VisualVM 本地监控、采样与远程连接手册

VisualVM 从趋势观察到有界采样先确认目标和窗口，再从 Monitor 逐级进入 Sampler、Profiler 与离线制品。高清原图

VisualVM 适合快速反馈，但每个按钮都有代价

VisualVM 把本地 JVM 发现、CPU 与堆趋势、线程、类、Sampler、Profiler 和 heap dump 浏览放在一个桌面界面里。它很适合开发机上回答“慢在 CPU 还是等待”“分配集中在哪条路径”“线程为什么堆积”这类短反馈问题。它不适合替代持续生产观测，也不会因为操作发生在 GUI 中就消除 Attach、采样、插桩、Full GC、磁盘和敏感数据风险。

产品边界需要先说清。VisualVM 是独立发行的工具，当前实验锁定 VisualVM 2.2.1；这个版本支持一组明确的 JDK 发行线，只作为可复现实验基线，不是永久最新声明。JFR 是目标 JDK 内置录制能力，JMC 是另一款偏向 JFR 规则与事件分析的产品。VisualVM 可以安装插件读取或采集相关数据，但它拥有自己的安装、用户目录、插件、连接和升级责任，不能埋在一篇 JFR 附录里。

安装从独立发行包和运行 JDK 开始

VisualVM 官网明确把当前版本作为独立工具分发。旧 JDK 曾经捆绑 Java VisualVM，GraalVM 某些发行阶段也包含过它，这些历史入口不应继续冒充当前独立产品。团队安装时保存下载来源、完整版本、包校验值、操作系统、架构和运行 VisualVM 的 JDK。

解压后先确认启动器和实际运行环境。--jdkhome 选择的是运行 VisualVM 自身的 JDK，不会升级或替换目标 JVM：

visualvm --help
visualvm --jdkhome /path/to/approved-jdk

桌面快捷方式可能绕过当前 shell 的 PATH，因此 About 页面、日志中的运行时与命令行结果要互相核对。首次启动使用全新的用户目录，先不装插件，只观察一个本地合成 JVM。升级则保留旧安装和旧用户目录的只读副本，用新的独立目录跑完回归后再切换；原地覆盖会让启动失败究竟来自新二进制、旧插件还是缓存变得难以判断。

VisualVM 用户目录会保存设置、插件、远程主机和连接相关信息。它不是普通 UI 缓存，应位于受控用户目录，不进入源码仓库、公共同步盘或共享桌面账号。需要代理下载插件时使用操作系统或组织批准的网络配置，不能把代理口令写进可导出的配置。

本地进程发现也依赖身份和 namespace

VisualVM 自动列出本机 JVM，看起来比命令行简单，底层仍受 JVM 发现与 Attach 边界影响。目标和 VisualVM 的 effective UID/GID、临时目录、目标 JDK、DisableAttachMechanism、容器 PID namespace 与安全策略都会决定能否出现和连接。看不到进程不等于应用没运行。

先从目标保存身份：

java --version
jcmd "$PID" VM.version
jcmd "$PID" VM.command_line

随后在 VisualVM 的 Overview 中核对 PID、主类、参数与 JVM 信息。多个相同主类的开发实例尤其容易选错；仅凭显示名点击采样，可能把结果归到另一份构建。实验应打印 ProcessHandle.current().pid()，并在应用日志中写入不含敏感信息的构建标识，让 GUI、命令行和实验输出形成三方核对。

容器内 JVM 通常不会自动出现在宿主 VisualVM 列表中。把业务容器改成 privileged、共享宿主 PID 或长期挂载 Attach socket，只为让 GUI 发现进程，会扩大整机读取能力。生产容器优先使用预先配置的 JFR 与平台指标；确需现场连接，应在摘流副本和批准的临时诊断环境中建立最小 namespace 与身份边界。

Monitor 先给出趋势，不给出根因

Monitor 页面常见 CPU、Heap、Classes 和 Threads 曲线，适合确认问题从何时开始、是否随负载变化，以及采样动作本身有没有扰动。CPU 曲线高只能说明目标 JVM 消耗增加，不能指出方法；Heap 上升可能是正常预热、批次活跃集或未回收垃圾，不能直接判泄漏；线程数增加也可能来自合理扩容，必须结合池配置与队列。

执行 GC 的按钮会请求目标 JVM 做垃圾收集，不是无害刷新。生产上不能为让图“更好看”反复点击。Heap Dump 按钮风险更高，可能触发 Full GC、长暂停和大文件，且文件近似一份生产内存副本。需要这两类动作时，应转到显式命令、审批、摘流、容量预检和产物治理流程，而不是依赖一次鼠标操作无法复现的历史。

