共计 943 个字符，预计需要花费 3 分钟才能阅读完成。

这篇文章将为大家详细讲解有关如何识别 Java 中的内存泄漏，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

内存泄漏的识别

在将程序部署到生产环境之前检查一下是否存在内存泄漏的问题是很有必要的。这里可以通过垃圾收集器的指标来进行初步的判断。

如 GC 后内存使用仍然持续上升，那么就可能有内存泄漏的问题，比如上面的这幅图，代码可以查看 GitHub(https://gist.github.com/dpryden/b2bb29ee2d146901b4ae)。不过在现实中内存像图上一样线性增加的可能性是很小的，见图 Old Gen，而 GC suspension times 或者 Eden Space 和 Survivor 空间使用并不足以识别出内存泄漏。

缩小问题的范围

要找出内存泄漏的原因当下已经有许多工具可用，比如 JVisualVM 或者 jStat。这些工具是 JDK 自带的，所以大家随时都能用。除了要识别一些常用的内部 Java 类，一些用户自定义累同样需要识别。

性能优化

在日常的开发过程中，只要 GC 没有影响到性能，开发者就不会去关注内存设置于配置。从而埋下了潜在的隐患：因为内存问题并不只有溢出和泄露，GC 时间过长同样会造成这个问题。比如下图中 GC 占用了 16% 的 CPU。

Heap 设置

Heap 太小会导致频繁的 GC，从而情景不难想象：增加 GC 会消耗更多的 CPU，同时在 GC 时 JVM 会被冻结，最后导致一个很差的性能。总的来说，Heap 太小的话，虽然 GC 时间变短，但是会变得更加频繁。

Heap 太大会导致 GC 时间边长。GC 不会经常发生，但是一旦被触发，那么 VM 会被冻结很久。

因此，如果这种情况下发生内存泄露，在最终 JVM 因为内存溢出崩溃之前，GC 会非常频繁或者时间特别长。

GC 版本

从 Java 6 开始，GC 就改变了很多。Java 7 引入了 G1GC 作为 CMS GC 的替代选择，而在 Java 9 中 G1GC 已成为默认选择。Java 8 中移除了 PermGen Space，之前存储在 PermGen Space 中的数据则改为存储在本地内存或者栈中。

关于如何识别 Java 中的内存泄漏就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。