CMS发生FullGc分析


fullgc的原因

Full GC触发条件:

(1)System.gc()方法的调用

该方法不一定执行,但是执行的时候是fullgc。

(2)老年代空间不足

老年代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象,当执行Full GC后空间仍然不足,则抛出如下错误:

java.lang.OutOfMemoryError: Java heap space

为避免以上两种状况引起的Full GC,调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。

(3)方法区空间不足

在HotSpot虚拟机中又被习惯称为永生代或者永生区,Permanet Generation中存放的为一些class的信息、常量、静态变量等数据,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了,那么JVM会抛出如下错误信息:

java.lang.OutOfMemoryError: PermGen space

为避免Perm Gen占满造成Full GC现象,可采用的方法为增大Perm Gen空间或转为使用CMS GC。

(4)CMS GC时出现promotion failed和concurrent mode failure

对于采用CMS进行老年代GC,要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Full GC。

promotion failed是在进行Minor GC时,survivor space放不下、对象只能放入老年代,而此时老年代也放不下造成的;concurrent mode failure是在

执行CMS GC的过程中同时有对象要放入老年代,而此时老年代空间不足造成的(有时候“空间不足”是CMS GC时当前的浮动垃圾过多导致暂时性的空间不足触发Full GC)。

措施为:增大survivor space、老年代空间或调低触发并发GC的比率,但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。

对于这种状况,可通过设置-XX: CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。

(5)Minor GC晋升到老年代的平均大小大于老年代的剩余空间

Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象,在进行Minor GC时,做了一个判断,如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间,那么就直接触发Full GC。

例如程序第一次触发Minor GC后,有6MB的对象晋升到旧生代,那么当下一次Minor GC发生时,首先检查老年代的剩余空间是否大于6MB,如果小于6MB,则执行Full GC。

当新生代采用PS GC时,方式稍有不同,PS GC是在Minor GC后也会检查,例如上面的例子中第一次Minor GC后,PS GC会检查此时旧生代的剩余空间是否大于6MB,如小于,则触发对旧生代的回收。

(6)堆中分配很大的对象

所谓大对象,是指需要大量连续内存空间的java对象,例如很长的数组,此种对象会直接进入老年代,而老年代虽然有很大的剩余空间,但是无法找到足够大的连续空间来分配给当前对象,此种情况就会触发JVM进行Full GC。

为了解决这个问题,CMS垃圾收集器提供了一个可配置的参数,即-XX:+UseCMSCompactAtFullCollection开关参数,用于在“享受”完Full GC服务之后额外免费赠送一个碎片整理的过程,内存整理的过程无法并发的,空间碎片问题没有了,但提顿时间不得不变长了,JVM设计者们还提供了另外一个参数 -XX:CMSFullGCsBeforeCompaction,这个参数用于设置在执行多少次不压缩的Full GC后,跟着来一次带压缩的。

补充2种fullgc情况

1.未指定老年代和新生代大小,堆伸缩时会产生fullgc。

2.直接内存

Cms退化为serial gc的情况

Minor GC后存活的对象晋升到老年代时由于悲观策略的原因,有两种情况会触发Full GC,:

1.之前每次晋升的对象的平均大小 > 老年代剩余空间;

2.Minor GC后存活的对象超过了老年代剩余空间。

这两种情况都是因为老年代会为新生代对象的晋升提供担保,而每次晋升的对象的大小是无法预测的,所以只能基于统计,1个是基于历史平均水平,一个是基于下一次可能要晋升的最大水平。这两种情况都是属于promotion failure。

CMS失败,发生concurrent mode failure会引起Full GC,这种情况下会使用Serial Old收集器,是单线程的,对GC的影响很大。concurrent mode failure产生的原因是老年代剩余的空间不够,导致了和gc线程并发执行的用户线程创建的大对象(由PretenureSizeThreshold控制新生代直接晋升老年代的对象size阀值)不能进入到老年代,只要stop the world来暂停用户线程,执行GC清理。可以通过设置CMSInitiatingOccupancyFraction预留合适的CMS执行时剩余的空间。

新生代直接晋升到老年代的大对象超过了老年代的剩余空间,引发Full GC。

注意于promotion failure的区别,promotion failure指的是Minor GC后发生的担保失败。

Perm区回收

Perm永久代空间不足会触发Full GC,可以让CMS清理永久代的空间。设置CMSClassUnloadingEnabled即可。

System.gc()引起的Full GC,可以设置DisableExplicitGC来禁止调用System.gc引发Full GC 。

使用CMS(ConcMarkSweep)策略时,必须有:-XX:+CMSPermGenSweepingEnabled 和-XX:+CMSClassUnloadingEnabled
来配合同时启用,才可以对PermGen进行GC(实际主要参数为:-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled  -XX:+CMSPermGenSweepingEnabled)。

调优方案

