性能文章>Java OOM 基础篇:常见的OutOfMemoryError 场景二 : GC overhead limit exceeded 问题详解>

Java OOM 基础篇:常见的OutOfMemoryError 场景二 : GC overhead limit exceeded 问题详解转载

2年前
9636221

Java OOM优化专题大纲目录

导语

此文来自于plumbr官网,plumbr作为一个常用的JVM 监测工具,官网有完整的oom和gc文章,本篇主要介绍了GC产生的原因以及解决办法,希望对大家有所帮助。

 

正文

第一篇:java.lang.OutOfMemoryError:Java heap space

第二篇:Java.lang.OutOfMemoryError: GC overhead limit exceeded

Java 运行时环境包含一个内置的垃圾回收 (GC)进程。在许多其他编程语言中,开发人员需要手动分配和释放内存区域,以便可以重用释放的内存。

另一方面,Java 应用程序只需要分配内存。每当内存中的特定空间不再使用时,称为垃圾收集的单独进程会为它们清除内存。垃圾收集手册中更详细地解释了 GC 如何检测内存的特定部分,但您可以相信 GC 能很好地完成它的工作。

GC开销超过极限:java.lang.OutOfMemoryError时显示错误您的应用程序已经耗尽了几乎所有的可用内存和GC一再未能清除它

1,是什么原因造成的?

java.lang.OutOfMemoryError:GC开销超过极限误差信号,你的应用程序花费太多的时间做垃圾收集太少的结果JVM的方式。默认情况下,如果 JVM 花费超过98% 的总时间进行 GC 并且在 GC 之后仅回收不到 2% 的堆,则JVM 被配置为抛出此错误。

java.lang.OutOfMemoryError:超出 GC 开销限制

如果这个 GC 开销限制不存在,会发生什么?请注意java.lang.OutOfMemoryError: GC 开销限制超出错误仅在几次GC 循环后释放 2% 的内存时才会抛出。这意味着 GC 能够清理的少量堆可能会再次被快速填满,从而迫使 GC 再次重新启动清理过程。这形成了一个恶性循环,CPU 100% 忙于 GC,无法完成任何实际工作。应用程序的最终用户面临极端的减速——通常在几毫秒内完成的操作需要几分钟才能完成。

因此,“ java.lang.OutOfMemoryError: GC 开销限制超出”消息是快速失败原则的一个很好的例子。

2,举个例子

在以下示例中,我们通过初始化 Map 并在未终止的循环中将键值对添加到映射中来创建“超出 GC 开销限制”错误:

class Wrapper {
  public static void main(String args[]) throws Exception {
    Map map = System.getProperties();
    Random r = new Random();
    while (true) {
      map.put(r.nextInt(), "value");
    }
  }

正如您可能猜到的那样,这不会有好的结局。事实上,当我们启动上述程序时:

java -Xmx100m -XX:+UseParallelGC Wrapper

我们很快就会遇到java.lang.OutOfMemoryError: GC 开销限制超出消息。但是上面的例子很棘手。当使用不同的 Java 堆大小或不同的GC 算法启动时,我的 Mac OS X 10.9.2 和 Hotspot 1.7.0_45 将选择不同的死亡。例如,当我以较小的 Java 堆大小运行程序时,如下所示:

java -Xmx10m -XX:+UseParallelGC Wrapper

应用程序将因更常见的java.lang.OutOfMemoryError: Java heap space消息而死亡,该消息在 Map resize 时抛出。当我使用除ParallelGC之外的其他垃圾收集算法运行它时,例如-XX:+UseConcMarkSweepGC-XX:+UseG1GC,错误被默认异常处理程序捕获并且没有堆栈跟踪,因为堆已经耗尽到甚至无法在异常创建时填充堆栈跟踪

这些变化确实是很好的例子,表明在资源受限的情况下,您无法预测应用程序的死亡方式,因此不要将您的期望建立在要完成的特定操作序列上。

3,解决办法是什么?

作为一个诙谐的解决方案,如果您只是想摆脱“ java.lang.OutOfMemoryError:GC开销限制超出”消息,将以下内容添加到您的启动脚本中即可实现:

-XX:-UseGCOverheadLimit

强烈建议不要使用这个选项——而不是解决问题,你只是推迟不可避免的问题:应用程序内存不足,需要修复。指定此选项只会用更熟悉的消息java.lang.OutOfMemoryError: Java heap space掩盖原始java.lang.OutOfMemoryError: GC 开销限制超出错误。

更严重的一点是 - 有时会触发 GC 开销限制错误,因为您分配给 JVM 的堆数量不足以满足在该 JVM 上运行的应用程序的需求。在这种情况下,你应该只分配更多的堆——请参阅本章末尾以了解如何实现这一点。

然而,在许多情况下,提供更多的 Java 堆空间并不能解决问题。例如,如果您的应用程序包含内存泄漏,添加更多堆只会推迟java.lang.OutOfMemoryError: Java heap space错误。此外,增加 Java 堆空间量也往往会增加影响应用程序吞吐量或延迟GC 暂停时间

如果您希望解决 Java 堆空间的潜在问题而不是掩盖症状,您需要弄清楚代码的哪一部分负责分配最多的内存。换句话说,您需要回答以下问题:

