记一次OOM(GC overhead limit exceeded)异常

记一次OOM(GC overhead limit exceeded)异常

最近在用thrift写一个文本挖掘的服务。在测试某个接口的时候出现如下异常:



服务端GC日志如下:

 


从日志分析,内存并未完全殆尽。新生代eden区只用了28%,而老年代也有37.4M((44032-5709)/1024)的空间可用。很奇怪为什么会报OOM异常呢,于是查了一下 GC overhead limit exceeded 参数



参数GC overhead limit exceeded是在jdk1.6引入的:

大概意思就如果系统大量的时间都在GC(98%)而回收的效果不明显(2% heap空间),就会抛出这个异常。实际这是一个JVM预判性的异常,也就是说抛出这个异常的时候没有真正的内存溢出。


 现在很容易得出结论:

  1. GC overhead limit exceeded 本质是一个预判性的异常,抛出该异常时系统没有真正的内存溢出。
  2. GC overhead limit exceeded 异常是由于垃圾回收效果不明显,或者垃圾回收效率不如分配效率高引起的。
  3. 通过增大对内存可以解决此问题,也可以用 -XX:-UseGCOverheadLimit 来显式关闭该功能。



此外还要感觉帮我分析问题的群友们。

### 解决构建项目过程中的GC Overhead Limit Exceeded错误 当遇到`java.lang.OutOfMemoryError: GC overhead limit exceeded` 错误时,表明垃圾回收器花费了过多的时间来尝试释放内存空间却只回收到了少量的可用堆空间[^1]。此问题通常发生在应用程序创建大量对象并频繁触发垃圾收集的情况下。 #### 增加JVM堆大小配置 为了缓解这个问题,在构建工具(如Maven, Gradle)中增加分配给JVM的最大堆大小是一个常见的解决方案。对于Gradle用户来说,可以通过修改gradle.properties文件设置更大的Xmx参数: ```properties org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError ``` 上述命令将最大堆尺寸设为4GB,并启用了在发生OOM时转储heap的功能以便后续分析。 #### 减少编译期间的对象生成量 优化代码结构减少不必要的临时对象创建可以有效降低GC压力。例如避免循环内部实例化大对象或使用StringBuilder代替String连接操作等措施均有助于改善性能表现。 #### 清理无用资源 定期清理工作区内的冗余依赖项以及不再使用的库文件能够帮助维持较低水平的基础占用率;另外确保IDE处于最新版本状态也可能带来意想不到的效果因为新版本往往包含了针对此类问题改进过的算法实现[^2]。 通过以上调整应该可以在很大程度上减轻甚至彻底消除该类异常的发生频率从而顺利完成项目的构建流程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值