关于JVM的垃圾回收(GC) 这可能是你想了解的

目录

• 1 JVM中Java对象的分类
• 2 JVM的GC类型及触发条件
  • 2.1 Young GC
  • 2.2 Full GC
• 3 Java对象生成时的内存申请过程
• 3 Oracle JDK中的垃圾收集器
  • 3.1 串行收集器(Serial Collector)
  • 3.2 并行收集器(Parallel Collector)
  • 3.3 并发收集器(Concurrent Collector)
  • 3.4 G1收集器(Garbage First GC)
  • 3.5 其他概念说明
• 4 GC的配置参数
  • 4.1 参数名称的说明
    • 4.1.1 标准参数(-)
    • 4.1.2 非标准参数(-X)
    • 4.1.3 非稳定参数(-XX)
  • 4.2 串行GC参数
  • 4.3 并行GC参数(吞吐量优先)
  • 4.4 并发GC参数(响应时间优先)
  • 4.5 G1 GC参数
  • 4.6 通用GC参数
  • 4.7 其他说明
• 参考资料
• 版权声明

垃圾收集 (Garbage Collection) 机制是Java语言的一大优势特性, 为充分榨取JVM性能, 避免系统因垃圾收集不及时导致的OOM (OutOfMemory, 内存溢出)问题, 或内存饱和出现无法响应用户请求的情况, 就需要根据服务器配置及应用复杂度对GC策略进行优化, 以确保系统正常运行.

1 JVM中Java对象的分类

JVM根据运行于其中的对象的生存时间, 将它们分为3种, 并分别存放在JVM的不同内存区域中. 这种对象存放空间的管理方式叫做Generation管理方式.

(1) Young Generation (新生代, 又称年轻代): 用于存放"早逝"对象(即瞬时对象), 一般的Java应用中, 80%的对象都是"朝生息灭"的, 比如在创建对象或调用方法时使用的临时对象或局部变量.

(2) Tenured Generation (老年代): 用于存放"驻留"对象(即被引用较长时间的对象). 往往体现为一个大型程序中的全局对象或长时间被使用的对象.

(3) Perm Generation (永久代): 用于存放"永久"对象. 这些对象管理着运行于JVM中的类和方法.

2 JVM的GC类型及触发条件

2.1 Young GC

又叫Minor GC(次收集), Young GC经常发生, 且其每次消耗的时间较短.

—— 它只对Young Generation中的对象进行垃圾收集.

触发条件:

在Young Generation(新生代)的Eden区的空间不足以容纳新生成的对象时执行, 同时会将 Eden 区与 From Survivor 区中尚且存活的对象移动至空闲的 To Survivor 区中.

—— 程序运行过程中, 始终有一个 Survivor 区是完全处于空闲状态的, 如果不是, 说明应用程序出现故障了.

2.2 Full GC

又叫Major GC(主收集), 是对整个Java Heap中的对象(不包括永久代/元空间)进行垃圾收集.

Full GC操作耗时久, 对系统的性能影响较大, 因此在 JVM 的调优中, 很多工作是针对 Full GC 的调优 —— 要尽可能减少Full GC的频率.

Full GC 是一种"昂贵"的垃圾收集方式, 它要对整个Heap进行垃圾收集, 并做一定的空间整理, 这会使Stop-The-World的时间变长.

Full GC的触发条件:

(1) 年老代(Tenured)空间不足:

• 通过Minor GC后进入老年代的对象的体积大于老年代的可用空间;
• 由Eden块、From Space块向To Space复制存活对象时, 它们的体积大于To Space的大小, 系统就会把这些对象转存到老年代, 而老年代的可用空间小于这些对象的体积.

(2) System.gc()方法被显式调用, 系统建议执行Full GC, 但并不会立即执行 —— 非常影响程序性能, 建议禁止使用;

(3) 上一次GC之后Heap中各个区域空间的动态变化.

3 Java对象生成时的内存申请过程

(1) JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域;

(2) 当Eden区空间足够时, 内存申请结束. 否则执行下一步;

(3) JVM 试图释放在Eden区中所有不活跃的对象(即 出发Young GC), 释放后若Eden空间仍然不足以放入新对象时, JVM会试图将部分Eden区中活跃的对象迁移至Survivor区;

(4) Survivor区被用来作为Eden区及老年代的中间交换区域, 当老年代空间足够时, Survivor区中存活了一定次数的对象会被迁移到老年代;

(5) 当年老代空间不够时, JVM会在老年代进行完全的垃圾回收(Full GC);

(6) Full GC后, 若Survivor区及老年代仍然无法存放从Eden区复制过来的对象, 则会导致JVM无法在 Eden区为新生成的对象申请内存, 即出现 "Out of Memory".

