我们的生产系统进入无限循环的完整gc，内存下降形成8个演出，仅需2分钟即可达到1 MB。
在进行堆转储后，它告诉我有一个java.lang.Object（[Ljava.lang.Object]数组，其中包含数百万个java.lang.String对象，这些对象具有占99％堆的相同String。
但它没有告诉我哪个类引用了这个数组，所以我可以在代码中修复它。
我在JDK 6上使用jmap工具进行了堆转储，并使用了JProfiler，NetBeans，SAP Memory Analyzer和IBM Memory Analyzer，但这些都没有告诉我是什么导致这个巨大的对象数组？ ...喜欢哪个类引用它或包含它。
我是否必须使用不同的配置进行不同的转储以获取该信息？ ......或者其他任何可以帮助我找出造成这种情况的罪魁祸首......它会有很多帮助。
答案 0 :(得分：3)
过去我使用过SAP Memory Analyzer，这是一个非常棒的工具，可以找到“贪吃记忆猪”。
以下演示文稿可能有所帮助：Effective Java Heap Memory Analysis on Enterprise-Scale。
答案 1 :(得分：1)
我之前使用过Eclipse Memory Analyzer来查找这样的问题。通常当它是直截了当的时候，很容易找到罪魁祸首，但需要一些人习惯这些术语。如果没有手中的实际转储，我无法告诉您可能导致此问题的原因。也许你应该看一下这个字符串实际包含的内容，它来自哪里？
答案 2 :(得分：0)
您是否尝试过简单地通过源和类grep这个字符串？