前言
本文旨在从理论上分析JVM 在 Linux 环境下 Attach 操作的前因后果，以及 JVM 为此而设计并实现的解决方案，通过本文，我希望能够讲述清楚如下三个主要方面的内容。
原发布：我的博客
一、Attach 为什么而出现
Attach的出现究其根本原因，应该就是为了实现 Java 进程（A）与进程（B）之间的本地通信。一旦这个通信通道能够成功建立，那么进程 A 就能通知进程 B 去执行某些操作，从而达到监控进程 B 或者控制进程 B 的某些行为的目的。如 jstack、jmap等 JDK 自带的工具，基本都是通过 Attach 机制去达成各自想要的目的的。至于 jstack、jmap 能做什么、怎么做，就不再本文的讨论范围了，请自行百度或者 Google。
二、Attach 在 JVM 底层实现的根本原理是什么
Attach 实现的根本原理就是使用了 Linux 下是文件 Socket 通信（详情可以自行百度或 Google）。有人也许会问，为什么要采用文件 socket 而不采用网络 socket？我个人认为也许一方面是为了效率（避免了网络协议的解析、数据包的封装和解封装等），另一方面是为了减少对系统资源的占用（如网络端口占用）。采用文件 socket 通信，就好比两个进程通过事先约定好的协议，对同一个文件进行读写操作，以达到信息的交互和共享。简单理解成如下图所示的模型
通过/tmp/.java.pid2345这个文件，实现客户进程与目标进程2345的通信。
三、Attach 在 JVM 中实现的源码分析
源码的分析主要分三阶段进行，这里要达到的目的是，弄 Attach 的清楚来龙去脉，本文的所有源码都是基于 Open JDK 1.8的，大家可以自行去下载 Open JDK 1.8 的源码。
3.1、目标JVM 对OS信号监听的实现
或许你会想，在最开始的时候，目标 JVM 是怎么知道有某个进程想 attach 它自己的？答案很简单，就是目标 JVM 在启动的时候，在 JVM 内部启动了一个监听线程，这个线程的名字叫“Signal Dispatcher”，该线程的作用是，监听并处理 OS 的信号。至于什么是 OS 的信号（可以自行百度或 Google），简单理解就是，Linux系统允许进程与进程之间通过过信号的方式进行通信，如触发某个操作（操作由接受到信号的进程自定义）。如平常我们用的最多的就是 kill -9 ${pid}来杀死某个进程，kill进程通过向${pid}的进程发送一个编号为“9”号的信号，来通知系统强制结束${pid}的生命周期。
接下来我们就通过源码截图的方式来呈现一下“Signal Dispatcher”线程的创建过程。
首先进入 JVM 的启动类：/jdk/src/share/bin/main.c
这个类里边最重要的一个方法就是最后的JLI_Launch，这个方法的实现存在于jdk/src/share/bin/java.c 中（大家应该都不陌生平时我们运行 java 程序时，都是采用 java com.***.Main来启动的吧）。
这个方法中，进行了一系列必要的操作，如libjvm.so的加载、参数解析、Classpath 的获取和设置、系统属性的设置、JVM 初始化等等，不过和本文相关的主要是299行处的 JVMInit 方法，接下来我们看下这个方法的实现（位于/jdk/src/solaris/bin/java_md_solinux.c）。
这里请关注两个点，ContinueInNewThread方法 和 ifn 入参。ContinueInNewThread位于 java.c中，而 ifn 则携带了libjvm.so中的几个非常重要的函数(CreateJavaVM/GetDefaultJavaVMInitArgs/GetCreatedJavaVMs)，这里我们重点关注CreateJavaVM
可以看出，这里进行了 JavaMainArgs 参数设置，设置完成之后，在1904行处调用了 ContinueInNewThread0 （位于/jdk/src/solaris/bin/java_md_solinux.c）方法，该方法中传入了 JavaMain 函数指针和 args 参数，这二者至关重要。接下来看下其源码
这里最关键的点在于，如果是 linux 环境下，则创建了一个 pthread_t 的线程来运行传入的 JavaMain 函数，并且将 args 参数也一并传入了。这时候，我们唯一要关注的便是 JavaMain （在jdk/src/share/bin/java.c ）函数，请看源码
这里只截取了一部分代码，和本小节相关的函数为InitializeJVM函数，在这个函数中，调用CreateJavaVM方法，这个方法就是之前在加载 libjvm.so 的时候，从动态库中获取的，首先看InitializeJVM的源码
1145行处，调用 CreateJavaVM（定义在hotspot/src/share/vm/prims/jni.cpp） 方法，来进行 JVM 虚拟机的真正创建过程，源码如下
这里只关注最核心的方法 Threads::create_vm（hotspot/src/share/vm/runtime/Thread.cpp） 方法，在这个方法中，进行了大量的初始化操作，不过，这里我们只关注其中的一个点，就是 os::signal_init() 方法的调用，这就是启动“Signal Dispatcher”线程的地方。先看 create_vm 的源码
.....此处省略很多暂时不需要关注的代码
3612行处，看到了os::signal_init() 的调用（hotspot/src/share/vm/runtime/os.cpp），这就是我们要找的。接着，我们看下其具体实现
这里的完全可以看出来，在此函数中357行处，创建了一个 java 线程，用于执行signal_thread_entry 函数，那我们来看看，这个 signal_thread_entry 函数到底做了什么？
函数里面意思已经很清晰明了了，首先在242行处，有一个os::signal_wait()的调用，该调用的主要是阻塞当前线程，并等待接收系统信号，然后再根据接收到的信号 sig 做 switch 逻辑，对于不同的信号做不同的处理。至此，关于“目标 JVM 对OS信号监听的实现”这一点，就已经分析结束了。简单的一句话总结就是，JVM 在启动的时候，会创建一个名为“Signal Dispatcher”的线程用于接收os 的信号，以便对不同信号分别做处理。
3.2、文件 Socket 通信的通道的创建
经过3.1的分析，我们已经知道在 JVM 启动之后，内部会有线程监听并处理 os 的信号，那么，这个时候，如果我们想和已经启动的 JVM 建立通信，当然就可以毫不犹豫的使用信号来进行了。不过，基于信号的通信，也是存在限制的，一方面，os 支持的信号是有限的，二来信号的通信往往是单向的，不方便通信双方进行高效的通信。基于这些，笔者认为，为了使得 Client JVM 和 Target JVM 更好的通信，就采用了 Socket 通信来实现二者的通信。那接下来我们看看，这个通道究竟是如何创建的？
当我们需要 attach 到某个目标 JVM 进程上去的时候，我们通常会写如下代码
这样我们就能得到目标 JVM 的相关信息了，是不是很简单？不过，今天我们要做的可不是这么简单的事情，我们需要深入其后，了解其根本。接下来我们就以com.sun.tools.attach.VirtualMachine的 attach 方法入手，逐层揭开其神秘面纱。
这是attach的源码，入参为目标 JVM 的进程 ID，其实现委派给了 AttachProvider 了，通过provider.attachVirtualMachine(id);来实现真正的 attach 操作。由于 AttachProvider 是个抽象类，所以这个方法的真正实现在子类中，在 Linux 环境下，我们看 sun.tools.attach.BsdAttachProvider 的实现。
这个方法非常简单，就是 new 了一个 BsdVirtualMachine 对象，并且把目标进程 ID 带过去了。看sun.tools.attach.BsdVirtualMachine的构造函数
首先看71行处的findSocketFile(pid);这里是找对应的 socket （/tmp/.java_pid${pid}）文件，这个文件就是我们在第二大点图中画出来的，用于进程间通信的 socket 文件，如果不存在，即第一次进入该方法的时候。这时会运行到74行的createAttachFile(f.getPath());来创建一个attach 文件，socket 文件的命名方式为：/tmp/../.attach_pid${pid}，关于这两个方法（findSocketFile和createAttachFile）的具体实现，这里就不展开了，感兴趣的可以直接去查看jdk/src/solaris/native/sun/tools/attach/BsdVirtualMachine.c的相关源码。然后就会运行到一个非常关键的方法76行的sendQuitTo(pid);这个方法的实现，我们等会进入BsdVirtualMachine.c看下源码，其主要目的就是给该进程发送一个信号。之后会进入到82行处的 do...while循环，自旋反复轮询指定的次数来获取该 socket 文件的路径，直到超时或者 path（即 socket 文件路径） 不为空，最后在106行处，建立一个 socket，并且在108行处通过 path 进行 socket 的连接，从而完成了客户端（Client JVM）到目标进程（Target JVM）的 socket 通道建立。不过，请打住，这里是不是少了点什么？我相信细心的你肯定发现了，至少还存2个问题，1. Target JVM 的 socket 服务端是何时创建的？2. 用于通信的 socket 文件是在哪里创建的？带着这两个问题，我们进入76行关键方法sendQuitTo(pid);的源码解读。
看到119行的时候，是不是觉得这里必然和前面3.1中大篇幅分析的信号处理线程“Signal Dispatcher”有种必然联系了？没错，这里就是通过 kill 这个系统调用像目标 JVM，发送了一个 SIGQUIT 的信号，该信号是个#define，即宏，表示的数字“3”，即类似在 linux 命令行执行了“kill -3 ${pid}”的操做（其实，这个命令正是获取目标 JVM 线程 dump 文件的一种方式，读者可以试试）。既然这里向目标 JVM 发送了这么个信号，那么我们现在就移步到3.1中讲到过的 signal_thread_entry 方法中去。这里的250行，我们看到了有个对 SIGBREAK（宏定义） 信号处理的 case，事实上，这个SIGBREAK和前面客户端发过来的SIGQUIT 的值是一样的，都是“3”，熟悉 C语言的读者应该不难理解。所以，当客户端发送这个信号给目标 JVM 时，就理所应当的进入了这个 case 的处理逻辑。这里的260行到273行，事实上就是对“kill -3 ${pid}”执行时对应的处理逻辑“进行目标 JVM 进程的线程 dump 操作”。现在我们重点关注一下253行的 if 语句，第一个 boolean 值，某认情况下是false（可通过/hotspot/src/share/vm/runtime/globals.c）查看，表示某认情况下是不禁止attach 机制的，于是就会进入第二个条件的判断AttachListener::is_init_trigger()，这里的判断还是比较有意思的（即判断当前杀是不是需要进行 attach 的初始化操作），我们进入源码，源码的文件为：hotspot/src/os/bsd/vm/attachListener.cpp
方法进入的第一行，即判断是不是在 JVM 启动时就初始化或者之前已经初始化过，如果是，则直接返回，否则继续当前方法。方法的第500行，是在处理/tmp/attach_pid${pid}路径（这个文件就是 Client JVM 在attach 时创建的），并把 path 传入502行定义的宏进行判断，如果这个文件存在，且刚好是当前用户的创建的 attach_pid 文件，则进入507行的 init() 方法，否则什么也不做，返回 false。接着我们进入 init 的源码
从源码中，我们可以看出来，这里最主要的方法是，创建一个名为“Attach Listener”的线程，该线程启动后会调用attach_listener_thread_entry这个方法（505行），来完成有关的任务处理。进入attach_listener_thread_entry方法
这里需要关注两个方面的内容，第一个为405行的AttachListener::pd_init()，第二为410行中的 for 循环里面的内容。
首先看AttachListener::pd_init()
以上的 pd_init() 方法是在hotspot/src/os/bsd/vm/attachListener_bsd.cpp中实现的，所以我们看472行的代码，调用了BsdAttachListener::init()一个这样的方法，该方法的主要作用就是生产 socket 通信文件的。源码如下
从方法的注释，就能看出这个方法就是用来创建一个 socket 的 listener 端，即服务端的。具体的创建过程，代码写的已经很清楚了，我做下简单描述，180行处，构建 socket 通信文件的路径（/tmp/.java_pid${pid}）,190行，创建一个 socket，其中关注 socket 函数的第一个参数，当为 PF_UNIX 时，表示创建文件 socket，详情可以参考 linux 的 socket 函数说明，然后到198行，将 socket 文件 path 拷贝到 socket 通信地址中，即以此文件作为通信地址，然后在200行时，将 socket 和该 socket 文件地址做一个绑定，207行，表示对当前 socket 进行监听（数字5表示监听时可容纳客户端连接的队列的大小），如果有Client JVM 的客户端连接上来，并且发送了相关消息，该服务端就可以对其进行相应处理了。至此，进程间 socket 的通信的通道就建立了。
其次看下 for 循环做了什么？其实很简单，411行，BsdAttachListener::dequeue() 从监听器的队列中拿到一个 Client JVM 的AttachOperation（当客户端 attach 上 target JVM 之后，往目标 JVM 发送任意 socket 信息，都会被放置到这个队列中，等待被处理），此处会被阻塞，直到收到请求，如下源码的338行，处于 socket 的 accept 函数处于等待状态，等待来之客户端 JVM 的相关请求
所以，只要收到一个AttachOperation不为“detachall”的操纵请求就会进入到425行处进行处理，这里的目的就是为了拿到对应的操作AttachOperationFunctionInfo对象，如果不为空，则调用其func，来完成对客户端的响应，如442行所示。AttachOperationFunctionInfo的定义如下
从这里，我们可以看到，threaddump、dumpheap 等我们常用的操纵。到此为止，水落石出，涉及到 attach 操纵的服务端的原理基本已经理清楚了。接下来我们以 jstack 为例，来看下客户端 JVM 是不是确实是以我们上面分析出来的方式与服务端 JVM 进行通信，并获取到它想要的内容的。
3.3 JVM 对 Attach 上来的进程的命令的响应，以 jstack -l 为例
我们首先进入 jstack 的源码，源码目录为jdk/src/share/classes/sun/tools/jstack/JStack.java。进入 main 函数
当采用 jstack -l 时，会走107行的 else 分支，最终执行runThreadDump方法
163行：执行VirtualMachine.attach(pid);则会达到3.1、3.2的效果，即服务端已经做好了所有 attach 所需的准备，如 socket 服务端、socket 通信文件、socket 请求处理线程“Attach Listener”。
181行：通过调用 HotSpotVirtualMachine 对象的 remoteDataDump 函数进行远程 dump，获得输入流 InputStream in，最后通过读取输入流的内容，来通过标准输出流输出从服务端获取的数据。至此，jstack -l 命令完成所有操作。
接下来，我们重点分析HotSpotVirtualMachine 对象的 remoteDataDump 函数。首先上HotSpotVirtualMachine 对象的 remoteDataDump的源码
请注意174行的 cmd 字符串为“threaddump”，这个和3.2中AttachOperationFunctionInfo的定义是吻合的，也就是说最终在服务端会调用 thread_dump 方法，来执行线程 dump，并将结果返回给客户端。接着我们看下下 executeCommand方法，该方法只是简单的调用 execute 方法，如下
exectue 方法在该类中为抽象方法，其具体实现放在了sun.tools.attach.BsdVirtualMachine.java中，我们看下在其具体实现这里可是最最关键的地方了
147行：创建一个 socket，这个是 socket 是一个 jni 本地方法，有兴趣的可以去看对应的实现，源码在jdk/src/solaris/native/sun/tools/attach/BsdVirtualMachine.c中，其关键操作就一个return socket(PF_UNIX, SOCK_STREAM, 0);
151行：这里也是一个本地方法，调用了 connect(s,p),这里的 p 就是 attach 时产生的/tmp/.java_pid${pid}的 socket 文件路径，这样，客户端就和目标 JVM 连接上了，该方法同样是一个 native 方法，可以通过查看BsdVirtualMachine.c的源码来进行查看，如下，重点在82行使用 socket 文件路径作为连接地址 和 84行与目标 JVM 端启动的 socket server 建立连接；
161~174行：想 Target JVM 端发送命令 threaddump、以及可能存在的相关参数，如-l；这里的 writeString 同样是一个本地方法，涉及到的底层操作就是一个 C 语言库的 write 操作，感兴趣的可以自己看源码，不再赘述；
178~213行：这里就是对当前 socket 连接，构建一个 SocketInputStream 对象，并等待Target JVM 端数据完全返回，最后将这个 InputStream 对象作为方法返回参数返回。
四、总结
本文结合 Attach 的原理和使用案例（jstack -l），对 Attach 的各个方面都进行了深入的分析和总结，希望能对有需要的同学有所帮助。当然，以上均为本人个人所学，所以难免会有错误和疏忽的地方，如果您发现了，还麻烦指出。