OOM(Out of Memory)异常一般主要有如下2种原因:

(1) 老年代溢出, 表现为: java.lang.OutOfMemoryError:Javaheapspace, 这是最常见的情况, 产生的原因可能是: 设置的内存参数-Xmx过小或程序的内存泄露及使用不当问题.

(2) 持久代溢出，表现为: java.lang.OutOfMemoryError:PermGenspace, 通常由于持久代设置过小, 动态加载了大量 Java 类而导致溢出, 解决办法唯有将参数 -XX:MaxPermSize 调大(一般256MB能满足绝大多数应用程序需求).

3 Oracle JDK中的垃圾收集器

3.1 串行收集器(Serial Collector)

只有一条GC线程, 运行时需要暂停用户程序(Stop-The-World).

实现: Serial(用于新生代, 采用复制算法)、serial old(用于老年代, 采用标记-整理算法).

3.2 并行收集器(Parallel Collector)

有多条GC线程, 运行时也需要暂停用户程序(Stop-The-World).

实现: ParNew(用于新生代, 采用复制算法)、Parallel Scavenge(用于新生代, 采用复制算法)、Parallel Old(用于老年代, 采用标记-整理算法).

3.3 并发收集器(Concurrent Collector)

有一条或多条GC线程, 且需要在部分阶段暂停用户程序(Stop-The-World), 部分阶段与用户程序并发执行.

实现: Concurrent Mark Sweep(CMS, 用于老年代, 采用标记-清除算法).

并发(concurrent)与并行(parallel)的比较:

(1) 并发就是两个任务(A和B)需要独立运行, 在任务A结束之前, 任务B开始执行 —— 即表面上多个任务同时执行.

(2) 并行, 类比串行, 是微观概念, 即在每一个时刻都有多个任务在同时执行, 形象点理解为多管齐下, 串行可理解为单列队列, 同一时刻只能执行一个任务.

(3) 事实上, 并行是并发的一种实现方式, 还有一种并发的实现方式, 即我们熟悉的时间片切换 —— 任务A执行一段时间, CPU再切换到任务B执行一段时间, 如此交替执行. 时间片切换在微观上仍然是串行 —— 某一具体时刻只有一个任务在执行, 而在宏观上, 即一段时间内, 有多个任务得到了执行.

(4) 总结: 并行必须在多核多处理器或分布式系统(本质还是多核多处理器)中才能发生, 而单核处理器上只能发生时间片切换.

3.4 G1收集器(Garbage First GC)

G1垃圾回收器在 Oracle JDK 7 开始提供完整支持, 它是 server 型的 GC, 主要针对多核处理器和大内存的服务器, 能够以很高的概率 满足开发人员对停顿时间的要求, 同时还能保证高吞吐量.

(1) 与CMS收集器相比, G1收集器的优势:

① 基于标记-整理算法, 不会产生大量的内存碎片;

② 可以更加精确地控制停顿时间, 在不牺牲吞吐量前提下, 实现低停顿垃圾回收.

(2) G1收集器的实现原理:

G1收集器能够避免全区域的垃圾收集, 它把堆内存划分为大小固定的几个独立区域, 并跟踪这些区域的垃圾收集进度, 同时在后台维护一个优先级列表, 每次根据所允许的收集时间, 优先回收垃圾最多的区域.

—— **区域划分和优先级区域回收机制, 确保G1收集器可以在有限的时间内获得最高的垃圾收集效率. **

G1的长期目标是取代CMS (Concurrent Mark-Sweep Collector) 并发标记-清除收集器.

3.5 其他概念说明

(1) 为了更大程度地榨取机器性能, 新生代的收集器都使用了复制算法, 老年代的收集器都使用 标记-清除 或 标记-整理 算法. 关于各算法详情, 请参阅: JVM内存管理———垃圾搜集器参数精解.

(2) 在实际应用中, 需要对JVM的新生代、老年代分别选择合适的垃圾收集器.

(3) 这里新生代和老年代都分别有三种实现, 但由于收集器的实现方式不同, 部分组合无法一起配合工作, 经过验证, 这六种垃圾收集器只有六种可用组合.

4 GC的配置参数

4.1 参数名称的说明

4.1.1 标准参数(-)

所有 JVM 都必须支持这些参数的功能, 而且向后兼容, 如:

-client : 设置 JVM 使用 client 模式, 特点是启动速度比较快, 但运行时性能和内存管理效率不高. 通常用于客户端应用程序或开发调试; 在32位环境下直接运行 Java 程序默认启用该模式.

