我是第一次在 NetBeans 中检查分析器，今天早上我注意到通过 Monitor 分析器显示了 1700 多个幸存的代，但堆大小保持不变。在阅读时，我发现这篇文章讨论了使用 NetBeans 分析器发现泄漏。
因此，按照文章的建议，我启动了一个内存分析器。在查看结果时，我发现 char[] 占幸存世代的大多数。目前截至这篇文章，char[] 已经有 22 代了，而且还在增加。
现在一些帖子（OldCurmudgeon 在底部附近的评论）表明，如果我的堆稳定，则没有泄漏，但其他人说，如果世代继续增长，就会有泄漏。所以我有点困惑哪个是正确的。
所以，我的问题是：
根据以下屏幕截图，我是否应该进一步调查潜在的内存泄漏？
内存（堆）
内存（GC）
实时分配的对象
将char[]可能由String对象持有。它们可以出于任何目的在任何地方创建，例如分析器和 JMX 使用它们，因此什么都不做的进程将显示这些（以及不断增长的堆）
注意：所有字符串字面量和类名称等都将继续存在，直到 ClassLoader 被卸载（这可能是程序的生命周期）
要确定您的堆使用量是否在增长，您应该查看完整 GC 后保留了多少。看看每个下降的底部，对我来说它看起来是一样的。其他信息对性能调整很有用，但本身不是问题。
在我的分析过程中，我也遇到了这些挥之不去的 char[]。经过长时间的分析，我得出一个结论，其中许多是字符串常量池的 char 数组。
不看代码，你无法分辨。有些程序使用 TB 内存，它们运行良好，因为这不是内存泄漏，而是程序的工作方式。
Netbeans 文档只定义了幸存的世代，而不是如何使用该数字来发现内存泄漏。而且， achar[]只是 a 的内容String，它可以保留很长时间（甚至与主线程一样长）。
没有找到泄漏的灵丹妙药。您应该在可行的负载下运行您的程序，并查看内存使用情况是否与预期模式一致。如果不是，那么您就有问题了，但是如果没有任何上下文，该图就没有任何意义。