堆转储分析 - 查找 OutOfMemory 异常的根本原因答案

【问题标题】：Heap Dump Analysis - Find root cause of OutOfMemory Exception堆转储分析 - 查找 OutOfMemory 异常的根本原因
【发布时间】：2016-10-12 06:19:39
【问题描述】：

我正在运行一个应用程序，它有 4 gigs 的最大堆大小 -Xms4096m -Xmx4096m -Xmn1024m，GC 配置为 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=50，GC 间隔为 Dsun.rmi.dgc.server.gcInterval=43200000 -Dsun.rmi.dgc.client.gcInterval=43200000

突然我的应用程序出现堆内存不足异常，我在同一场合进行了线程转储和堆转储。在分析线程转储时，由于为 hashMap 和 arrayList 创建了一些值，线程被卡住了。 ByteArrayOutStream 在其中一个线程中创建了锁。

在 Eclipse 内存分析工具的 Analyzing Heap dump 中，它清楚地表明 bytearray 对象已经占用了将近 1 Gigs 的 Heap。从 GCViewer 显示它在几分之一秒内有一个峰值。我不知道为什么突然字节数组对象使用了 1 Gigs 的空间。有人可以帮我找出罪魁祸首吗？

-- 应用服务器 - Weblogic 12c

【问题讨论】：

提供的信息很难说什么。你能提供更多关于你的内存消耗代码的细节吗？
仅仅知道它是一个字节数组对你没有多大帮助。您必须查看您的应用程序的哪些对象正在使用该数组，以了解发生了什么问题。 MAT 确实允许您将层次结构向上移动到包含对象。
更多代码细节会有所帮助，使用提供的 jvm 标志运行默认应用程序不会为我复制任何内容
@NickBell 您需要的所有其他信息是什么

标签： java garbage-collection heap-memory eclipse-memory-analyzer

【解决方案1】：

在 Eclipse 内存分析工具的 Analyzing Heap dump 中，它清楚地表明 bytearray 对象已经占用了将近 1 Gigs 的 Heap。

使用 MAT 的 GC 根特性的最短路径来查看哪些引用持有该字节数组。

【讨论】：

我尝试了合并到 GC 根的最短路径，所有参考都没有显示任何参考。我尝试使用 Dominator 树，它向我显示了内存地址为“0x74d407870”的字节数组对象和字节 [] 中的某些值。除了这个，还有什么办法吗？
由于OOME，对象分配后可能无法访问。也许你正试图将一些大的东西序列化到 ByteArrayOutStream 中，它当然会保存在内存中直到它被使用。
你是对的。我正在尝试序列化一个对象。从 JVisualVM，我可以看到参考，`this (Java frame) - value: byte[] #65581 (1,073,790,734 项)
然后要么突破内存限制，要么序列化到一个文件中