JVM内存分配和垃圾回收

本文部分图片来自网络

内存分布

对象一般在堆上分配，但JVM支持一种在栈上分配内存的机制。
通过-XX:+DoEscapeAnalysis开启逃逸分析(默认开启)，JVM会针对不会逃逸的对象分配在栈上。好处是，栈可以自动弹出，不需要垃圾回收参与处理这些对象。

此外TLAB(Thread Local Allocation Buffer)是一个线程独占的堆空间。一般的堆空间是共享的，在内存分配时，多个线程需要同步，但TLAB区域由于线程独占，所以不必在分配内存时进行同步。TLAB本身占用eden区域。

关于逃逸分析和TLAB参见jvm 优化篇-（4）-栈上分配与逃逸分析 -XX:+DoEscapeAnalysis -XX:+UseTLAB -XX:TLABRefillWasteFraction

分代算法

现代垃圾回收的基本算法是标记清除(Mark-Sweep)，但依然要面临内存碎片的问题。JVM采用分代机制解决内存碎片问题。

新生代采用复制算法。新生代的特点是，大部分对象是可以回收的。新生代区进一步分为eden区、from区、to区。from区和to区是两块大小相同内存区域，有时也叫S0/S1，作用是交换存活对象。新生代内存分配发生在eden区。当新生代需要垃圾回收时，假设此时S0中是上一次GC留下来的存活对象，那么eden中的存活对象和S0中的对象都将复制到S1（并对齐），然后eden和S0可以直接清空；下一次垃圾回收时，eden和S1的存活对象复制到S0（并对齐）。所以说S0和S1相互交换存活对象。如果S0和S1无法容纳对象，那么部分对象将进入老年代区。由于新生代中大部分对象是可以回收的，所以采用这种复制算法压缩内存最为高效。

老年代采用标记压缩算法。因为老年代活动对象多，垃圾对象少。

分区算法

G1采用分区算法。分区的思想是将推内存划分为多个区，如果每次只收集若干区域，而不是整个堆，可以有效的控制停顿时间。

垃圾回收器的发展

垃圾回收器经历了串行、并行(多线程)、并发(不阻塞应用)的发展。参考[深入JVM读书笔记（四）——Java的垃圾收集器]

• Serial/Serial Old: 串行收集器，收集过程会阻塞应用程序线程，并用单线程完成收集
• ParNew: 适用于新生代的并行收集器，收集过程会阻塞应用程序线程，并用多个线程完成对新生代区的收集
• Parallel Scavenge: 与ParNew类似，但可以调节停顿时间和吞吐等参数
• Parallel Old: 针对老年代的并行收集
• CMS: 针对老年代，可针对某些收集阶段支持并发收集。意味着某些情况下可以不阻塞应用程序运行
• G1: 1.7开始引入，同时具有并行、并发能力，同时支持新生代和老年代，并采用分区的思想控制停顿时间。当Java堆非常大的时候，G1的优势更加明显

早期的垃圾收集器可以组合使用，如下图

G1

G1收集器的总体效果是好于CMS的，有更好的自我调节能力而G1从JDK9开始才是默认垃圾回收器。所以JDK8的情况下，最好主动设置G1垃圾回收器：

-XX:+UseG1GC

G1收集器用Region来划分内存，虽然逻辑上依然保留新生代和老年代，但是新生代和老年代是由若干Region组成的，并且并不一定要求连续。每个分区Region也不会确定地为某个代服务，可以按需在新生代和老年代之间切换。

18.657: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 26M->24M(32M), 0.0025448 secs]
18.659: [GC concurrent-root-region-scan-start]
18.660: [GC concurrent-root-region-scan-end, 0.0008815 secs]
18.660: [GC concurrent-mark-start]
18.696: [GC concurrent-mark-end, 0.0357099 secs]
18.696: [GC remark, 0.0037490 secs]
18.703: [GC cleanup 24M->24M(32M), 0.0004163 secs]
18.892: [GC pause (G1 Evacuation Pause) (young) 26M->25M(32M), 0.0027587 secs]
19.014: [GC pause (G1 Evacuation Pause) (mixed) 26M->24M(32M), 0.0042025 secs]

上面是一段G1的gc日志

• initial-mark: 初始标记，伴随一个新生代GC，有暂停
• concurrent-root-region-scan-start/end: 根区域扫描，并发的无暂停
• concurrent-mark-start/end: 并发标记，并发的无暂停
• remark: 重新标记，有暂停
• cleanup: 独占清理，有暂停
• young: 新生代GC，有暂停
• mixed: 同时有新生代和老年代GC，无暂停。在并发标记中得知哪些Region垃圾比例比较高，会在这个阶段对这些Region进行清理（Gargage First的由来）