-server : 设置 JVM 使 server 模式, 特点是启动速度比较慢, 但运行时性能和内存管理效率很高, 适用于生产环境; 在具有64位能力的JDK环境下默认启用该模式.

4.1.2 非标准参数(-X)

各 JVM 厂商应该全部实现这些参数的功能, 但并不能保证这些厂商提供的 JVM 中都实现了这些功能, 且不保证向后兼容;

4.1.3 非稳定参数(-XX)

此类参数在各个 JVM 的实现中会有所不同, 将来也可能不被支持, 要慎重使用.

注意: 在"-XX:"后的参数若不需要赋值, 即只是用来配置开启或关闭相应选项, 则需要有 **"+" (开启) 或 "-" (禁止) **, 否则应用程序将在日志文件 (如 Tomcat 的日志文件 catalina.out ) 中抛出如下错误:

Missing +/- setting for VM option 'UseConcMarkSweepGC'.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

可以看出, 这里缺少了 "+/-" 符号, 导致虚拟机启动异常, 修改后即可正常启动.

4.2 串行GC参数

-XX:+UseSerialGC
# 使用 Serial & Serial Old 串行收集器(JDK 5以前的主要收集方式), 是client模式的默认设置.

4.3 并行GC参数(吞吐量优先)

-XX:+UseParNewGC
# 使用ParNew & Serial Old收集器, 即对新生代使用并行收集, 提高收集效率(缩短Young GC的时间), 不推荐. 

-XX:+UseParallelGC
# 使用Parallel Scavenge & Parallel Old并行收集器, 吞吐量优先, 会消耗更多内存, 是server模式的默认设置. 

-XX:+UseParallelOldGC
# 对老年代使用Parallel Old并行收集器(JDK 6开始支持). 

-XX:ParallelGCThreads=20
# 配置并行收集器的线程数, 即并行执行垃圾收集任务的线程个数.
# 此值最好与CPU处理器的个数相同(默认即相同).

-XX:GCTimeRatio=49
# 设置系统用作GC的时间比例, 如49, 则GC时间比为 1/(1+49) = 2%, 即Java用2%的时间来做垃圾收集.
# 如果此值设置过大, 即GC时间太少导致GC无法完成, JVM会压缩新生代的大小以适应此配置. 

-XX:MaxGCPauseMillis=100
# 设置每次新生代垃圾收集的最长毫秒值, 如果时间久而新生代的大小不足以支撑到此时间,
# JVM会自动调整新生代的大小以满足此值. 若仍然无法满足, 则会调整GCTimeRatio. 

-XX:+UseAdaptiveSizePolicy
# 使并行收集器自动设定Eden区的大小与相应的Survivor区的比例,
# 以达到目标系统规定的最低响应时间或收集频率等. 建议在使用并行收集器时始终开启此选项.

4.4 并发GC参数(响应时间优先)

-XX:+UseConcMarkSweepGC
# JDK 5开始提供支持, 以响应时间优先--即缩短Full GC的时间.
# JVM会根据系统配置自行设置使用ParNewGC & CMS(Serial Old作为替补)收集器.
# 建议在Heap Size较大且Full GC时间较长, 对响应时间的需求大于对吞吐量的需求, 能够承受垃圾回收线程和应用线程共享CPU资源等情况下使用. 

-XX:+UseCMSCompactAtFullCollection
# CMS是不会移动内存的, 此参数设置在每次Full GC后对老年代空间进行压缩整理, 会影响性能, 但是能减少内存碎片. 

-XX:CMSInitiatingOccupancyFraction=70
# 触发CMS收集器的内存占用阈值, 默认为90%: 当老年代内存空间使用率达到90%时, 就开始对老年代进行CMS并发垃圾收集.
# 这个参数设置不当, 将发生promotion failed(晋升失败). 

-XX:CMSFullGCsBeforeCompaction=10
# 由于并发收集器不对内存空间进行压缩整理, 所以运行一段时间后会产生"碎片", 使得运行效率降低. 此配置项用来设置在几次GC后触发一次内存整理.
# 此配置项即将被移除(JDK 8已不建议使用).

4.5 G1 GC参数

-XX:+UseG1GC
# 使用G1收集器

-XX:MaxGCPauseMillis=200
# 设置回收器的最大停顿毫秒值, 这是一个概率目标, JVM将尽最大努力去实现它. 

-XX:G1ReservePercent=15
# 设置堆的临时上限, 以防止因堆扩大失败而导致的异常. 默认值是10. 