Monitor 的采样周期和窗口也会掩盖尖峰。短时间 CPU 抖动可能只留下一个低平均点，快速创建并退出的线程可能从曲线中消失。结论要注明观察区间、负载阶段、VisualVM 版本和采样设置，并和服务端指标使用同一时钟。

Sampler 与 Profiler 不是同一个成本等级

Sampler 周期性抓取线程栈或分配信息，通常比插桩式 Profiler 更适合第一轮定位。CPU sampling 统计被采中的栈，短方法、native 代码和采样间隔之间完成的调用可能缺失；Memory sampling 更接近分配热点，不代表对象仍然存活。两种结果都必须和业务场景、请求量及时间窗口一起解释。

Profiler 会对目标类或方法插桩，能提供更细的信息，也更可能改变 JIT、内联、线程调度和总体时延。性能问题对扰动敏感时，插桩后的现场可能已经不是原现场。生产默认不直接启用；确需使用，应在流量隔离的副本上限定类范围、持续时间和停止条件，并同步观察目标延迟、CPU、GC 与错误率。

入口	主要回答	典型失真	使用边界
Monitor	资源与线程趋势是否同步变化	低频刷新抹平尖峰	先观察，不点击高影响动作
CPU Sampler	哪些调用栈反复获得 CPU 样本	短方法与 native 路径缺失	短窗口、同负载、多次复测
Memory Sampler	哪些路径持续分配对象	分配被误写成存活或泄漏	和 GC 后趋势、业务生命周期对照
Profiler	指定方法调用与成本细节	插桩改变 JIT 和时序	隔离实例、缩小范围、可立即停止

一个能看见正反证据的小实验

在随机目录中启动小堆 JVM，创建一个 CPU 线程、一个锁持有者、一个等待者和有界分配。代码只处理合成数据，不开放网络：

LAB="$(mktemp -d "${TMPDIR:-/tmp}/visualvm-lab-XXXXXXXX")"
chmod 700 "$LAB"
cat > "$LAB/VisualVmLab.java" <<'JAVA'
import java.util.ArrayList;
import java.util.List;

public final class VisualVmLab {
  private static final Object LOCK = new Object();
  private static final List<byte[]> RETAINED = new ArrayList<>();
  public static void main(String[] args) throws Exception {
    System.out.println("pid=" + ProcessHandle.current().pid());
    long end = System.nanoTime() + 120_000_000_000L;
    Thread cpu = new Thread(() -> {
      long x = 7;
      while (System.nanoTime() < end) x = Long.rotateLeft(x * 31 + 17, 5);
      System.out.println(x);
    }, "lab-cpu");
    Thread holder = new Thread(() -> {
      synchronized (LOCK) {
        try { Thread.sleep(90_000L); } catch (InterruptedException ignored) { }
      }
    }, "lab-lock-holder");
    Thread waiter = new Thread(() -> {
      synchronized (LOCK) { System.out.println("acquired"); }
    }, "lab-lock-waiter");
    cpu.start(); holder.start(); Thread.sleep(500L); waiter.start();
    for (int i = 0; i < 40; i++) { RETAINED.add(new byte[256 * 1024]); Thread.sleep(200L); }
    cpu.join(); holder.join(); waiter.join();
  }
}
JAVA
javac -d "$LAB" "$LAB/VisualVmLab.java"
java -Xms128m -Xmx128m -cp "$LAB" VisualVmLab > "$LAB/app.log" 2>&1 &
PID=$!

VisualVM 连接前先从日志和 jcmd "$PID" VM.version 核对目标。Monitor 应显示 CPU 活跃、堆在有界分配后趋于稳定、线程数保持可解释。CPU Sampler 在合适窗口应反复命中 lab-cpu，Threads 页应看到等待线程与持有线程围绕同一 monitor。

反向观察很重要。等 CPU 线程结束后再开启 Sampler，结果可能看不到热点；这说明窗口错过，不说明代码没有消耗过 CPU。Memory Sampler 看到 byte array 排名靠前，也不能宣布泄漏，因为实验明确有界，并会随进程退出释放。若为了得到“更确定”的图而点击 Heap Dump，反而违反了实验目的；对象保留关系应另设经过容量与敏感数据审批的小堆练习。

停止 Sampler 或 Profiler 后，确认 VisualVM 状态回到未采集，再终止自己持有的 PID：

kill "$PID" 2>/dev/null || true
wait "$PID" 2>/dev/null || true
rm -rf -- "$LAB"

生产证据不能照此立即删除。实验目录由 mktemp -d 返回且只含自有样本，正式现场则必须按事件保留清单处理。

Threads 页面需要连续观察和命令行复核

线程时间线能帮助发现新建、休眠、等待、阻塞与结束，但单个状态没有根因含义。RUNNABLE 可能位于 native 调用，WAITING 可能是健康的空闲池，持续 BLOCKED 在同一 monitor 且持有者不动才形成较强锁证据。

