最稳方式是用jps -l或ps aux | grep java查PID，再在JProfiler中选Session → Connect to Running VM手动填PID；需确保JVM未禁用attach、用户权限一致、Docker加--cap-add=SYS_PTRACE并挂载/proc。
怎么启动 JProfiler 连接本地正在运行的 Java 进程
JProfiler 不能直接“看到”所有 Java 进程，尤其当进程以 java -jar 或 systemd、Docker 方式启动时，jps 可能查不到，JProfiler GUI 列表里就为空。
最稳的方式是：先用 jps -l 或 ps aux | grep java 找到目标进程 PID，再在 JProfiler 中选 Session → Connect to Running VM，手动填 PID —— 注意不是进程名，是纯数字 ID。
常见错误现象：Cannot connect to VM: Connection refused，大概率是目标 JVM 启动时没开 JMX 或没加 -Dcom.sun.management.jmxremote 参数；但 JProfiler 用的是 JVMTI 协议，不依赖 JMX，所以只要 JVM 是 HotSpot 且未禁用 attach（比如加了 -XX:+DisableAttachMechanism），就能连上。
- Linux/macOS 下，确保当前用户和 Java 进程属同一用户（否则 attach 失败）
- 如果进程由
sudo启动，JProfiler 也得用sudo启动，否则权限不足 - Docker 容器内 Java 进程默认无法被宿主机 JProfiler attach，需加
--cap-add=SYS_PTRACE并挂载/proc
为什么 heap walker 查不到“泄露对象”，但内存持续上涨
不是所有内存增长都叫“泄露”。JProfiler 的 Heap Walker 显示的是“可达对象”，而真正泄露往往藏在弱引用、软引用、线程局部变量或 Native 内存里 —— 这些区域 Heap Walker 不统计。
立即学习“Java免费学习笔记（深入）”；
典型场景：用了 ThreadLocal 存大对象，线程池长期复用线程，ThreadLocalMap 里的 Entry 没被清理；或者用了 JNI 库（如图像处理、加密），Native 堆分配未释放。
实操建议：
- 先切到
Live Memory → Record allocations，跑一段时间后 dump，看哪些类实例数/总大小异常增长 - 打开
Biggest Objects视图，按 retained size 排序，重点看是不是某个 Map、List 或缓存容器占了 80%+ 内存 - 右键可疑对象 →
Show Nearest GC Root，确认是不是被静态字段、线程、ClassLoader 持有住 - 若怀疑 Native 内存，用
Monitor → Native Memory Tracking (NMT)（需 JVM 启动加-XX:NativeMemoryTracking=detail）
JProfiler 采样模式选 Allocation Recording 还是 Heap Walking
Allocation Recording 记录每次 new 对象的动作，开销大（约 15–25% CPU）、内存占用高，适合定位“谁在疯狂创建对象”；Heap Walking 是定时触发 full GC 后扫描堆快照，轻量但只能看到“此刻活着的对象”，漏掉已 GC 掉的短命对象。
性能影响很实在：线上环境绝对别开 Allocation Recording，连测试环境都建议只开 30–60 秒就停。Heap Walking 可常驻开启，每 5 分钟自动 dump 一次，配合告警更实用。
- 排查内存缓慢泄漏：用
Heap Walking+ 自动定时 dump，对比多个快照的 retained size 趋势 - 排查 OOM 前的暴增：用
Allocation Recording，但必须提前设好触发条件（比如堆使用率达 85% 时自动开始） - 参数差异：
Allocation Recording支持过滤包名（如只录com.example.cache.），Heap Walking不支持实时过滤，得靠事后分析
为什么 dump 出来的 hprof 文件在 JProfiler 里打不开
不是所有 hprof 都兼容。JProfiler 只认 JVM 自己生成的 hprof（用 jmap -dump:format=b,file=xxx.hprof <pid>），不支持 VisualVM、Eclipse MAT 或某些 APM 工具导出的变体格式。
更隐蔽的问题是：JVM 默认生成的 hprof 是“live objects only”，但 JProfiler 的 Heap Walker 需要完整堆镜像（含 unreachable 对象），否则 GC Roots 分析不准。必须加 -all 参数：jmap -dump:format=b,file=heap.hprof,all <pid>。
- 错误信息示例：
Unsupported hprof version 7→ 说明文件不是标准 JVM hprof，可能是其他工具生成 - Linux 下用
file heap.hprof看文件头，标准 hprof 开头是JAVA PROFILE 1.0.2 - JProfiler 9+ 支持直接打开
.jps快照（它自己的格式），比 hprof 加载快、功能全，优先用它
