JVM快速入门

1、类加载机制：

PS:关于双亲委派机制，扩展类加载器在JDK1.9中改为了平台加载器，如下图所示

2、JVM内存模型

 

JDK1.7版本

（方法区=Non-Heap, hotspot中为永久代）

 

在JDK1.8中，永久代改为元数据空间，直接由操作系统分配，不再受限于JVM。

方法区在逻辑上属于堆内存，表现在：

• 线程共享；
• 都可以被GC所管理。

关于JDK1.7与JDK1.8的堆内存具体差异，可以看下图

JDK1.8

JDK1.7

    计算伸缩区是否使用，将会耗费一定的计算资源，又因为使用JVM肯定要尽可能的往大设置，在我们工作中伸缩区的存在意义不大，所以一般设置"-Xmx512M -Xms512M"，其中512M根据自己需要设定，单位可以是M，也可以是G，二者应该设置相同的数值。

    -Xmx设置的为JVM最大堆内存，默认物理内存的1/4；

    -Xms设置的为JVM初始堆内存，默认物理内存的1/64；

 

3、对象可以回收的依据——对象不可用

引用计数器和可达性分析算法两种。

引用计数器记录对象是否被引用，当计数器为零时，说明对象已经不再被使用，可以进行回收。java中的对象有复杂的引用关系，如两个对象互相引用，引用计数器无法判定这种情况，所以sun jdk中并没有实现这种GC方式。

可达性分析：从GC Roots作为起始点，向下搜索，搜索所走过的路径成为引用链（Reference Chain）。当一个对象到GC Roots不存在引用链时，证明此对象不可用。

 

4、内存回收算法

1）三种回收算法的介绍

复制：从根集合搜扫描出存活的对象，然后将存活的对象复制到一块新的未使用的空间中，当要回收的空间中存活的对象较少时，比较高效。年轻代使用这种算法；

标记清除：从根集合开始扫描，对存活的对象进行标记，比较完毕后，再扫描整个空间中未标记的对象，然后进行回收，不需要对对象进行移动；

标记整理：基于“标记清除”，但是回收不存活的对象后，会把所有存活的对象在内存空间中进行移动，好处是减少了内存碎片，缺点是成本比较高。老年代使用这种算法；

PS:会发生STW（Stop-The-World）问题，暂时挂起所有的执行线程，标记可以回收的对象。

2）复制算法的应用——年轻代垃圾回收机制

年轻代

Eden 伊甸园区 占年轻代80%空间 新建的对象放这里，如果过大直接放老年代。	S0 10%空间
	S1 10%空间

1. 回收时，伊甸园+S0存活的对象，放入S1；
2. 清空伊甸园+S0；
3. 再次回收时，伊甸园+S1存活的对象，放入S0；
4. 清空伊甸园+S1；
5. 1-4步循环进行，必定有10%的年轻代空间被浪费掉；
6. S0或者S1放不下对象时（分配担保），或对象年龄（存活一次回收+1）够大时，或新生对象过大时，或动态年龄比例满足条件时（根据年龄划分，低龄对象所占空间占比达到50%，送走高龄），将对象放入老年代。

 

5、GC处理流程

1、新对象都会在伊甸园区开辟，伊甸园区的内存空间不足会发生MinorGC。

Member mem = new Member()，很小，直接保存在伊甸园；过大，放入老年代。

2、有些对象执行了N次的MinorGC后还会存在，那么这些对象将进入到存活区（S0+S1，永远都有一个空着）；

3、根据大小、年龄、动态年龄比例，或者存活区放不下了，把相应的对象放入老年代；

4、若干次MinorGC回收之后空间依然不够使用，那么则进行老年代GC回收，执行了MajorGC（Full GC，性能很差），如果可以回收空间，则继续进行MinorGC；

5、如果MajorGC失败，则继续内存已经占用完满，则抛出OOM异常；

 

6、G1算法

• 支持大内存（4G-64G）；
• 支持多CPU；
• 减少STW停顿时间；
• 可以保证并发状态下的程序执行；
• 采用分片的思想，每个片区都有自己独立的年轻代、老年代，独立进行自己的垃圾回收。
• 开启命令 -XX:+UseG1GC

 

7、jvm性能调优

• java内存分析工具： jmap -heap PID
• tomcat/bin/catalina.sh（8G机器）添加JAVA_OPTS="-Xms4096m -Xmx4096m -Xss1024K -XX:+UseG1GC”

 

8、其他资料

