JDK8 JVM性能优化-1

原文地址:https://blog.csdn.net/xingkongtianma01/article/details/80689928

大 多数情况下,我们并不需要关心JVM的底层,但是如果了解它的话,对于我们系统调优是非常有用的,在这里面了解JVM的GC原理,是非常重要的一块知识。 我们都知道对于一个大型网站,如果JVM频繁发生FULL GC,那么将会是致命的危险,不仅仅会造成网站响应迟钝,更严重的时候会导致系统崩溃,这对用户体验来讲,都是我们不愿意看到的。

在JVM里的内存空间,从大的层面划分,主要有新生代空间(Young)和老年代空间(Old),其中Young空间,又被分为2个部分和3个板块,分别是1个Egen区,和2个Survivor区,看下图:

OK,下面来具体看下,每部分都是干啥的 
(1)Eden区域是用来存放使用new或者newInstance等方式创建的对象,默认都是存放在Eden区,除非这个对象太大,或者超过了设定的阈值-XX:PretenureSizeThresold,这样的对象会被直接分配到Old区域。

(2)2个Survivor(幸存)区,一般称S0,S1,理论上他们是一样大的,解释一下,他们是如何工作的: 
在不断创建对象的过程中,Eden区会满,这时候会开始做Young G也叫Minor GC,而Young空间的第一次GC就是找出Eden区中,幸存活着的对象,然后将这些对象,放到S0,或S1区中的其中一个, 假设第一次选择了S0,它会逐步将活着的对象拷贝到S0区域,但是如果S0区域满了,剩下活着的对象只能放old区域了,接下来要做的是,将Eden区域 清空,此时时候S1区域也是空的。

当第二次Eden区域满的时候,就将Eden区域中活着的对象+S0区域中活着的对象,迁移到S1中,如果S1放不下,就会将剩下的部门,放到Old区域中,只是这次对象来源区域增加了S0,最后会将Eden区+S0区域,清空

第三次和第四次依次类推,始终保证S0和S1有一个是空的,用来存储临时对象,用于交换空间的目的,反反复复多次没有被淘汰的对象,将会放入old区域中,默认是15次。具体的交换过程就和上图中的信息相似。

问题一:怎么定义活着的对象? 
从根引用开始,对象的内部属性可能也是引用,只要能级联到的都被认为是活着的对象

问题二:什么是根? 
本地变量引用,操作数栈引用,PC寄存器,本地方法栈引用等这些都是根。

问题三:对象进入Old区域有什么坏处? 
old区域一般称为老年代,老年代与新生代不一样,年轻代,我们可以认为存活下来的对象很少,而老年代则相反,存活下来的对象很多,所以JVM的 堆内存,才是我们通常关注的主战场,因为这里面活着的对象非常多,所以发生一次FULL GC,来找出来所有存活的对象是非常耗时的,因此,我们应该尽量避免FULL GC的发生。

问题四:S0和S1一般多大,靠什么参数来控制,有什么变化?

一般来说很小,我们大概知道它与Young差不多相差一倍的比例,设置的的参数主要有两个: 
-XX:SurvivorRatio=8 
-XX:InitialSurvivorRatio=8

第一个参数是Eden和Survivor区域比重,注意是一个Survivor的的大小,如果将其设置为8,则说明Eden区是一个Survivor区的8倍,换句话说S0或S1空间是整个Young空间的1/10,剩余的80%由Eden区域来使用。

第二个参数是Young/S0的比值,当其设置为8时,表示s0或s1占整个Young空间的12.5%。

问题五;一个对象每次Minor Gc时,活着的对象都会在s0和s1区域转移,经过经过Minor GC多少次后,会进入Old区域呢?

默认是15次,参数设置-XX:MaxTenuringThreshold=15,计数器会在对象的头部记录它交换的次数

问题六:为什么发生FULL GC会带来很大的危害?

在发生FULL GC的时候,意味着JVM会安全的暂停所有正在执行的线程(Stop The World),来回收内存空间,在这个时间段内,所有除了回收垃圾的线程外,其他有关JAVA的程序,代码都会静止,反映到系统上,就会出现系统响应大幅度变慢,卡机等状态。

举个通俗易懂点的例子,就是在一个房间里,如果有一个人,不停的扔垃圾,然后有一个清洁工不停扫垃圾,这时候,我们的系统是OK的,因为基本不会 出现垃圾堆满房间的情景,而且因为清洁工可以对付过来,假设现在有10个人不停扔垃圾,那么就房间就会很快被堆满,这时候清洁工,由于工作不过来了,大声 吼一声,你们都暂停3分钟,别再扔了,我先把这个房间打扫完,你们才可以扔。 
在这个场景中,一个人扔,一个人扫,就类似于Minor GC,这时候,并不会影响扔垃圾的人,然后一旦10个人同时仍,而且很快就没地方仍了,这时候,就会触发Full GC,然后JVM下令,你们暂时都别仍了,等我什么时候回收完垃圾了,你们在仍,现在大家清楚了吧,所谓的10个人,就是类似我们成千上百的java类, 在不停的执行任务,所谓的清洁工,就是我们的GC机制,所以,大家在平时编码的时候,一定注意尽量少造点垃圾对象,这样触发FULL GC的几率,才会变小。

原文地址:https://www.cnblogs.com/technology-huangyan/p/10175621.html

时间: 2024-08-08 02:35:14

