4

我们的生产系统进入了完整 gc 的无限循环，并且内存在 2 分钟内从 8 gig 下降到 1 MB。

进行堆转储后，它告诉我有一个 java.lang.Object ([Ljava.lang.Object) 数组，其中数百万个 java.lang.String 对象具有相同的 String 占用 99% 的堆。

但它并没有告诉我哪个类引用了这个数组，以便我可以在代码中修复它。

我在 JDK 6 上使用 jmap 工具进行了堆转储，并使用了 JProfiler、NetBeans、SAP 内存分析器和 IBM 内存分析器，但这些都没有告诉我是什么导致了这个庞大的对象数组？...就像什么类正在引用它或包含它。

我是否必须使用不同的配置进行不同的转储才能获取该信息？...或任何其他可以帮助我找出导致此问题的罪魁祸首的东西...这将有很大帮助。

4

3 回答 3

3

我过去使用过 SAP Memory Analyzer，它是查找“贪婪的内存猪”的绝佳工具。

也许以下演示文稿可以提供帮助：企业级的有效 Java 堆内存分析。

于 2009-09-08T20:14:05.450 回答
1

我以前使用过Eclipse 内存分析器来发现这样的问题。通常，当事情很简单时，很容易找到罪魁祸首，但需要一些时间来适应这些术语。如果没有实际的转储，我无法告诉您可能导致此问题的原因。也许你应该看看这个字符串实际上包含什么，它来自哪里？

于 2009-09-11T12:37:38.060 回答
0

您是否尝试通过源和类简单地 grep 这个字符串？

于 2009-09-09T21:29:46.330 回答