  1. 哪些对象占据堆的大部分
  2. 在源代码中分配这些对象的位置

此时,请确保在您的日历中清除几天(或 – 请参阅项目符号列表下方的自动方式)。以下是一个粗略的流程大纲,可以帮助您回答上述问题:

  • 从您的 JVM-to-troubleshoot 获取获取堆转储的许可。“转储”基本上是您可以分析的堆内容的快照,并包含应用程序在转储时保留在内存中的所有内容。包括密码、信用卡号等。
  • 指示您的 JVM 将其堆内存的内容转储到一个文件中。准备好进行一些转储,因为在错误的时间进行时,堆转储包含大量噪音,实际上可能毫无用处。另一方面,每个堆转储都会完全“冻结”JVM,所以不要太多,否则你的最终用户会开始发誓。
  • 找到一台可以加载转储的机器。当您的 JVM-to-troubleshoot 使用例如 8GB 的​​堆时,您需要一台超过 8GB 的​​机器来分析堆内容。启动转储分析软件(我们推荐Eclipse MAT,但也有同样好的替代品)。
  • 检测到最大堆消耗者的 GC 根的路径。我们已经覆盖在一个单独的后这一活动在这里。不用担心,一开始会觉得很麻烦,但经过几天的挖掘,你会好起来的。
  • 接下来,您需要弄清楚在源代码中的何处分配了具有潜在危险的大量对象。如果您对应用程序的源代码有很好的了解,则希望通过几次搜索就能做到这一点。当您运气不佳时,您将需要一些能量饮料来辅助。

或者,我们建议Plumbr,这是唯一具有自动根本原因检测功能的 Java 监控解决方案。在其他性能问题中,它捕获所有java.lang.OutOfMemoryError并自动为您提供有关最需要内存的数据结构的信息。它负责在幕后收集必要的数据——这包括有关堆使用情况的相关数据(只有对象布局图,没有实际数据),以及一些您甚至在堆转储中都找不到的数据。它还会为您进行必要的数据处理——在 JVM 遇到java.lang.OutOfMemoryError 时立即进行。这是来自 Plumbr 的java.lang.OutOfMemoryError事件警报示例:

无需任何额外的工具或分析,您就可以看到:

  • 哪些对象消耗的内存最多(271 个com.example.map.impl.PartitionContainer实例消耗了 248MB 总堆中的 173MB)
  • 这些对象的分配位置(大部分分配在MetricManagerImpl类中,第 304 行)
  • 当前引用这些对象的是什么(直到 GC 根的完整引用链)

有了这些信息,您就可以放大潜在的根本原因,并确保将数据结构修剪到适合您的内存池的级别。

但是,当您从内存分析或阅读 Plumbr 报告得出的结论是内存使用是合法的并且源代码中没有任何更改时,您需要让您的 JVM 有更多的 Java 堆空间才能正常运行。在这种情况下,更改您的 JVM 启动配置并在您的启动脚本中添加(或增加值,如果存在)仅一个参数:

java -Xmx1024m com.yourcompany.YourClass

在上面的例子中,Java 进程被分配了 1GB 的堆。修改最适合您的 JVM 的值。但是,如果结果是您的 JVM 仍然因 OutOfMemoryError 而死亡,您可能仍然无法避免上述手动或 Plumbr 辅助分析。

点赞收藏
金色梦想

终身学习。

请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

一次 GDB 源码角度分析 jvm 无响应问题

一次 GDB 源码角度分析 jvm 无响应问题

21
2