JDK8 JVM性能优化-1的相关文章

jvm性能优化及内存分区

jvm性能优化及内存分区 2012-09-17 15:51:37 分类: Java Some of the default values for Sun JVMs are listed below. JDK 1.3.1_06 Initial Size Maximum Size Client JVM 1MB 32MB Server JVM 1MB 64MB JDK 1.4.1_01 Initial Size Maximum Size Client JVM 4MB 64MB Server JVM 4

JVM性能优化, Part 5:Java的伸缩性

ImportNew注: JVM性能优化系列文章前4篇由ImportNew翻译(第一篇,第二篇,第三篇, 第四篇).本文由新浪微博:吴杰 (@WildJay) 投稿至ImportNew.感谢吴杰! 如果你希望分享好的原创文章或者译文,欢迎投稿到ImportNew. 很多程序员在解决JVM性能问题的时候,花开了很多时间去调优应用程序级别的性能瓶颈,当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题.我说过JVM的自身技术限制了Java企业级应用的伸缩性.首先我们先列举一些主导因素. l

JVM性能优化, Part 2 ―― 编译器

作为JVM性能优化系列文章的第2篇,本文将着重介绍Java编译器,此外还将对JIT编译器常用的一些优化措施进行讨论(参见"JVM性能优化,Part 1″中对JVM的介绍).Eva Andreasson将对不同种类的编译器做介绍,并比较客户端.服务器端和层次编译产生的编译结果在性能上的区别,此外将对通用的JVM优化做介绍,包括死代码剔除.内联以及循环优化. Java编译器存在是Java编程语言能独立于平台的根本原因.软件开发者可以尽全力编写程序,然后由Java编译器将源代码编译为针对于特定平台的高

一文学会JVM性能优化

实战性能优化 1 重新认知JVM 之前我们画过一张图,是从Class文件到类装载器,再到运行时数据区的过程,现在咱们把这张图不妨丰富完善一下,展示了JVM的大体物理结构图. 执行引擎:用于执行JVM字节码指令 主要由两种实现方式: (1)将输入的字节码指令在加载时或执行时翻译成另外一种虚拟机指令: (2)将输入的字节码指令在加载时或执行时翻译成宿主主机本地CPU的指令集.这两种方式对应着字节码的解释执行和即时编译. 9.2 堆内存溢出 9.2.1 代码 记得设置参数比如-Xmx20M -Xms2

JVM性能优化,第2部分:编译器JVM

通过优锐课的java学习分享中,整理了部分关于JVM的相关知识点,分享给大家参考学习,如有不足之处,欢迎 补充! Java编译器在JVM性能优化系列的第二篇文章中占据中心位置. Eva Andreasson介绍了不同种类的编译器,并比较了客户端,服务器和分层编译的性能结果.最后,她概述了常见的JVM优化,例如消除死代码,内联和循环优化. Java编译器是Java著名的平台的独立性的来源.软件开发人员会尽力编写最好的Java应用程序,然后编译器会在幕后进行工作,以为目标目标平台生成高效且性能良好的

Tomcat7调优及JVM性能优化for Linux环境

   该优化针对Linux X86_X64环境 Tomcat的三种模式及并发优化 Tomcat的运行模式有3种 1. bio 默认的模式,性能非常低下,没有经过任何优化处理和支持. 2. nio 利用java的异步io护理技术,noblocking IO技术 想运行在该模式下,直接修改server.xml里的Connector节点,修改protocol为 <Connector port="80″ protocol="org.apache.coyote.http11.Http11N

JVM性能优化,提高Java的伸缩性

很多程序员在解决JVM性能问题的时候,花开了很多时间去调优应用程序级别的性能瓶颈,当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题.我说过JVM的自身技术限制了Java企业级应用的伸缩性.首先我们先列举一些主导因素. 主流的硬件服务器提供了大量的内存 分布式系统有大量内存的需求,而且该需求在持续增长 一个普通Java应用程序所持有的对空间大概在1GB~4GB,这远远低于一个硬件服务器的内存管理能力以及一个分布式应用程序的内存需求量.这被称之为Java内存墙,如下图所示(图中表述Ja

提高Java的伸缩性 JVM性能优化

很多程序员在解决JVM性能问题的时候,花开了很多时间去调优应用程序级别的性能瓶颈,当你读完这本系列文章之后你会发现我可能更加系统地看待这类的问题.我说过JVM的自身技术限制了Java企业级应用的伸缩性.首先我们先列举一些主导因素. 主流的硬件服务器提供了大量的内存 分布式系统有大量内存的需求,而且该需求在持续增长 一个普通Java应用程序所持有的对空间大概在1GB~4GB,这远远低于一个硬件服务器的内存管理能力以及一个分布式应用程序的内存需求量.这被称之为Java内存墙,如下图所示(图中表述Ja

JVM性能优化系列-(1) Java内存区域

1. Java内存区域 1.1 运行时数据区 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域.主要包括:程序计数器.虚拟机栈.本地方法栈.Java堆.方法区(运 行时常量池).直接内存. 程序计数器 程序计数器(Program Counter Register)是一块较小的内存空间,可以看作是当前线程所执行的字节码的行号指示器.在虚拟机概念模型中,字节码解释器工作时就是通过改变计数器的值来选取下一条需要执行的字节码指令,分支.循环.跳转.异常处理.线程恢复等