jvm 无内置自动内存泄漏检测机制，仅通过可达性分析、堆转储参数、nmt、gc日志等提供诊断支持；工具如mat、jprofiler实现半自动化分析，仍需人工确认。
JVM 本身没有内置的自动检测内存泄漏的机制。它不主动识别“逻辑上无用但引用仍存在”的对象，也不会告警或干预这类问题。内存泄漏在 JVM 看来是合法的——只要对象被 GC Roots 可达，就视为“存活”，GC 就不会回收它。所谓“泄漏”，本质是程序逻辑错误导致的引用关系失控，而非 JVM 功能缺失。
真正起作用的是配套工具链和运行时参数支持，它们让开发者能发现、定位、验证泄漏，但不是“自动检测”：
JVM 提供的关键支持能力
可达性分析（Reachability Analysis）
这是 GC 的基础机制，也是所有泄漏分析的起点：JVM 持续计算哪些对象与 GC Roots 有引用链。虽然它不标出“这是泄漏”，但堆转储（heap dump）文件中的完整引用链，正是 MAT、VisualVM 等工具逆向追踪泄漏源头的依据。-
堆转储触发参数
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/
当
java.lang.OutOfMemoryError: Java heap space发生时，JVM 自动保存当前堆快照。这不是“提前预警”，而是“事后留证”，为分析提供原始数据。 -
原生内存监控（Native Memory Tracking, NMT）
对 Direct Memory 泄漏尤其关键：-XX:NativeMemoryTracking=detail
启用后可通过
jcmd <pid> VM.native_memory summary</pid>查看 native 内存分配趋势，配合pmap或Process Explorer观察 RSS/Private Bytes 是否持续增长——这是堆外泄漏最直接的信号。 -
GC 日志输出能力
-Xlog:gc*:file=/logs/gc.log:time,uptime,pid,tid,level,tags
持续记录每次 GC 的耗时、前后堆大小、晋升失败、Full GC 频次等。若发现老年代占用持续上升、Minor GC 后老年代反而增长、或频繁 Full GC 却回收极少——这些异常模式是泄漏的重要线索，需人工或借助 GCViewer/GCEasy 分析。
工具层面的“自动”其实是半自动化
MAT（Eclipse Memory Analyzer）
加载 heap dump 后，它能自动运行“Leak Suspects Report”，基于对象数量、保留集（Retained Heap）大小、常见泄漏模式（如静态集合、线程局部变量未清理）给出概率性提示，但仍需人工确认引用路径。JProfiler / YourKit
支持实时监控对象创建速率、堆中对象实例数趋势、按类统计的 retained memory。当某个类的实例数随时间单向增长且不回落，工具会高亮提醒——这属于行为异常检测，依赖采样和阈值判断，并非 JVM 内置。Arthas + dashboard/mbean 命令
在线查看java.lang:type=MemoryMBean 中HeapMemoryUsage.used、NonHeapMemoryUsage.used，结合vmtool --action getInstances --classLoaderClass java.net.URLClassLoader --className xxx动态抓取可疑类实例，属于运维阶段的主动探查，也非自动。
不复杂但容易忽略