为什么要有GC（垃圾回收）？

 

JVM通过GC来回收堆和方法区中的内存，GC的基本原理就是找到程序中不再被使用的对象，然后回收掉这些对象占用的内存。

 

主要的收集器有哪些？

引用计数器和跟踪计数器两种。

引用计数器记录对象是否被引用，当计数器为零时，说明对象已经不再被使用，可以进行回收。java中的对象有复杂的引用关系，不是很适合引用计数器，所以sun jdk中并没有实现这种GC方式。

跟踪收集器，全局记录数据的引用状态，基于一定的条件触发。执行的时候，从根集合开始扫描对象的引用关系，主要有复制（copying）、标记-清除（Mark-Sweep）、标记-压缩(Mark-Compact)那种算法。

 

跟踪计数器的三种算法简介？

复制：从根集合搜扫描出存活的对象，然后将存活的对象复制到一块新的未使用的空间中，当要回收的空间中存活的对象较少时，比较高效；

标记清除：从根集合开始扫描，对存活的对象进行标记，比较完毕后，再扫描整个空间中未标记的对象，然后进行回收，不需要对对象进行移动；

标记压缩：标记形式和“标记清除”一样，但是回收不存活的对象后，会把所有存活的对象在内存空间中进行移动，好处是减少了内存碎片，缺点是成本比较高；

 

java内存区域的形式是啥样的？

这里就不再介绍了，之前有一篇文章中专门介绍这个的（http://iamzhongyong.iteye.com/blog/1333100）。

 

新生代可用的GC？

新生代中对象存活的时间比较短，因此给予Copying算法实现，Eden区域存放新创建的对象，S0和S1区其中一块用于存放在Minor GC的时候作为复制存活对象的目标空间，另外一块清空。

串行GC（Serial GC）比较适合单CPU的情况，可以通过-XX：UseSerialGC来强行制定；

并行回收GC（Parallel Scavenge），启动的时候按照设置的参数来划定Eden/S0/S1区域的大小，但是在运行时，会根据Minor GC的频率、消耗时间来动态调整三个区域的大小，可以用过-XX：UseAdaptiveSizePolicy来固定大小，不进行动态调整；

并行GC（ParNew）划分Eden、S1、S0的区域上和串行GC一样。并行GC需要配合旧生代使用CMS GC（这是他和并行回收GC的不同）（如果配置了CMS GC的方式，那么新生代默认采取的就是并行GC的方式）；

 

啥时候会触发Minor GC？

当Eden区域分配内存时，发现空间不足，JVM就会触发Minor GC，程序中System.gc()也可以来触发。

 

旧生代可用的GC方式有哪几种？

串行GC（Serial MSC）、并行GC（Parallel MSC）、并发GC（CMS）；

 

关于CMS？

采用CMS时候，新生代必须使用Serial GC或者ParNew GC两种。CMS共有七个步骤，只有Initial Marking和Final Marking两个阶段是stop-the-world的，其他步骤均和应用并行进行。持久代的GC也采用CMS，通过-XX：CMSPermGenSweepingEnabled -XX：CMSClassUnloadingEnabled来制定。在采用cms gc的情况下，ygc变慢的原因通常是由于old gen出现了大量的碎片。

 

为啥CMS会有内存碎片，如何避免？

由于在CMS的回收步骤中，没有对内存进行压缩，所以会有内存碎片出现，CMS提供了一个整理碎片的功能，通过-XX：UseCompactAtFullCollection来启动此功能，启动这个功能后，默认每次执行Full GC的时候会进行整理（也可以通过-XX：CMSFullGCsBeforeCompaction=n来制定多少次Full GC之后来执行整理），整理碎片会stop-the-world.

 

啥时候会触发CMS GC？

1、旧生代或者持久代已经使用的空间达到设定的百分比时（CMSInitiatingOccupancyFraction这个设置old区，perm区也可以设置）；

2、JVM自动触发(JVM的动态策略，也就是悲观策略)（基于之前GC的频率以及旧生代的增长趋势来评估决定什么时候开始执行），如果不希望JVM自行决定，可以通过-XX：UseCMSInitiatingOccupancyOnly=true来制定；

3、设置了 -XX：CMSClassUnloadingE考虑nabled 这个则考虑Perm区；

 

啥时候会触发Full GC？

一、旧生代空间不足：java.lang.outOfMemoryError：java heap space；

二、Perm空间满：java.lang.outOfMemoryError：PermGen space；

