Java 中内存泄漏排查怎么使用 VisualVM 监控内存与线程-java教程-PHP中文网

visualvm 排查 java 内存泄漏的核心是“监控找异常 → 快照抓现场 → 引用链定位源头”，依托jdk自带工具实时监控堆内存趋势、抓取堆快照、分析支配树与引用链，并用oql辅助验证，10分钟内可完成初步定位。

java 中内存泄漏排查怎么使用 visualvm 监控内存与线程

用 VisualVM 排查 Java 内存泄漏，核心是“监控找异常 → 快照抓现场 → 引用链定位源头”。它不依赖复杂配置，JDK 自带、开箱即用，适合开发自测和线上轻量诊断。

启动 jvisualvm.exe（JDK 8 及以前在 bin 目录；JDK 9+ 需单独下载），连接目标 JVM 进程后，切换到监视标签页：

观察堆内存曲线：若持续阶梯式上升，且点击执行 GC后内存不明显回落，尤其老年代占比长期 >85%，就是典型泄漏迹象
留意Metaspace 和类加载数：若类数量持续增长，可能有动态类加载未卸载（如热部署、Groovy 脚本）
配合VisualGC 插件（工具 → 插件 → 安装）：可直观看到 Eden/Survivor/Old 区变化。若大量对象直接进入老年代，要检查是否因对象过大或 Survivor 区过小导致提前晋升

在内存明显上涨但尚未 OOM 时手动触发，或配置 JVM 参数自动捕获：

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

手动：在监视页点击堆 Dump，生成 .hprof 文件
自动：启动参数加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/dumps/
打开 dump 后，切到类视图，按保留大小（Retained Size）倒序排列
重点关注：实例数异常高（如百万级 String[]）、单类占比超 20%、名称含 Cache、Listener、ThreadLocal、Map、Holder 的类

双击可疑类 → 进入实例列表 → 右键任一实例选择显示支配者（Show Dominators），或直接切换到支配树（Dominators Tree）：

顶层节点即内存“大户”，展开看其引用路径，例如：ThreadPoolExecutor → Worker → Thread → threadLocals → ThreadLocalMap → Entry → value → 泄漏对象
若路径中出现 static final HashMap 或 未注销的监听器引用，基本可确认泄漏点
重点检查是否被 java.lang.Thread、ClassLoader 或 static 字段 直接/间接持有——这些是 GC Roots，只要它们活着，下游对象就无法回收

在 dump 分析界面顶部点击OQL 控制台，输入查询语句缩小范围：

查所有非空 ThreadLocal 值：select x from java.lang.ThreadLocal$ThreadLocalMap$Entry x where x.value != null
查某类全部实例及直接引用者：select s, s.@referers from com.example.User s
查未关闭的 InputStream：select s from java.io.InputStream s where s.@outbound = false（需结合实际类名调整）

整个过程不需要改代码、不重启服务，从发现异常到定位根源，通常可在 10 分钟内完成初步判断。关键不是看工具多炫酷，而是盯住“谁没放手”这个本质问题。