-XX:G1HeapRegionSize=16
# 使用 G1 的 Java 堆细分为大小相等的区域(Region), 此选项是设置单个区域的大小,
# 默认值是基于堆大小的一种人体工效划分, 最小值是1Mb, 最大值是32Mb.
# 人体工效: 根据平台相关的默认选择和根据需求动态垃圾回收的行为统称为人体工效,
# 人体工效的作用就是可以通过少量的命令行选项就可以让JVM提供最合适的性能.

4.6 通用GC参数

-Xnoclassgc
# 禁用类垃圾收集, 能提高性能. 

-XX:MaxHeapFreeRatio=70
# GC过后堆的最大空闲空间比例, 避免过渡压缩

-XX:MinHeapFreeRatio=40
# GC过后堆的最小空闲空间比例, 避免过度膨胀

-XX:MaxTenuringThreshold=5
# 晋升老年代的最大年龄, 默认为15: 新生代对象在15次Minor GC后将被转移至老年代. -- 必须在0-15之间.
# 如果设置为0, 等同于去掉了新生代的空间, 新生代对象将会越过Survivor区直接进入老年代, 很快就会占满老年代发生Full GC.
# 同时, 这在老年代对象较多的应用中却可以提高效率.
# 如果将此值调大, 则新生代对象会在Survivor区进行多次复制, 即增加了对象在新生代的存活时间. 

-XX:PretenureSizeThreshold=10
# 晋升老年代的对象的大小, 默认为0. 比如设为10M, 则超过10M的对象将越过Eden区, 直接存入老年代.

-XX:+UseThreadPriorities
# 启用本地线程优先级API, 使java.lang.Thread.setPriority()生效, 不启用则无效

-XX:+DisableExplicitGC
# 禁用写在程序中的System.gc(), 即禁止开发人员调用gc()方法影响性能. 

-XX:+ExplicitGCInvokesConcurrent
# 配置System.gc()可以和应用程序一起并发执行.
# System.gc()用来回收不用的内存, 此方法只是"建议"JVM回收内存, 不能强制回收, 具体回收时机由JVM决定. 

-XX:TargetSurvivorRatio=90
# 允许90%的Survivor区被占用(JVM默认为50%), 提高对于Survivor区的使用率

-XX:SoftRefLRUPolicyMSPerMB=1
# Soft Reference(弱引用)在虚拟机中比在客户机中存活的时间更长, 其清除频率可用此命令来控制.
# 此命令用来指定每MB堆空间中Soft Reference存活的秒数, 默认值为1000毫秒: 对象的最后一个强引用被收集之后, 存活1秒钟.
# 这是个近似值: Soft Reference只会在垃圾收集时才会被清除, 而垃圾收集并不总是发生. 可改为0, 客户机中不使用就立即清除.

4.7 其他说明

(1) 在内存调优中, 内存设置越大, 处理请求的效率也就越高, 但同时垃圾收集所需要的时间也就越长, 在垃圾收集期间的处理效率肯定会受影响, 因此需要作出相应的权衡.

(2) 关于 CMS 收集器的 Promotion Failed 和 Concurrent Mode Failure :

• Promotion Failed, 晋升失败: 发生Young GC时, Eden区存活的对象 和 Eden区的From块中存活的对象, 两者的体积超过了Eden区中To块的大小, Young GC的悲观策略将使这些存活的对象都迁移到老年代, 而此时老年代的大小不足以容纳这些对象, 从而发生promotion failed , 程序将暂停很长时间.

• Concurrent Mode Failure, 并发修改失败: 在执行GC的过程中, 恰好有对象要晋升至老年代, 而此时老年代的空间不足, 从而造成Concurrent Mode Failure.

• 这两种情况都可能触发Full GC. 要注意不要一次性占用太多的内存, 或对JVM的配置进行一定的优化.

• CMSInitiatingOccupancyFraction的设置技巧: 参考: CMSInitiatingOccupancyFraction计算公式

  (Xmx-Xmn) * (1 - CMSInitiatingOccupancyFraction/100) >= (Xmn - Xmn/(SurvivorRatior+2))

  进而推断出：

  CMSInitiatingOccupancyFraction <= ( (Xmx-Xmn) - (Xmn - Xmn/(SurvivorRatior+2) ) ) / (Xmx-Xmn) * 100

参考资料

JVM系列三:JVM参数设置、分析

G1(Garbage-First)垃圾回收器

JVM内存管理——垃圾搜集器参数精解

版权声明

作者: 马瘦风

出处: 博客园 马瘦风的博客

您的支持是对博主的极大鼓励, 感谢您的阅读.

本文版权归博主所有, 欢迎转载, 但请保留此段声明, 并在文章页面明显位置给出原文链接, 否则博主保留追究相关人员法律责任的权利.