Java随手记

Java随手记【3】OutOfMemeory 分析 GC overhead limit exceeded

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 02:07 min
[INFO] Finished at: 2020-04-30T10:22:10+02:00
[INFO] Final Memory: 40M/444M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:
sonar (default-cli) on project cats: Can not execute Findbugs: java.lang.OutOfMemoryError: GC overhead limit exceeded -> [Help 1]
[ERROR] 

GC overhead limit exceeded 是 Java HotSpot VM 1.6 增加的一个新的策略，它允许VM在Heap内存空间使用完之前能更早的检测潜在的OOM error，允许VM 终止正在运行的程序线程并报告OOM error。
该策略的满足条件基于VM GC的运行时间和频率，比如，GC 允许时间太久， Full GC轮训频率过高，或太长时间花费在GC 上， 都会导致这个error。
Sun 官方声明如下：
如果在垃圾回收上花费了太多时间，则并行/并发收集器将抛出OutOfMemoryError：
如果在垃圾回收中花费了总时间的98％以上，并且回收的堆少于2％，则会抛出OutOfMemoryError 。 此功能旨在防止应用程序长时间运行，而由于堆太小而几乎没有进展，甚至没有进展。
如有必要，可以通过在命令行中添加选项 -XX：-UseGCOverheadLimit 来禁用此功能。

此新策略在某种程度上很有用，因为它可以防止JVM完全挂起，并允许你在整个JVM变得无响应之前执行一些操作，例如数据收集，JVM堆转储，JVM线程转储等。

某些情况下，此策略也会产生不良影响。由于超出了GC 开销上限，Java应用程序处理大型内存分配/块 时 可能会看到更频繁的OOM error。 应用程序长时间处理GC 使得健康的整体内存使用情况也会受到影响。在上述情况下，您可能需要考虑关闭此策略，并查看它是否有助于您的环境稳定。

本例是在使用mvn 命令构建工程时出现的，
mvn clean compile sonar:sonar -Dsonar.analysis.mode=preview
maven SonarQube 插件中 sonar-findbugs-plugin 功能会被执行。
“In general, FindBugs requires lots of memory and a relatively fast CPU. For large applications, 1024M or more of heap space may be required. By default, FindBugs allocates 768M of heap space. ”
But the project in the development server only requests : JAVA_TOOL_OPTIONS = -Xmx500m
一般情况下，FindBugs 要求相对高速的CPU并会消耗大量内存。默认情况下，FindBugs 会申请768M heap 空间。对于大型项目来说，可能需要1024 M或者更多的heap空间。
个人觉得，想要解决这个问题除了扩大内存目前也没有别的好方法。