探秘Java虚拟机——内存管理与垃圾回收

本文主要是基于Sun JDK 1.6 Garbage Collector（做者：毕玄）的整理与总结，原文请读者在网上搜索。

一、Java虚拟机运行时的数据区

二、经常使用的内存区域调节参数

-Xms：初始堆大小，默认为物理内存的1/64(<1GB)；默认(MinHeapFreeRatio参数能够调整)空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数能够调整)空余堆内存大于70%时，JVM会减小堆直到 -Xms的最小限制

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不一样的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。 
在保证堆大小不变的状况下，增大新生代后,将会减少老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX:SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每一个线程的堆栈大小。JDK5.0之后每一个线程堆栈大小为1M,之前每一个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减少这个值能生成更多的线程。可是操做系统对一个进程内的线程数仍是有限制的，不能无限生成，经验值在3000~5000左右。通常小的应用， 若是栈不是很深， 应该是128k够用的，大的应用建议使用256k。这个选项对性能影响比较大，须要严格的测试。和threadstacksize选项解释很相似,官方文档彷佛没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”通常设置这个值就能够了。

-XX:PermSize：设置永久代(perm gen)初始值。默认值为物理内存的1/64。

-XX:MaxPermSize：设置持久代最大值。物理内存的1/4。

三、内存分配方法

1）堆上分配   2）栈上分配  3）堆外分配（DirectByteBuffer或直接使用Unsafe.allocateMemory,但不推荐这种方式）

四、监控方法

1）系统程序运行时可经过jstat –gcutil来查看堆中各个内存区域的变化以及GC的工做状态； 
2）启动时可添加-XX:+PrintGCDetails  –Xloggc:<file>输出到日志文件来查看GC的情况； 
3）jmap –heap可用于查看各个内存空间的大小；

5）断代法可用GC汇总

1、新生代可用GC

1）串行GC(Serial Copying)：client模式下默认GC方式，也可经过-XX:+UseSerialGC来强制指定；默认状况下 eden、s0、s1的大小经过-XX:SurvivorRatio来控制，默认为8，含义 
为eden:s0的比例，启动后可经过jmap –heap [pid]来查看。

      默认状况下，仅在TLAB或eden上分配，只有两种状况下会在老生代分配： 
      一、须要分配的内存大小超过eden space大小； 
      二、在配置了PretenureSizeThreshold的状况下，对象大小大于此值。

      默认状况下，触发Minor GC时：
      以前Minor GC晋级到old的平均大小 < 老生代的剩余空间 < eden+from Survivor的使用空间。当HandlePromotionFailure为true，则仅触发minor gc；如为false，则触发full GC。

      默认状况下，新生代对象晋升到老生代的规则：

     一、经历屡次minor gc仍存活的对象，可经过如下参数来控制：以MaxTenuringThreshold值为准，默认为15。
     二、to space放不下的，直接放入老生代；

2）并行GC（ParNew）：CMS GC时默认采用，也可采用-XX:+UseParNewGC强制指定；垃圾回收的时候采用多线程的方式。

3）并行回收GC(Parallel Scavenge)：server模式下默认的GC方式，也可采用-XX:+UseParallelGC强制指定；eden、s0、s1的大小可经过-XX:SurvivorRatio来控制，但默认状况下
以-XX:InitialSurivivorRatio为准，此值默认为8，表明的为新生代大小 : s0，这点要特别注意。

      默认状况下，当TLAB、eden上分配都失败时，判断须要分配的内存大小是否 >= eden space的一半大小，如是就直接在老生代上分配；

      默认状况下的垃圾回收规则：

      一、在回收前PS GC会先检测以前每次PS GC时，晋升到老生代的平均大小是否大于老生代的剩余空间，如大于则直接触发full GC；
      二、在回收后，也会按照上面的规则进行检测。

      默认状况下的新生代对象晋升到老生代的规则：
     一、经历屡次minor gc仍存活的对象，可经过如下参数来控制：AlwaysTenure，默认false，表示只要minor GC时存活，就晋升到老生代；NeverTenure，默认false，表示永不晋升到老生代；上面两个都没设置的情冴下，如UseAdaptiveSizePolicy，启动时以InitialTenuringThreshold值做为存活次数的阈值，在每次ps gc后会动态调整，如不使用UseAdaptiveSizePolicy，则以MaxTenuringThreshold为准。
     二、to space放不下的，直接放入老生代。

     在回收后，如UseAdaptiveSizePolicy，PS GC会根据运行状态动态调整eden、to以及TenuringThreshold的大小。若是不但愿动态调整可设置-XX:-UseAdaptiveSizePolicy。如但愿跟踪每次的变化状况，可在启劢参数上增长： PrintAdaptiveSizePolicy。