(1)观察gc情况,结合代码,调整线程数,可以减少fullgc次数,但是计算时间消耗很大。

(2)由于这种频繁的fullgc只是在早上汇总时候产生,并且正常每天一次,所以解决方案是更换gc,将由一台机器进行汇总,其他机器不影响。

jvm的gc相关参数:

-Xmx4096m -Xms4096m

-XX:MetaspaceSize=256m

-XX:MaxMetaspaceSize=512m

-XX:SurvivorRatio=8

-XX:ParallelCMSThreads=8

-XX:+CMSParallelRemarkEnabled  开启降低标记停顿

-XX:+ExplicitGCInvokesConcurrent

-XX:+CMSPermGenSweepingEnabled

-XX:+CMSClassUnloadingEnabled

-XX:+PrintGCCause

-XX:+PrintGCDetails

-XX:+PrintHeapAtGC

-XX:+PrintTenuringDistribution

-XX:+UseConcMarkSweepGC

-XX:+PrintGCTimeStamps

-XX:+PrintGCDateStamps

-XX:CMSFullGCsBeforeCompaction=0

-XX:+UseCMSCompactAtFullCollection

-XX:CMSInitiatingOccupancyFraction=80

04-02
### Full GC 的定义 在 Java 中,Full GC 是指垃圾回收器对整个堆内存(包括年轻代和老年代)以及方法区进行全面清理的过程。通常情况下,GC 主要集中在年轻代上执行 Minor GC,而当对象无法放入年轻代或者需要分配较大的对象时,则会触发 Full GC[^1]。 Full GC 可能由多种原因引起,例如老年代空间不足、永久代/元空间满载、System.gc() 被显式调用等。每次发生 Full GC 都会对应用程序性能造成显著影响,因为它会导致应用线程暂停(Stop-The-World),直到完成所有的垃圾回收操作为止。 --- ### 解决 Full GC 问题的方法 #### 方法一:分析内存泄漏 如果程序存在内存泄漏,可能会频繁触发 Full GC。为了检测是否存在内存泄漏,可以使用工具如 JConsole 或者 VisualVM 来监控 JVM 堆内存的变化趋势。此外,还可以通过以下方式定位问题: - 使用 `jmap` 工具生成堆转储文件并利用 `jhat` 进行分析。 - 如果怀疑某些大对象未被销毁,可以通过启用 `-XX:+HeapDumpOnOutOfMemoryError` 参数,在 OOM 发生时自动生成堆转储文件以便后续排查[^2]。 #### 方法二:调整 JVM 参数优化 GC 行为 合理配置 JVM 启动参数能够有效减少 Full GC 的频率及其带来的停顿时间。常见的做法有以下几个方面: - **增大堆大小**:适当增加最大堆容量 (`-Xmx`) 和初始堆容量 (`-Xms`) ,从而降低因内存紧张而导致的 Full GC 次数。 - **选用合适的收集器**:针对不同应用场景选择恰当类型的垃圾回收算法,比如 G1 收集器适合处理大规模数据集的应用场景;CMS(Concurrent Mark Sweep)则适用于低延迟需求较高的环境。 - **调节新生代比例**:通过设置 `-XX:NewRatio=N` 控制新生代相对于整个堆的比例,默认值通常是 2 (即新生代占总堆的一半)。对于创建短生命周期临时对象较多的情况可考虑减小该数值来扩大新生代区域范围。 #### 方法三:避免不必要的引用保留 长时间持有无用的对象引用也是引发 Full GC 的常见原因之一。因此建议开发者遵循如下原则以改善此状况: - 定期释放不再使用的资源实例变量。 - 对于缓存机制中的条目设定合理的过期策略及时淘汰陈旧项。 - 尽量采用弱引用(WeakReference)/软引用(SoftReference)代替强引用存储可能很快会被丢弃的数据结构成员[^3]。 #### 方法四:理解 C++ 和 Java 在内存管理上的差异 值得注意的是,虽然两者都涉及到了自动化的内存管理过程,但是它们实现的具体细节却有很大区别。例如,在 C++ 中允许程序员定义析构函数用于手动控制资源释放时机;而在 Java 当中由于引入了垃圾回收机制所以无需担心此类问题[^4] 。然而这也意味着开发人员必须更加关注如何编写高效且不会干扰到正常运行状态下的代码逻辑设计思路。 --- ### 总结 综上所述,解决 Full GC 问题是提升 Java 应用性能的重要环节之一。这不仅涉及到深入理解其背后的工作原理还需要掌握一系列实用技巧来进行针对性调试与优化工作。只有这样才能真正达到既满足业务功能又兼顾用户体验双重目标的最佳效果。 ```bash # 示例命令行查看当前 JVM 的 GC 日志信息 java -verbose:gc -Xloggc:/path/to/gc.log YourApplicationClass ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值