jvm GC优化

xiaoxiao2024-10-02  31

JVM GC调优

年轻代和年老代增量的比例分别通过命令行参数 -XX:YoungGenerationSizeIncrement=<Y> 和-XX:TenuredGenerationSizeIncrement=<T> 来设定。而缩小比例的要通过-XX:AdaptiveSizeDecrementScaleFactor=<D> 参数来设定。如果增量是X%,那么每次减小量就是(X/D)%。

 

吞吐量目标测量垃圾回收时间和非垃圾回收时间(也就是应用时间)的比例。这个目标时间可以用命令行参数-XX:GCTimeRatio=<N> 来指定,这样,垃圾回收时间和应用时间的比例将是1 / (1 + <N>) 。例如,-XX:GCTimeRatio=19 设置1/20活5%的时间用于垃圾回收。缺省值是99,目标是1%的时间用于垃圾回收。

 

最大停顿时间的目标由参数-XX:MaxGCPauseMillis=<N> 来指定。

 

垃圾收集器线程数的多少可以用-XX:ParallelGCThreads=<N> 参数来控制。。

 

当有过多的时间花费在垃圾收集上的时候,并行垃圾收集器会跑出 OutOfMemoryError 错误:如果超过 98% 的时间花费在垃圾收集上并且只有 2% 的堆被释放的话,就会抛出一个 OutOfMemory。这个功能是用来防止堆太小导致程序长时间无法正常工作而设计的。如果必要,这个功能可以使用命令行参数-XX:-UseGCOverheadLimit 来关闭。

 

发垃圾收集器适用于那些需要更短的垃圾收集停顿,并发垃圾收集器可以通过命令行参数-XX:+UseConcMarkSweepGC 来启动。

 

 

应用程序和垃圾回收器的另一个交互途径是显式调用 System.gc() 进行完整的垃圾回收。这回强制进行一次主回收,即使没有必要(也就是说一次小回收可能就足够了),所以应该避免这种情况。显式垃圾回收对性能的影响可以通过使用 -XX:+DisableExplicitGC 进行比较来进行测量,这样虚拟机会无视 System.gc() 的。

 

Soft reference在虚拟机中比在客户集中存活的更长一些。其清除频率可以用命令行参数 -XX:SoftRefLRUPolicyMSPerMB=<N> 来控制,这可以指定每兆堆空闲空间的 soft reference 保持存活(一旦它不强可达了)的毫秒数,这意味着每兆堆中的空闲空间中的 soft reference 会(在最后一个强引用被回收之后)存活1秒钟。注意,这是一个近似的值,因为 soft reference 只会在垃圾回收时才会被清除,而垃圾回收并不总在发生。

 

-XX:+PrintHeapAtGC  在GC回收的时候打印Heap信息

 

为了能够将JVM GC的调优能够使用在具体的实践当中,下面将利用若干个例子来说明GC的调优.例1:Heap size 设置 JVM 堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值,其初始空间(即-Xms)是物理内存的1/64,最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。当在JAVA_HOME下demo/jfc/SwingSet2/目录下执行下面的命令。java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar系统输出为:Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap spaceException in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap spaceException in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap spaceException in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space除了这些异常信息外,还会发现程序的响应速度变慢了。这说明Heap size 设置偏小,GC占用了更多的时间,而应用分配到的执行时间较少。提示:在JVM中如果98%的时间是用于GC且可用的Heap size 不足2%的时候将抛出此异常信息。 将上面的命令换成以下命令执行则应用能够正常使用,且未抛出任何异常。java -jar -Xmn4m -Xms16m -Xmx32m SwingSet2.jar提示:Heap Size 最大不要超过可用物理内存的80%,一般的要将-Xms和-Xmx选项设置为相同,而-Xmn为1/4的-Xmx值。

例2:Young Generation(-Xmn)的设置 在本例中看一下Young Generation的设置不同将有什么现象发生。假设将Young generation 的大小设置为4M ,即执行java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar,屏幕输出如下(节选)[GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs][GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs][GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]将程序体制并将Young Generation的大小设置为8M,即执行java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar,屏幕输出如下(节选)[GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs][GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs][GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs][GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs][GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs][GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]那么根据GC输出的信息(这里取第一行)做一下Minor收集的比较。可以看出两次的Minor收集分别在Young generation中找回3904K(3968K->64K)和7616K(7808K->192K)而对于整个jvm则找回 1943K(3968K->2025)和5451K(7808K->2357K)。第一种情况下Minor收集了大约50%(1943/3904)的对象,而另外的50%的对象则被移到了tenured generation。在第二中情况下Minor收集了大约72%的对象,只有不到30%的对象被移到了Tenured Generation.这个例子说明此应用在的Young generation 设置为4m时显的偏小。提示:一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70%以上。当然在实际的应用中需要根据具体情况进行调整。

