VisualVM 和 JMC 均通过 JMX 连接 JVM 进行性能调优，前者轻量免费适合日常排查，后者依托 JFR 低开销适合生产深度分析；需启用 JMX 参数，优先关注内存、CPU、线程三类瓶颈信号。
直接用 VisualVM 或 JMC 做 JVM 性能调优，核心是“先看瓶颈、再验证假设、最后改配置或代码”。两者都依赖 JVM 内置的 JMX 和事件采集机制，但定位和使用场景略有不同：VisualVM 更轻量、免费、适合日常排查；JMC 配合 JFR（Java Flight Recorder）更深入、低开销、适合生产环境深度分析。
连接目标 JVM 并启动基础监控
两者都需要目标 JVM 启用 JMX 支持。本地进程通常自动识别；远程监控需在启动应用时添加参数：
- -Dcom.sun.management.jmxremote（启用 JMX）
- -Dcom.sun.management.jmxremote.port=9999（指定端口）
- -Dcom.sun.management.jmxremote.authenticate=false（开发环境可关闭认证）
- -Dcom.sun.management.jmxremote.ssl=false（简化连接）
启动 VisualVM（jvisualvm）或 JMC（jmc）后，在左侧进程列表中选择目标应用即可连接。JMC 还支持直接加载本地生成的 JFR 文件（.jfr），无需实时连接。
聚焦关键指标定位瓶颈
不要泛看所有面板，优先盯住三类信号：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 内存压力信号：堆内存持续高位（>75%）、频繁 GC（尤其老年代 GC）、GC 后内存回收不明显 → 指向内存泄漏或堆大小不合理
- CPU 热点信号：VisualVM 的“Sampler”或 JMC 的“Hot Methods”显示某方法 CPU 占比超 20%，且调用栈深、重复率高 → 可能存在低效算法或冗余计算
- 线程异常信号：活动线程数突增、大量线程处于 BLOCKED/WAITING 状态、锁竞争事件频发（JMC 的 “Lock Instances” 视图）→ 提示线程池过载或同步瓶颈
用 JFR 做低开销深度诊断（JMC 专属优势）
JMC 的核心价值在于 Java Flight Recorder。它默认以
- 启动时加参数：
-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=recording.jfr - 或运行中通过 JMC 界面动态开启录制（支持自定义事件级别：low/medium/high）
- 录制结束后打开 .jfr 文件，重点查看：“Garbage Collection” 时间分布、“Code Heap” 是否耗尽、“Allocation in New TLAB” 是否异常飙升
例如：若发现大量短生命周期对象在 Eden 区快速填满，但 Survivor 区存活率极低，说明对象创建过于频繁，应检查循环内 new 对象、日志字符串拼接等代码模式。
结合工具结果做针对性调优
工具只暴露现象，调优动作要落在具体层面：
-
GC 层：若 G1 GC 暂停时间超标，尝试调小
-XX:MaxGCPauseMillis；若 CMS 出现 concurrent mode failure，考虑切换为 G1 或 ZGC -
内存层：确认无泄漏后，按实际峰值堆用量 +20% 设置
-Xms和-Xmx；新生代占比可通过-XX:NewRatio或-Xmn调整 -
代码层：JMC 中点击热点方法 → 查看源码行号 → 替换低效操作（如
list.contains(x) && list.get(i)改为直接get+ try-catch，避免重复遍历）
每次调整后，务必重新采集数据对比，避免“凭经验乱调”。
