转载

JVM内存分配和垃圾回收

内存分布

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的优势更加明显

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

JVM内存分配和垃圾回收

JVM内存分配和垃圾回收

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]

总结

JVM内存分配和垃圾回收

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规范中方法区的实现,不过元空间与永久代之间最大的区别在于:元空间并不在虚拟机中,而是使用本地内存。因此默认情况下,元空间的大小仅受本地内存的限制。

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
原文  https://segmentfault.com/a/1190000022542270
正文到此结束
Loading...