GUI thread dump 仍是一个时刻的栈。正式现场优先用 jcmd、jstack 与 jmap 手册 的脚本连续采集多份，保存命令、时间和文件哈希。VisualVM 负责快速筛选，命令行产物负责可重复与交接。大量虚拟线程场景还要检查目标 JDK 是否提供更合适的 Thread.dump_to_file；旧 GUI 视图可能只显示平台线程或已挂载虚拟线程。

线程名、栈、锁对象和请求上下文可能暴露内部路径与用户信息。截图不是天然脱敏产物，进入工单前要检查线程名、参数和插件附加字段。不要把全量线程页面直接复制到公共聊天。

heap dump 浏览从文件身份开始

VisualVM 可以打开 HPROF 并查看类、实例、引用和 GC roots。它只是分析器，采集风险不会因为后续由 VisualVM 打开而降低。生产 dump 应在摘流实例上显式生成，预先检查最大堆、可用空间、停顿预算、文件权限和保留期；真实文件不得进入源码仓库、普通网盘或第三方在线分析器。

打开前记录 SHA-256、目标构建、JDK、采集命令与是否包含不可达对象。类实例的 shallow size 不等于 retained heap；类名排名高不等于泄漏。真正的对象保留结论要沿引用链找到所有者，并证明它跨业务生命周期和 GC 周期持续增长。字符串、byte array 与集合常是被保留的载体，不一定是责任对象。

分析工作站要有足够内存和独立加密空间。超大 dump 打不开时，不要随意复制到更强的个人电脑；先检查文件完整性、分析机容量与批准边界。需要供应商协助时，只交付最小充分副本，并明确地域、访问与销毁要求。

远程 JMX 不是快速打开一个端口

VisualVM 远程实时连接常依赖 JMX/RMI。RMI 可能同时使用 registry 端口和服务端口，只放通一个端口会出现“能发现但连不上”的现场。安全配置应固定两者、绑定管理地址、启用认证和 TLS，并通过防火墙、VPN 或受控 SSH 隧道限制来源。

无认证、无 TLS、监听所有接口的示例不能进入共享环境。JMX 能读取 MBean，部分能力还能执行操作或触发诊断命令，其权限远高于普通指标读取。口令文件、keystore 与 truststore 由密钥系统下发，VisualVM 保存的连接信息也进入敏感配置治理。

连接失败按网络、RMI 地址、端口、认证、TLS 信任和目标权限分层检查。为了验证而关闭安全控制，会改变问题并扩大暴露。更稳的降级路径是导出 JFR 离线分析；只有确实需要即时 MBean 或线程状态时才保留短时 JMX 窗口，结束后检查 IPv4、IPv6 监听和防火墙规则都已退出。

插件要经过和工具本体相同的审查

VisualVM 插件可以增加数据源、分析视图或目标操作。每个插件记录来源、版本、适用 VisualVM/JDK、网络访问、读取的数据和卸载方式。只安装解决明确问题的插件，不把公共插件中心当作生产分析机的默认软件源。

升级前用独立用户目录验证基础 VisualVM，然后逐个加入插件。出现启动失败、页面异常或 CPU 升高时，可以由这个顺序定位责任。插件卸载后还要检查用户目录残留、缓存和连接定义；“界面里不显示”不等于代码、配置或凭证已经离开工作站。

对于 JFR 规则和事件时间线，优先使用 JDK Mission Control 的专门能力。VisualVM 插件若复制了同一功能，应说明选择理由与兼容基线，避免团队同时维护两套不可比较的结论。

结果可信需要把观察者成本也记下来

每次采样记录目标 PID 与构建、VisualVM 版本、运行 JDK、模式、筛选范围、开始与结束相对窗口、目标 CPU、延迟、GC 和错误率。Sampler 开启前后指标没有明显变化，只能证明这一次扰动可接受；不能推广到更大堆、更多线程或更紧 CPU 配额的实例。

Profiler 造成延迟或错误率上升时立即停止，保存目标指标和当前配置，不继续扩展类范围。停止后确认目标恢复、插桩状态退出、连接断开。无法证明恢复时，最可靠的回退是销毁诊断副本并从正常构建重建，而不是相信关闭桌面窗口已经撤销所有状态。

长期升级门禁使用固定合成样本，覆盖本地发现、错误 PID、Monitor、CPU/Memory Sampler、线程锁、插件空基线、受控 JMX 拒绝路径和用户目录清理。真正有用的 VisualVM 流程让开发反馈更快，同时明确何时必须退出 GUI，转向持续 JFR、可重复命令行证据或隔离的 heap 分析。

安装范围与兼容信息继续查阅 VisualVM 下载页、VisualVM 文档和 VisualVM 发布记录。