可用jmap -dump:format=b,file=/path/to/heap.hprof 手动触发堆转储，需对应进程权限；卡顿时加-F强制执行，但可能不完整；容器中需--cap-add=SYS_PTRACE且避免Alpine镜像。
怎么用 jmap 手动触发堆转储
直接在目标 Java 进程运行的机器上执行命令即可，不需要重启或改代码。前提是得有对应进程的权限（通常是同一用户，或 root）。
最常用的是这个组合：
-
jmap -dump:format=b,file=/path/to/heap.hprof <pid></pid>—— 生成二进制格式的堆转储，VisualVM、Java Mission Control、Eclipse MAT都认 - 如果进程卡死或响应慢，加
-F强制执行：jmap -F -dump:format=b,file=heap.hprof <pid></pid>，但可能产生不完整快照 - 别用
-dump:live除非明确要排除 unreachable 对象——它会先触发 Full GC，可能干扰线上行为
jmap 找不到进程或报错 “Unable to get pid” 怎么办
常见于容器环境或非 root 用户操作。JDK 自带的 jmap 默认依赖 /proc/<pid>/mem</pid> 读取内存，而很多容器默认禁用该权限。
- 确认
pid确实存在：ps aux | grep java，注意容器内 PID 是 1 的情况（宿主机看到的是其他数字） - 在 Docker 中，必须加
--cap-add=SYS_PTRACE启动容器，否则jmap直接失败 - Alpine 镜像通常不带
jmap（musl libc + OpenJDK headless），换openjdk:jre-slim或手动安装 full JDK - 错误信息如
sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process，基本就是权限或容器限制问题
导出的 .hprof 文件太大，能压缩或限流吗
不能。jmap 导出的是原始堆镜像，不支持边 dump 边压缩，也不支持采样。文件大小 ≈ 当前堆已使用容量（jstat -gc <pid></pid> 里的 OU 值）。
- 导出前先看堆占用：
jstat -gc <pid></pid>，如果OU是 2GB，那.hprof就接近 2GB - 磁盘空间至少留出 2 倍余量（写入 + 临时页缓存）
- 别把文件导到
/tmp（很多系统挂载了 noexec 或 tmpfs，空间小还易丢） - 想减小体积？唯一靠谱办法是先调低 JVM 堆（
-Xmx），再 dump；或者用jcmd <pid> VM.native_memory summary</pid>快速排查是否 native 内存泄漏，避免误 dump
导出后打不开或分析工具报 “Invalid HPROF header”
大概率是 dump 过程被中断，或文件传输时损坏（比如用 base64 转义没处理好，或 FTP 用了 ASCII 模式）。
- 检查文件头：
head -c 4 heap.hprof，正常应输出JAVA四字节（十六进制4a 41 56 41） - 用
file heap.hprof确认类型，应为data，不是text或empty - 从容器拷贝文件别用
docker cp后直接双击打开——Windows 上可能因换行符或路径长度截断，优先用sha256sum校验一致性 - 某些 JDK 版本（如早期 JDK 8u20）dump 出的文件 MAT 打不开，升级 MAT 或换用
jdk9+的jhsdb jmap替代
堆转储本身不加密、不校验，文件完整性全靠写入过程稳定——这也是为什么生产环境宁可多等一分钟，也别在高峰期强制 -F dump。