2、老生代可用GC

一、串行GC(Serial Copying)：client方式下默认GC方式，可经过-XX:+UseSerialGC强制指定。

    触发机制汇总：
   1）old gen空间不足；
   2）perm gen空间不足；
   3）minor gc时的悲观策略；
   4）minor GC后在eden上分配内存仍然失败；
   5）执行heap dump时；
   6）外部调用System.gc，可经过-XX:+DisableExplicitGC来禁止。

二、并行回收GC(Parallel Scavenge)： server模式下默认GC方式，可经过-XX:+UseParallelGC强制指定； 并行的线程数为当cpu core<=8 ? cpu core : 3+(cpu core*5)/8或经过-XX:ParallelGCThreads=x来强制指定。如ScavengeBeforeFullGC为true（默认值），则先执行minor GC。

三、并行Compacting：可经过-XX:+UseParallelOldGC强制指定。

四、并发CMS：可经过-XX:+UseConcMarkSweepGC来强制指定。并发的线程数默认为:( 并行GC线程数+3)/4，也可经过ParallelCMSThreads指定。

    触发机制：
    一、当老生代空间的使用到达必定比率时触发；

     Hotspot V 1.6中默认为65%，可经过PrintCMSInitiationStatistics（此参数在V 1.5中不能用）来查看这个值究竟是多少；可经过CMSInitiatingOccupancyFraction来强制指定，默认值并非赋值在了这个值上，是根据以下公式计算出来的： ((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默认值： 40   CMSTriggerRatio默认值： 80。

     二、当perm gen采用CMS收集且空间使用到必定比率时触发；

     perm gen采用CMS收集需设置：-XX:+CMSClassUnloadingEnabled   Hotspot V 1.6中默认为65%；可经过CMSInitiatingPermOccupancyFraction来强制指定，一样，它是根据以下公式计算出来的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默认值： 40    CMSTriggerPermRatio默认值： 80。

      三、Hotspot根据成本计算决定是否须要执行CMS GC；可经过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策略。
      四、外部调用了System.gc，且设置了ExplicitGCInvokesConcurrent；须要注意，在hotspot 6中，在这种状况下如应用同时使用了NIO，可能会出现bug。

六、GC组合

1）默认GC组合

2）可选的GC组合

七、GC监测

1）jstat –gcutil [pid] [intervel] [count]
2）-verbose:gc // 能够辅助输出一些详细的GC信息；-XX:+PrintGCDetails // 输出GC详细信息；-XX:+PrintGCApplicationStoppedTime // 输出GC形成应用暂停的时间
-XX:+PrintGCDateStamps // GC发生的时间信息；-XX:+PrintHeapAtGC // 在GC先后输出堆中各个区域的大小；-Xloggc:[file] // 将GC信息输出到单独的文件中，建议都加上，这个消耗不大，并且对查问题和调优有很大的帮助。gc的日志拿下来后可以使用GCLogViewer或gchisto进行分析。
3）图形化的状况下可直接用jvisualvm进行分析。

4）查看内存的消耗情况

      （1）长期消耗，能够直接dump，而后MAT(内存分析工具)查看便可

      （2）短时间消耗，图形界面状况下，可以使用jvisualvm的memory profiler或jprofiler。

八、系统调优方法

步骤：一、评估现状 二、设定目标 三、尝试调优 四、衡量调优 五、细微调整

设定目标：

1）下降Full GC的执行频率？
2）下降Full GC的消耗时间？
3）下降Full GC所形成的应用停顿时间？
4）下降Minor GC执行频率？
5）下降Minor GC消耗时间？
例如某系统的GC调优目标：下降Full GC执行频率的同时，尽量下降minor GC的执行频率、消耗时间以及GC对应用形成的停顿时间。

衡量调优：

一、衡量工具
1）打印GC日志信息：-XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名}  -XX:+PrintGCTimeStamps
2）jmap：（因为每一个版本jvm的默认值可能会有改变，建议仍是用jmap首先观察下目前每一个代的内存大小、GC方式） 
3）运行情况监测工具：jstat、jvisualvm、sar 、gclogviewer

二、应收集的信息
1）minor gc的执行频率；full gc的执行频率，每次GC耗时多少？
2）高峰期什么情况？
3）minor gc回收的效果如何？survivor的消耗情况如何，每次有多少对象会进入老生代？
4）full gc回收的效果如何？（简单的memory leak判断方法）
5）系统的load、cpu消耗、qps or tps、响应时间

QPS每秒查询率：是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。在因特网上，做为域名服务器的机器性能常常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也便是最大吞吐能力。
TPS(Transaction Per Second)：每秒钟系统可以处理的交易或事务的数量。

尝试调优：

注意Java RMI的定时GC触发机制，可经过：-XX:+DisableExplicitGC来禁止或经过 -Dsun.rmi.dgc.server.gcInterval=3600000来控制触发的时间。

1）下降Full GC执行频率 – 一般瓶颈
老生代自己占用的内存空间就一直偏高，因此只要稍微放点对象到老生代，就full GC了；
一般缘由：系统缓存的东西太多；
例如：使用oracle 10g驱动时preparedstatement cache太大；
查找办法：现执行Dump而后再进行MAT分析；

（1）Minor GC后老是有对象不断的进入老生代，致使老生代不断的满
一般缘由：Survivor过小了
系统表现：系统响应太慢、请求量太大、每次请求分配的内存太多、分配的对象太大...
查找办法：分析两次minor GC之间到底哪些地方分配了内存；
利用jstat观察Survivor的消耗情况，-XX:PrintHeapAtGC，输出GC先后的详细信息；
对于系统响应慢能够采用系统优化，不是GC优化的内容；

（2）老生代的内存占用一直偏高
调优方法：① 扩大老生代的大小（减小新生代的大小或调大heap的 大小）；
减小new注意对minor gc的影响而且同时有可能形成full gc仍是严重；
调大heap注意full gc的时间的延长，cpu够强悍嘛，os是32 bit的吗？
② 程序优化（去掉一些没必要要的缓存）

（3）Minor GC后老是有对象不断的进入老生代
前提：这些进入老生代的对象在full GC时大部分都会被回收
调优方法：
① 下降Minor GC的执行频率；
② 让对象尽可能在Minor GC中就被回收掉：增大Eden区、增大survivor、增大TenuringThreshold；注意这些可能会形成minor gc执行频繁；
③ 切换成CMS GC：老生代尚未满就回收掉，从而下降Full GC触发的可能性；
④ 程序优化：提高响应速度、下降每次请求分配的内存、

（4）下降单次Full GC的执行时间
一般缘由：老生代太大了...
调优方法：1）是并行GC吗？   2）升级CPU  3）减少Heap或老生代

（5）下降Minor GC执行频率
一般缘由：每次请求分配的内存多、请求量大
一般办法：1）扩大heap、扩大新生代、扩大eden。注意点：下降每次请求分配的内存；横向增长机器的数量分担请求的数量。

（6）下降Minor GC执行时间
一般缘由：新生代太大了，响应速度太慢了，致使每次Minor GC时存活的对象多
一般办法：1）减少点新生代吧；2）增长CPU的数量、升级CPU的配置；加快系统的响应速度

细微调整：

首先须要了解如下状况：

① 当响应速度降低到多少或请求量上涨到多少时，系统会宕掉？

② 参数调整后系统多久会执行一次Minor GC，多久会执行一次Full GC，高峰期会如何？

须要计算的量：

①每次请求平均须要分配多少内存？系统的平均响应时间是多少呢？请求量是多少、多常时间执行一次Minor GC、Full GC？

②现有参数下，应该是多久一次Minor GC、Full GC，对比真实情况，作必定的调整；

必杀技：提高响应速度、下降每次请求分配的内存？

九、系统调优举例

     现象：一、系统响应速度大概为100ms；二、当系统QPS增加到40时，机器每隔5秒就执行一次minor gc，每隔3分钟就执行一次full gc，而且很快就一直full GC了；四、每次Full gc后旧生代大概会消耗400M，有点多了。

     解决方案：解决Full GC次数过多的问题

    （1）下降响应时间或请求次数，这个须要重构，比较麻烦；——这个是终极方法，每每可以顺利的解决问题，由于大部分的问题均是由程序自身形成的。

    （2）减小老生代内存的消耗，比较靠谱；——能够经过分析Dump文件（jmap dump），并利用MAT查找内存消耗的缘由，从而发现程序中形成老生代内存消耗的缘由。

    （3）减小每次请求的内存的消耗，貌似比较靠谱；——这个是海市蜃楼，没有太好的办法。

    （4）下降GC形成的应用暂停的时间——能够采用CMS GS垃圾回收器。参数设置以下：

     -Xms1536m -Xmx1536m -Xmn700m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

     -XX:CMSMaxAbortablePrecleanTime=1000 -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC

    （5）减小每次minor gc晋升到old的对象。可选方法：1） 调大新生代。2）调大Survivor。3）调大TenuringThreshold。

      调大Survivor：当前采用PS GC，Survivor space会被动态调整。因为调整幅度很小，致使了常常有对象直接转移到了老生代；因而禁止Survivor区的动态调整了，-XX:-UseAdaptiveSizePolicy，并计算Survivor Space须要的大小，因而继续观察，并作微调…。最终将Full GC推迟到2小时1次。

十、垃圾回收的实现原理

      内存回收的实现方法：1）引用计数：不适合复杂对象的引用关系，尤为是循环依赖的场景。2）有向图Tracing：适合于复杂对象的引用关系场景，Hotspot采用这种。经常使用算法：Copying、Mark-Sweep、Mark-Compact。

      Hotspot从root set开始扫描有引用的对象并对Reference类型的对象进行特殊处理。
      如下是Root Set的列表：1）当前正在执行的线程；2）全局/静态变量；3）JVM Handles；4）JNI 【 Java Native Interface 】Handles；

      另外：minor GC只扫描新生代，当老生代的对象引用了新生代的对象时，会采用以下的处理方式：在给对象赋引用时，会通过一个write barrier的过程，以便检查是否有老生代引用新生代对象的状况，若有则记录到remember set中。并在minor gc时，remember set指向的新生代对象也做为root set。

     新生代串行GC(Serial Copying)：

     新生代串行GC(Serial Copying)完整内存的分配策略：

     1）首先在TLAB（本地线程分配缓冲区）上尝试分配；
     2）检查是否须要在新生代上分配，如须要分配的大小小于PretenureSizeThreshold，则在eden区上进行分配，分配成功则返回；分配失败则继续；
     3）检查是否须要尝试在老生代上分配，如须要，则遍历全部代并检查是否可在该代上分配，如能够则进行分配；如不须要在老生代上尝试分配，则继续；
     4）根据策略决定执行新生代GC或Full GC，执行full gc时不清除soft Ref；
     5）如须要分配的大小大于PretenureSizeThreshold，尝试在老生代上分配，不然尝试在新生代上分配；
     6）尝试扩大堆并分配；
     7）执行full gc，并清除全部soft Ref，按步骤5继续尝试分配。  

     新生代串行GC(Serial Copying)完整内存回收策略
     1）检查to是否为空，不为空返回false；
     2）检查老生代剩余空间是否大于当前eden+from已用的大小，如大于则返回true，如小于且HandlePromotionFailure为true，则检查剩余空间是否大于以前每次minor gc晋级到老生代的平均大小，如大于返回true，如小于返回false。
     3）如上面的结果为false，则执行full gc；如上面的结果为true，执行下面的步骤；
     4）扫描引用关系，将活的对象copy到to space，如对象在minor gc中的存活次数超过tenuring_threshold或分配失败，则往老生代复制，如仍然复制失败，则取决于HandlePromotionFailure，如不须要处理，直接抛出OOM，并退出vm，如需处理，则保持这些新生代对象不动；

    新生代可用GC-PS

    完整内存分配策略
    1）先在TLAB上分配，分配失败则直接在eden上分配；
    2）当eden上分配失败时，检查须要分配的大小是否 >= eden space的一半，如是，则直接在老生代分配；
    3）如分配仍然失败，且gc已超过频率，则抛出OOM；
    4）进入基本分配策略失败的模式；
    5）执行PS GC，在eden上分配；
    6）执行非最大压缩的full gc，在eden上分配；
    7）在旧生代上分配；
    8）执行最大压缩full gc，在eden上分配；
    9）在旧生代上分配；
    10）如还失败，回到2。

   最悲惨的状况，分配触发屡次PS GC和屡次Full GC，直到OOM。

   完整内存回收策略
   1）如gc所执行的时间超过，直接结束；
   2）先调用invoke_nopolicy
       2.1 先检查是否是要尝试scavenge；
       2.1.1 to space必须为空，如不为空，则返回false；
       2.1.2 获取以前全部minor gc晋级到old的平均大小，并对比目前eden+from已使用的大小，取更小的一个值，如老生代剩余空间小于此值，则返回false，如大于则返回true；
       2.2 如不须要尝试scavenge，则返回false，不然继续；
       2.3 多线程扫描活的对象，并基亍copying算法回收，回收时相应的晋升对象到旧生代；
       2.4 如UseAdaptiveSizePolicy，那么从新计算to space和tenuringThreshold的值，并调整。
   3）如invoke_nopolicy返回的是false，或以前全部minor gc晋级到老生代的平均大小 > 旧生代的剩余空间，那么继续下面的步骤，不然结束；
   4）如UseParallelOldGC，则执行PSParallelCompact，如不是UseParallelOldGC，则执行PSMarkSweep。

    老生代并行CMS GC：

    优缺点：

    1） 大部分时候和应用并发进行，所以只会形成很短的暂停时间；
    2）浮动垃圾，没办法，因此内存空间要稍微大一点；
    3）内存碎片，-XX:+UseCMSCompactAtFullCollection 来解决；
    4） 争抢CPU，这GC方式就这样；
    5）屡次remark，因此总的gc时间会比并行的长；
    6）内存分配，free list方式，so性能稍差，对minor GC会有一点影响；
    7）和应用并发，有可能分配和回收同时，产生竞争，引入了锁，JVM分配优先。

十一、TLAB的解释

     堆内的对象数据是各个线程所共享的，因此当在堆内建立新的对象时，就须要进行锁操做。锁操做是比较耗时，所以JVM为每一个线在堆上分配了一块“自留地”——TLAB(全称是Thread Local Allocation Buffer)，位于堆内存的新生代，也就是Eden区。每一个线程在建立新的对象时，会首先尝试在本身的TLAB里进行分配，若是成功就返回，失败了再到共享的Eden区里去申请空间。在线程本身的TLAB区域建立对象失败通常有两个缘由：一是对象太大，二是本身的TLAB区剩余空间不够。一般默认的TLAB区域大小是Eden区域的1%，固然也能够手工进行调整，对应的JVM参数是-XX:TLABWasteTargetPercent。

参考文献：

一、Sun JDK 1.6 GC（Garbage Collector）  做者：毕玄