并发标记可能被young gc和full gc打断，例如下面的日志展示了被full gc中断的concurrent-mark

34.036: [GC concurrent-mark-start]
34.037: [Full GC (Allocation Failure)  31M->31M(32M), 0.0912206 secs]
34.128: [Full GC (Allocation Failure)  31M->31M(32M), 0.0905478 secs]
34.219: [GC concurrent-mark-abort]
34.219: [GC pause (G1 Evacuation Pause) (young) 31M->31M(32M), 0.0084531 secs]
34.228: [GC pause (G1 Evacuation Pause) (young) (initial-mark) 31M->31M(32M), 0.0067091 secs]

总结

G1的参数

选项	说明
-XX:MaxGCPauseMillis	设置最大GC停顿时间(GC pause time)指标(target). 这是一个软性指标(soft goal), JVM 会尽量去达成这个目标.
-XX:InitiatingHeapOccupancyPercent	启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环". 默认值为 45
-XX:ParallelGCThreads	设置垃圾收集器在并行阶段使用的线程数,默认值随JVM运行的平台不同而不同

常见OOM

• StackOverFlowError: 栈内存溢出，用于深度方法调用（循环递归）
• OutOfMemoryError: Java heap space。用于变量申请的空间大于jvm的最大值
• OutOfMemoryError: GC overhead limit exceed。GC回收的过长时会抛出OutOfMemoryError,过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存，连续多次GC都只回收了不到2%的极端情况下才会抛出。假如不抛出GC overhead limit 错误会发生什么情况？那就是GC清理的这么点内存很快会再次填满，迫使GC再次执行，这样就形成恶性循环，CPU使用率一直是100%，而GC却没有任何成果
• OutOfMemoryError: Direct buffer memory。堆外内存溢出，主要呈现在写NIO程序经常使用ByteBuffer来读取或者写入数据，这是一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据
• OutOfMemoryError: unable to create new native thread。应用创建了太多线程
• OutOfMemoryError: Metaspace。元空间的本质和永久代类似，都是对JVM规范中方法区的实现，不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此默认情况下，元空间的大小仅受本地内存的限制。

JDK工具

jstat

jstat -gc <pid>

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
1088.0 1088.0  0.0   117.2   8704.0   8641.6   21888.0    21888.0   24832.0 24320.1 2560.0 2340.1     26    0.134  13      0.810    0.944

• S0C：第一个幸存区的大小
• S1C：第二个幸存区的大小
• S0U：第一个幸存区的使用大小
• S1U：第二个幸存区的使用大小
• EC：eden区的大小
• EU：eden区的使用大小
• OC：老年代大小
• OU：老年代使用大小
• MC：方法区大小
• MU：方法区使用大小
• CCSC:压缩类空间大小
• CCSU:压缩类空间使用大小
• YGC： 年轻代垃圾回收次数
• YGCT：年轻代垃圾回收消耗时间
• FGC： 老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间

jinfo

查看进程的jvm flag。例如，验证DoEscapeAnalysis默认是开启的

$ jinfo -flag DoEscapeAnalysis 6953
-XX:+DoEscapeAnalysis

也可以动态修改部分参数

$ jinfo -flag +PrintGCDetails 6953

jmap

常用于dump进程的堆快照

jmap -dump:format=b,file=/tmp/heap.hprof <pid>

堆快照文件可用jhat, MAT等工具进行分析。堆快照也可以通过设置-XX:+HeapDumpOnOutOfMemoryError使jvm在发生OOM时自动产生。

jmap还可以生成对象统计信息，添加live会强制进行一次full gc。

jmap -histo[:live] <pid>

jhat

jdk自带的堆分析工具，需要事先得到堆快照文件

jhat /tmp/heap.hprof

该命令会启动一个7000端口的http服务，通过页面可以查看对象统计信息。还支持一种叫OQL(Object Query Language)的查询语句(类似SQL)检索对象。jhat比较简单，紧急情况下用于生产的在线分析还可以，相比较而言类似MAT这样的工具更适合做细致的离线分析。

jstack

栈分析工具，死锁分析

jstatd

从名字可以看出，这是一个常驻进程。功能是为本机的jvm开启一个RMI代理，默认监听在1099端口。这样可以在远程主机上通过命令来访问本机jvm进程的性能。如：

# 列出<ip>主机上的jvm进程
jps <ip>:1099

# 显示<ip>主机上进程号为460的进程的gc统计
jstat -gcutil 460@<ip>:1099

jmx远程调优

java进程通过开启jmx远程，可支持远程监控和分析：

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=8888
-Dcom.sun.management.jmxremote.ssl=false

在远程，用jconsole或者更好用的jvisualvm，连接到进程进行监控和分析。参考Java - jmx远程调优