java - 运行 jmap 无法打开套接字文件

Question

我不得不跑 jmap为了对我的进程进行堆转储。但是 jvm返回:

Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

所以我使用了 -F :

./jmap -F -dump:format=b,file=heap.bin 10330
Attaching to process ID 10331, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.51-b03
Dumping heap to heap.bin ...

使用 -F可以进行堆转储吗？

我等了 20 分钟，还没有完成。任何想法为什么？

Answer 1

jmap对比 jmap -F ，以及 jstack对比 jstack -F使用完全不同的机制与目标 JVM 通信。

jmap/jstack

在没有 -F 的情况下运行时这些工具使用 Dynamic Attach Mechanism .这如下工作。

连接Java进程1234之前，jmap创建文件 .attach_pid1234在目标进程的工作目录或在 /tmp .

然后jmap发送 SIGQUIT到目标进程。当JVM捕捉到信号，发现.attach_pid1234 ，它开始 AttachListener线程。

AttachListener线程创建 UNIX 域套接字 /tmp/.java_pid1234听取来自外部工具的命令。

出于安全原因，当连接(来自 jmap)被接受时，JVM 会验证套接字对等方的凭据是否等于 euid和 egid JVM 进程。这就是为什么jmap如果由不同的用户(甚至是 root 用户)运行，则将不起作用。

jmap连接到套接字，并发送 dumpheap命令。

该命令由 AttachListener 读取并执行JVM 的线程。所有输出都发送回套接字。由于堆转储是由JVM直接在进程内进行的，因此操作非常快。但是，JVM 只能在 safepoints 执行此操作.如果无法到达安全点(例如，进程挂起、没有响应或正在进行长时间的 GC)，jmap将超时并失败。

让我们总结一下动态附加的优点和缺点。

优点。

堆转储等操作由JVM以最大速度协同运行。

您可以使用任何版本的 jmap或 jstack连接到任何其他版本的 JVM。

缺点。

该工具应由与目标 JVM 相同的用户 ( euid/egid ) 运行。

只能在正常运行的 JVM 上使用。

如果目标 JVM 以 -XX:+DisableAttachMechanism 启动，将无法工作.

jmap -F/jstack -F

当使用 -F 运行时工具切换到具有特色的特殊模式 HotSpot Serviceability Agent .在这种模式下，目标进程被卡住；这些工具通过操作系统调试工具读取其内存，即 ptrace 在 Linux 上。

jmap -F调用 PTRACE_ATTACH在目标 JVM 上。响应SIGSTOP，目标进程无条件挂起信号。

该工具使用 PTRACE_PEEKDATA 读取 JVM 内存. ptrace一次只能读取一个字，因此读取目标进程的大堆需要太多调用。这是非常非常缓慢的。

该工具根据特定 JVM 版本的知识重建 JVM 内部结构。由于不同版本的JVM有不同的内存布局，-F模式仅适用于 jmap来自与目标 Java 进程相同的 JDK。

该工具自己创建堆转储，然后恢复目标进程。

优点。

不需要来自目标 JVM 的合作。即使在挂起的进程中也可以使用。

ptrace只要操作系统级别的权限足够，就可以工作。例如root可以转储所有其他用户的进程。

缺点。

对于大堆来说非常慢。

工具和目标进程应该来自相同版本的 JDK。

当工具以强制模式连接时，无法保证安全点。虽然 jmap尝试处理所有特殊情况，有时可能会发生目标 JVM 未处于一致状态的情况。

备注

有一种更快的方法可以在强制模式下进行堆转储。首先，使用 gcore 创建核心转储，然后运行 ​​ jmap在生成的核心文件上。见 the related question .