三、CMS GC时出现promotion failed  和concurrent  mode failure（Concurrent mode failure发生的原因一般是CMS正在进行，但是由于old区内存不足，需要尽快回收old区里面的死的java对象，这个时候foreground gc需要被触发，停止所有的java线程，同时终止CMS，直接进行MSC。）；

四、统计得到的minor GC晋升到旧生代的平均大小大于旧生代的剩余空间；

五、主动触发Full GC（执行jmap -histo:live [pid]）来避免碎片问题；

 

为啥heap小于3g不建议使用CMS GC这种方式？

http://hellojava.info/?p=142 毕大师的这篇文章讲的很清楚。

1、触发比例不好设置，设置大了，那么剩余的空间就少了很多，设置小了，那old区还没放置多少东西，就要进行回收了；

2、CMS进行的时候，是并行的，也就意味着如果过于频繁的话，会和应用的强占CPU；

3、CMS会有内存 碎片问题；

4、YGC的速率变慢（由于CMS GC的实现原理，导致对象从新生代晋升到旧生代时，寻找哪里能放下的这个步骤比ParallelOld GC是慢一些的，因此就导致了YGC速度会有一定程度的下降。）；

 

JVM的悲观策略是啥？

所谓的悲观策略（http://tmalltesting.com/archives/663 我们性能测试团队一个同学分析的案例），就是JVM不按照JVM指定的参数来进行CMS GC，而是根据内存情况以及之前回收的方式动态调整，自行进行GC。旧生代剩余的空间（available）大于新生代中使用的空间（max_promotion_in_bytes），或者大于之前平均晋升的old的大小（av_promo），返回false。cms gc是每隔一个周期（默认2s）就会做一次这个检查，如果为false，则不执行YGC，而触发cms gc。

 

我们经常使用的是啥GC方式？

针对目前线上机器的情况（8G的物流内存），heap区一般设置在4g或者5g左右，一般是使用CMS GC，这时候：

young区使用ParNew（并行GC），Old+Perm(需要单独设置)使用CMS，整个堆（young+old+perm）使用MSC（（Mark Sweep Compact）是CMS GC算法的Full GC算法,单线程回收整个堆，回收过程有严格的步骤。压缩，所以回收完理论上任何Generation都不会有内存碎片）压缩回收的方式。

 

读懂GC日志？

基本上都是这种格式：回收前区域占用的大小->回收后区域占用的大小（区域设置的大小），占用的时间

 

1、promotion failed的一段日志

1 2

2013-11-27T03:00:53.638+0800: 35333.562: [GC 35333.562: [ParNew (promotion failed): 1877376K->1877376K(1877376K), 15.7989680 secs]35349.361: [CMS: 2144171K->2129287K(2146304K), 10.4200280 sec s] 3514052K->2129287K(4023680K), [CMS Perm : 119979K->118652K(190132K)], 26.2193500 secs] [Times: user=30.35 sys=5.19, real=26.22 secs]

解释如下：

1 2 3 4 5

1877376K->1877376K(1877376K), 15.7989680 secs   young区 2144171K->2129287K(2146304K), 10.4200280 sec     old区情况 3514052K->2129287K(4023680K)                     heap区情况 119979K->118652K(190132K)], 26.2193500 secs      perm区情况  [Times: user=30.35 sys=5.19, real=26.22 secs]    整个过程的时间消耗

 

2、一段正常的CMS的日志

1 2 3 4 5 6 7 8 9 10 11 12 13 14