例3:Young Generation对应用响应的影响 还是使用-Xmn4m 和-Xmn8m进行比较,先执行下面的命令

java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar屏幕输出如下(节选)Application time: 0.5114944 seconds[GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs]Total time for which application threads were stopped: 0.0839428 secondsApplication time: 0.9871271 seconds[GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs]Total time for which application threads were stopped: 0.0464380 secondsYoung Generation 的Minor收集占用的时间可以计算如下:应用线程被中断的总时常/(应用执行总时?L+应用线程被中断的总时常),那么在本例中垃圾收集占用的时?L约为系统的5%~14%。那么当垃圾收集占用的时间的比例越大的时候,系统的响应将越慢。提示:对于互联网应用系统的响应稍微慢一些,用户是可以接受的,但是对于GUI类型的应用响应速度慢将会给用户带来非常不好的体验。

例4:如何决定Tenured Generation 的大小 分别以-Xmn8m -Xmx32m和-Xmn8m -Xmx64m进行对比,先执行java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类,命令行将提示(只提取了Major收集)

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs]144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]再执行java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类,命令行将提示(只提取了Major收集)90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]可以看出在Heap size 为32m的时候系统等候时间约为0.13秒左右,而设置为64m的时候等候时间则增大到0.22秒左右了。但是在32m的时候系统的Major收集间隔为 10秒左右,而Heap size 增加到64m的时候为30秒。那么应用在运行的时候是选择32m还是64m呢?如果应用是web类型(即要求有大的吞吐量)的应用则使用64m(即 heapsize大一些)的比较好。对于要求实时响应要求较高的场合(例如GUI型的应用)则使用32m比较好一些。 注意:1。因为在JVM5运行时已经对Heap-size进行了优化,所以在能确定java应用运行时不会超过默认的Heap size的情况下建议不要对这些值进行修改。2。 Heap size的 -Xms -Xmn 设置不要超出物理内存的大小。否则会提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

