Java 堆内存溢出梗概分析

昵称63557093 2020-02-27

展开全文

　　任何使用过基于 Java 的企业级后端应用的软件开发者都会遇到过这种低劣、奇怪的报错，这些报错来自于用户或是测试工程师： java.lang.OutOfMemoryError：Java heap space。

　　为了弄清楚问题，我们必须返回到算法复杂性的计算机科学基础，尤其是“空间”复杂性。如果我们回忆，每一个应用都有一个最坏情况特征。具体来说，在存储维度方面，超过推荐的存储将会被分配到应用程序上，这是不可预测但尖锐的问题。这导致了堆内存的过度使用，因此出现了内存不够的情况。

　　这种特定情况最糟糕的部分是应用程序不能修复，并且将崩溃。任何重启应用的尝试 - 甚至使用最大内存(-Xmx option)- 都不是长久之计。如果不明白什么导致了堆使用的膨胀或突出，内存使用稳定性(即应用稳定性)就不能保障。于是，什么才是更有效的理解关于内存的编程问题的途径?当内存溢出时，明白应用程序的内存堆和分布情况才能回答这个问题。

　　在这一前提下，我们将聚焦以下方面：

　　当内存溢出时，获取到 Java 进程中的堆转储。

　　明白应用程序正在遭遇的内存问题的类型。

　　使用一个堆分析器，可以使用 Eclipse MAT 这个优秀的开源项目来分析内存溢出的问题。

　　配置应用，为堆分析做准备

　　任何像内存溢出这种非确定性的、时有时无的问题对于事后的分析都是一个挑战。所以，最好的处理内存溢出的方法是让 JVM 虚拟机转储一份 JVM 虚拟机内存状态的堆文件。

　　Sun HotSpot JVM 有一种方法可以引导 JVM 转储内存溢出时的堆状态到一个文件中。其标准格式为 .hprof 。所以，为了实现这种操作，向 JVM 启动项中添加 XX:+HeapDumpOnOutOfMemoryError 。因为内存溢出可能经过很长一段时间才会发生，向生产系统增加这一选项也是必须的。

　　如果堆转储 .hprof 文件必须被写在一个特定的文件系统位置，那么就添加目录途径到 XX:HeapDumpPath 。只需确保该应用对于指定目录途径始终拥有写入权限。

　　原因分析

　　101：了解内存溢出错误的本质

　　当尝试去评估和了解一个内存溢出错误时，最先做的事情应该是观察内存增长特征。根据情况做出可能性的评估：

　　尖峰状：这种类型的内存溢出在某种类型的加载上会是比较激烈的。当 JVM 分配内存给 20 个用户时，应用程序可以正常运行。但是，如果到第 100 个用户时可能会遭遇到内存峰值，从而导致内存溢出。有两种可能的办法去解决这个问题。

　　泄露：由于某些编程问题，内存使用随着时间的推移逐渐增加。

　　拥有良性垃圾回收机制的健康图表

　　健康一段时间后，随时间推移而泄露的图表

　　引起内存使用凸起、导致内存溢出的内存图表

　　在我们了解导致使用率激增的内存问题的本质之后，基于从对分析中得到的推断，下面的这些方法或许可以用来避免遭遇内存溢出的错误。

　　解决内存问题

　　修复引起内存溢出的代码：由于应用在某段时间内增量添加了一个对象而没有清除其引用(来自正在运行的应用程序的对象引用)，导致不得不修复程序错误。例如，这一错误可能是插入了一个哈希表, 其中的业务对象会逐渐增加，然而业务逻辑和事务在完成之后并没有删除这些对象。

　　增加内存最大值作为一种修复方法。在了解了运行内存特征和堆之后，可能必须增加分配的最大堆内存来避免再次发生内存溢出，因为推荐的最大内存值不能够满足应用程序的稳定性。所以，应用程序可能不得不基于堆分析器的评估，将 Java -Xmx 的 flag 信息更新成一个更高值后再来运行。

　　堆分析

　　下面我们将详细分析如何使用一个堆分析工具来分析堆转储。在示例中，将使用到 Eclipse 基金会的开源工具 MAT 。

　　使用 MAT 进行堆分析

　　是时候进行深入探讨了。我们将通过一系列的步骤，帮助探索在 MAT 中的不同表现和视图，以获取一个堆内存溢出的示例并思考分析。

　　1. 打开内存溢出错误发生时产生的 .hprof 堆文件。确保复制转储文件到一个专门的文件夹下，因为 MAT 会创建许多索引文件：文件 - 打开

　　2. 打开转储文件，有内存泄漏嫌疑报告和组件报告的选项。选择运行泄漏嫌疑报告。

　　3. 泄漏嫌疑表打开后，在预览窗口的饼状图会展示在每个对象基础上保留内存的分布情况。它显示了内存中的最大对象(拥有最高保留内存的对象 —— 累积的内存和引用的对象)。

　　4. 上面的饼图通过聚合拥有最高内存引用(本身内存和总内存)的对象来展示 3 个问题嫌疑人。

　　让我们逐一分情况查看，评估它是否是内存溢出错误的根本原因。

　　可疑点 1

　　由 “” 加载的 454,570 个 “java.lang.ref.Finalizer” 实例占用了 790,205,576(47.96%)个字节。

　　这就是告诉我们有 454,570 个 JVM finalizer(终结器)实例占据了分配的应用内存的近 50 %。

　　假设读者知道 Java Finalizer 是做什么的，上面的信息会让我们明白什么呢?

　　入门阅读：http:///questions/2860121/why-do-finalizers-have-a-severe-performance-penalty

　　本质上，开发者编写了一些定制化的终结器去释放一个实例的资源。这些由终结器收集的实例不在 JVM 使用单独队列的垃圾回收算法的范围之内。实际上，这种途径比起垃圾回收机制的清理路径更长。所以现在我们应该努力搞清楚这些终结器到底终结了什么?

　　也或许是可疑点 2 ，占据了 20% 的 sun.security.ssl.SSLSocketImpl 。我们能确认是否这些就是要被终结器终结的实例吗?

　　可疑点 2

　　现在，让我们打开在 MAT 顶部的工具按钮下面的 Dominator 视图。我们会看到所有的列出的类实例，经由 MAT 解析展示出有效的堆存储。

　　下一步，在 Dominator 视图，我们尝试理解 java.lang.Finalizer 和 sun.security.ssl.SSLSocketImpl 之间的关系。我们右键点击 sun.security.ssl.SSLSocketImpl 这一列，打开 GC Roots - exclude soft/weak references。