2013-11-27T04:00:12.819+0800: 38892.743: [GC [1 CMS-initial-mark: 1547313K(2146304K)] 1734957K(4023680K), 0.1390860 secs] [Times: user=0.14 sys=0.00, real=0.14 secs] 2013-11-27T04:00:12.958+0800: 38892.883: [CMS-concurrent-mark-start] 2013-11-27T04:00:19.231+0800: 38899.155: [CMS-concurrent-mark: 6.255/6.272 secs] [Times: user=8.49 sys=1.57, real=6.27 secs] 2013-11-27T04:00:19.231+0800: 38899.155: [CMS-concurrent-preclean-start] 2013-11-27T04:00:19.250+0800: 38899.175: [CMS-concurrent-preclean: 0.018/0.019 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 2013-11-27T04:00:19.250+0800: 38899.175: [CMS-concurrent-abortable-preclean-start]  CMS: abort preclean due to time 2013-11-27T04:00:25.252+0800: 38905.176: [CMS-concurrent-abortable-preclean: 5.993/6.002 secs] [Times: user=6.97 sys=2.16, real=6.00 secs] 2013-11-27T04:00:25.253+0800: 38905.177: [GC[YG occupancy: 573705 K (1877376 K)]38905.177: [Rescan (parallel) , 0.3685690 secs]38905.546: [weak refs processing, 0.0024100 secs]38905.548: [cla ss unloading, 0.0177600 secs]38905.566: [scrub symbol & string tables, 0.0154090 secs] [1 CMS-remark: 1547313K(2146304K)] 2121018K(4023680K), 0.4229380 secs] [Times: user=1.41 sys=0.01, real= 0.43 secs] 2013-11-27T04:00:25.676+0800: 38905.601: [CMS-concurrent-sweep-start] 2013-11-27T04:00:26.436+0800: 38906.360: [CMS-concurrent-sweep: 0.759/0.760 secs] [Times: user=1.06 sys=0.48, real=0.76 secs] 2013-11-27T04:00:26.436+0800: 38906.360: [CMS-concurrent-reset-start] 2013-11-27T04:00:26.441+0800: 38906.365: [CMS-concurrent-reset: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

这个是一个正常的CMS的日志，共分为七个步骤，重点关注initial-mark和remark这两个阶段，因为这两个是停机的。

A、[GC [1 CMS-initial-mark: 1547313K(2146304K)] 1734957K(4023680K), 0.1390860 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]

各个数据依次表示标记前后old区的所有对象占内存大小和old的capacity，整个JavaHeap（不包括perm）所有对象占内存总的大小和JavaHeap的capacity。

B、2013-11-27T04:00:25.253+0800: 38905.177: [GC[YG occupancy: 573705 K (1877376 K)]38905.177: [Rescan (parallel) , 0.3685690 secs]38905.546: [weak refs processing, 0.0024100 secs]38905.548: [class unloading, 0.0177600 secs]38905.566: [scrub symbol & string tables, 0.0154090 secs] [1 CMS-remark: 1547313K(2146304K)] 2121018K(4023680K), 0.4229380 secs] [Times: user=1.41 sys=0.01, real=0.43 secs]

Rescan (parallel)表示的是多线程处理young区和多线程扫描old+perm的卡表的总时间， parallel 表示多GC线程并行。

weak refs processing 处理old区的弱引用的总时间，用于回收native memory。

class unloading 回收SystemDictionary消耗的总时间。

 

3、一段正常的Young GC的日志

1 2	2013-11-27T04:00:07.345+0800: 38887.270: [GC 38887.270: [ParNew: 1791076K->170624K(1877376K), 0.2324440 secs] 2988366K->1413629K(4023680K), 0.2326470 secs] [Times: user=0.80 sys=0.00, real=0. 23 secs]

ParNew这个表明是并行的回收方式，具体的分别是young区、整个heap区的情况；

 

4、一段通过system.gc产生的FullGC日志

1	2013-07-21T17:44:01.554+0800: 50.568: [Full GC (System) 50.568: [CMS: 943772K->220K(2596864K), 2.3424070 secs] 1477000K->220K(4061184K), [CMS Perm : 3361K->3361K(98304K)], 2.3425410 secs] [Times: user=2.33 sys=0.01, real=2.34 secs]

解释如下：

Full GC (System)意味着这是个system.gc调用产生的MSC。

“943772K->220K(2596864K), 2.3424070 secs”表示：这次MSC前后old区内总对象大小，old的capacity及这次MSC耗时。

“1477000K->220K(4061184K)”表示：这次MSC前后JavaHeap内总对象大小，JavaHeap的capacity。

“3361K->3361K(98304K)], 2.3425410 secs”表示：这次MSC前后Perm区内总对象大小，Perm区的capacity。

 

5、一个特殊的GC日志，根据动态计算直接进行的FullGC（MSC的方式）

1	2013-03-13T13:48:06.349+0800: 7.092: [GC 7.092: [ParNew: 471872K->471872K(471872K), 0.0000420 secs]7.092: [CMS: 366666K->524287K(524288K), 27.0023450 secs] 838538K->829914K(996160K), [CMS Perm : 3196K->3195K(131072K)], 27.0025170 secs]

ParNew的时间特别短，jvm在minor gc前会首先确认old是不是足够大，如果不够大，这次young gc直接返回，进行MSC。

 

 

其他资料转载自文章：

https://www.iteye.com/blog/iamzhongyong-1989829  一次CMS GC问题排查过程（理解原理+读懂GC日志）