例5:如何缩短minor收集的时间 下面比较一下采用-XX:+UseParNewGC选项和不采用它的时候的minor收集将有什么不同。先执行java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 系统将输出如下信息(片段〕[GC 7807K->2641K(32576K), 0.0676654 secs][GC 10436K->3108K(32576K), 0.0245328 secs][GC 10913K->3176K(32576K), 0.0072865 secs][GC 10905K->4097K(32576K), 0.0223928 secs]之后再执行 java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar系统将输出如下信息(片段〕[ParNew 7808K->2656K(32576K), 0.0447687 secs][ParNew 10441K->3143K(32576K), 0.0179422 secs][ParNew 10951K->3177K(32576K), 0.0031914 secs][ParNew 10985K->3867K(32576K), 0.0154991 secs]很显然使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。

例6:如何缩短major收集的时间 下面比较一下采用-XX:+UseConcMarkSweepGC选项和不采用它的时候的major收集将有什么不同。先执行java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar系统将输出如下信息(片段〕[Full GC 22972K->18690K(262080K), 0.2326676 secs][Full GC 18690K->18690K(262080K), 0.1701866 secs之后再执行 java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar系统将输出如下信息(片段〕[Full GC 56048K->18869K(260224K), 0.3104852 secs]提示:此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

例7:关于-server选项 在JVM中将运行中的类认定为server-class的时候使用此选项。SUN 的Hot Spot JVM5 如果判断到系统的配置满足如下条件则自动将运行的类认定为server-class,并且会自动设置jvm的选项(当没有手工设置这选项的时候〕而且 HOTSPOT JVM5提供了自动调优的功能,他会根据JVM的运行情况进行调整。如果没有特别的需要是不需要太多的人工干预的。SUN形象的称这个机制为“人体工学 ”(Ergonomics〕。具体可以参考http://java.sun.com/docs/hotspot/gc5.0/ergo5.html*.具有2个或更多个物理的处理器*.具有2G或者更多的物理内存提示:此选项要放在所有选项的前面。例如:java -server 其他选项 java类

附录A:预备知识 . JVM中对象的划分及管理

JVM根据运行于其中的对象的生存时间大致的分为3种。并且将这3种不同的对象分别存放在JVM从系统分配到的不同的内存空间。这种对象存放空间的管理方式叫做Generation管理方式。1。Young Generation:用于存放“早逝”对象(即瞬时对象)。例如:在创建对象时或者调用方法时使用的临时对象或局部变量。2。Tenured Generation:用于存放“驻留”对象(即较长时间被引用的对象)。往往体现为一个大型程序中的全局对象或长时间被使用的对象。3。Perm Generation:用于存放“永久”对象。这些对象管理着运行于JVM中的类和方法。

. JVM选项的分类

JVM有这么几种选项供使用.1.供-X选项使用的项目,又称为非标准选项,不同厂商的此类型选项是有所不同的。例如:IBM的JVM用的一些选项在Sun的JVM中就不一定能生效。这种选项的使用方式如下:java -Xmn16m -Xms64m -Xmx64m java类名2.供-XX选项使用的项目,这种类型的选项可能要求有对系统信息访问的权限。所以要慎用。这种选项的使用方式如下:java -XX:MaxHeapFreeRatio=70 -XX:+PrintGCDetails java类名3.java选项(即在命令行执行java后提示的选项).java -server -verbose:gc -d64 java类名

. 垃圾收集分类

在JVM中有两种垃圾方式,一种叫做Minor(次收集),另一种叫做Major(主收集)。其中Minor在Young Generation的空间被对象全部占用后执行,主要是对Young Generation中的对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集经常发生,并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵”的垃圾收集方式,因为在Major要对整个Heap size进行垃圾收集,这会使得应用停顿的时间变得较长。

. GC信息的格式

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]<collector> GC为minor收集过程中使用的垃圾收集器起的内部名称.<starting occupancy1> young generation 在进行垃圾收集前被对象使用的存储空间.<ending occupancy1> young generation 在进行垃圾收集后被对象使用的存储空间<pause time1> minor收集使应用暂停的时间长短(秒) <starting occupancy3> 整个堆(Heap Size)在进行垃圾收集前被对象使用的存储空间<ending occupancy3> 整个堆(Heap Size)在进行垃圾收集后被对象使用的存储空间<pause time3> 整个垃圾收集使应用暂停的时间长短(秒),包括major收集使应用暂停的时间(如果发生了major收集).. GC信息的选项-XX:+PrintGCDetails 显示GC的详细信息-XX:+PrintGCApplicationConcurrentTime 打印应用执行的时间-XX:+PrintGCApplicationStoppedTime 打印应用被暂停的时间

J2SE 6(代号:Mustang野马)主要设计原则之一就是提升J2SE的性能和扩展能力,主要通过最大程度提升运行效率,更好的垃圾收集和一些客户端性能来达到。 1、偏向锁(Biased locking) Java 6以前加锁操作都会导致一次原子CAS(Compare-And-Set)操作,CAS操作是比较耗时的,即使这个锁上实际上没有冲突,只被一个线程拥有,也会带来较大开销。为解决这一问题,Java 6中引入偏向锁技术,即一个锁偏向于第一个加锁的线程,该线程后续加锁操作不需要同步。大概的实现如下:一个锁最初为NEUTRAL状态,当第一个线程加锁时,将该锁的状态修改为BIASED,并记录线程ID,当这一线程进行后续加锁操作时,若发现状态是BIASED并且线程ID是当前线程ID,则只设置一下加锁标志,不需要进行CAS操作。其它线程若要加这个锁,需要使用CAS操作将状态替换为REVOKE,并等待加锁标志清零,以后该锁的状态就变成 DEFAULT,常用旧的算法处理。这一功能可用-XX:-UseBiasedLocking命令禁止。 2、锁粗化(Lock coarsening) 如果一段代码经常性的加锁和解锁,在解锁与下次加锁之间又没干什么事情,则可以将多次加加锁解锁操作合并成一对。这一功能可用-XX:-EliminateLocks禁止。 3、自适应自旋(Adaptive spinning) 一般在多CPU的机器上加锁实现都会包含一个短期的自旋过程。自旋的次数不太好决定,自旋少了会导致线程被挂起和上下文切换增加,自旋多了耗CPU。为此Java 6中引入自适应自旋技术,即根据一个锁最近自旋加锁成功概率动态调整自旋次数。 4、常用大内存分布的堆(large page heap) 在大内分页是x86/amd64架构上用来减小TLB(虚拟地址到物理地址翻译缓存)大小的TLB失配率。Java 6中的内存堆可以使用这一技术。 5、提高数组拷贝性能 对每种类型大小写一个定制的汇编数组拷贝程序。 6、后台进行代码优化 Background Compilation in HotSpot™ Client Compiler: 后台进行代码优化 7、线性扫描寄存器分配算法(Linear Scan Register Allocation): 一种新的寄存器分配策略,基于SSA(static single assignment),性能提高10%左右。常用的寄存器分配算法将寄存器分配看作图着色问题,时间复杂度是O(n^4),不适用于Java的JIT编译。原来的JVM里是根据一些本地启发式规则来分配寄存器,效果不太好,Java 6中使用的线性扫描寄存器算法能够达到与图颜色算法相似的效果,并且时间复杂度是线性的。 8、并行缩并垃圾收集器(Parallel Compaction Collector) 进行Full GC时使用并行垃圾收集(JDK 5里原来非Full GC是并行的但Full GC是串行的),使用-XX:+UseParallelOldGC开启这一功能 9、并行低停顿垃圾收集器(Concurrent Low Pause Collector) 显式调用gc(如System.gc)时也可以并行进行标记-清扫式垃圾收集,使用-XX:+ExplicitGCInvokesConcurrent开启。 10、Ergonomics in the 6.0 Java Virtual Machine 自动调整垃圾收集策略、堆大小等配置,这一功能在JDK 5中加入,JDK 6中得到显著增强,SPECjbb2005性能提高70%。 11、boot类装载器的优化 jre中增加一个描述package所在jar文件的元索引文件,加快classloader加载类性能,提高桌面Java应用启动速度(+15%)。内存占用也减少了10% 12、图形程序优化 在jvm启动之前显示splash。

3 收集器选择

CMS收集器:暂停时间优先

   配置参数:-XX:+UseConcMarkSweepGC    已默认无需配置的参数:-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(FullGC时压缩年老代)

   初始效果:1G堆内存的新生代约60m,minor gc约5-20毫秒,full gc约130毫秒。

Parallel收集器:吞吐量优先

    配置参数: -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代,从JDK6.0开始支持)

    已默认无需配置的参数: -XX:+UseAdaptiveSizePolicy(动态调整新生代大小)

    初始效果:1G堆内存的新生代约90-110m(动态调整),minor gc约5-20毫秒,full gc没有UseParallelOldGC 参数约 1.3秒,有UseParallelOldGC参数约1.06秒,差别不大。

    另外-XX:MaxGCPauseMillis=100 设置期望minor gc的最大时间,JVM会以此来调整新生代的大小,但在此测试环境中对象死的太快,此参数作用不大。

4 调优实战

      Parallel收集高达1秒的暂停时间基本不可忍受,所以选择CMS收集器。

      不知为何在被压的Mule 2.0应用里,每秒都有大约400M的海量短命对象产生:

因为默认60M的新生代太小了,频繁发生minor gc,大约0.2秒就进行一次。 因为CMS收集器中MaxTenuringThreshold(生代对象撑过过多少次minor gc才进入年老代的设置)默认0,存活的临时对象不经过Survivor区直接进入年老代,不久就占满年老代发生full gc。

     对这两个参数进行调优,既要改善上面两种情况,又要避免新生代过大,复制次数过多造成minor gc的暂停时间过长。

使用-Xmn调到1/3 总内存。比较后设置-Xmn500m,新生代实际约460m。(-XX:NewRatio参数无效)。 添加-XX:+PrintTenuringDistribution 参数观察各个Age的对象总大小,观察后设置-XX:MaxTenuringThreshold=5。

      优化后,大约1.1秒才发生一次minor GC,同时年老代的增长速度大大减缓,预计几个小时才会发生一次GC,而minor gc速度依然保持在15-20ms之间。

      参数定稿:

 -Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC  -XX:MaxTenuringThreshold=5  -XX:+ExplicitGCInvokesConcurrent 显式调用gc(如System.gc)时也可以并行进行标记-清扫式垃圾收集,使用-XX:+ExplicitGCInvokesConcurrent开启。 相关资源:敏捷开发V1.0.pptx
转载请注明原文地址: https://www.6miu.com/read-5017962.html

最新回复(0)