共计 3547 个字符，预计需要花费 9 分钟才能阅读完成。
本文来自: PerfMa 技术社区
PerfMa(笨马网络)官网
Attach 是什么
在讲这个之前，我们先来点大家都知道的东西，当我们感觉线程一直卡在某个地方，想知道卡在哪里，首先想到的是进行线程 dump，而常用的命令是 jstack，我们就可以看到如下线程栈了
大家是否注意过上面圈起来的两个线程，”Attach Listener”和“Signal Dispatcher”，这两个线程是我们这次要讲的 Attach 机制的关键，先偷偷告诉各位，其实 Attach Listener 这个线程在 jvm 起来的时候可能并没有的，后面会细说。
那 Attach 机制是什么？说简单点就是 jvm 提供一种 jvm 进程间通信的能力，能让一个进程传命令给另外一个进程，并让它执行内部的一些操作，比如说我们为了让另外一个 jvm 进程把线程 dump 出来，那么我们跑了一个 jstack 的进程，然后传了个 pid 的参数，告诉它要哪个进程进行线程 dump，既然是两个进程，那肯定涉及到进程间通信，以及传输协议的定义，比如要执行什么操作，传了什么参数等
Attach 能做些什么
总结起来说，比如内存 dump，线程 dump，类信息统计 (比如加载的类及大小以及实例个数等)，动态加载 agent(使用过 btrace 的应该不陌生)，动态设置 vm flag(但是并不是所有的 flag 都可以设置的，因为有些 flag 是在 jvm 启动过程中使用的，是一次性的)，打印 vm flag，获取系统属性等，这些对应的源码(AttachListener.cpp) 如下
static AttachOperationFunctionInfo funcs[] = {{ "agentProperties", get_agent_properties},
{"datadump", data_dump},
{"dumpheap", dump_heap},
{"load", JvmtiExport::load_agent_library},
{"properties", get_system_properties},
{"threaddump", thread_dump},
{"inspectheap", heap_inspection},
{"setflag", set_flag},
{"printflag", print_flag},
{"jcmd", jcmd},
{NULL, NULL}
};后面是命令对应的处理函数。
Attach 在 jvm 里如何实现的
Attach Listener 线程的创建
前面也提到了，jvm 在启动过程中可能并没有启动 Attach Listener 这个线程，可以通过 jvm 参数来启动，代码（Threads::create_vm）如下：
if (!DisableAttachMechanism) {if (StartAttachListener || AttachListener::init_at_startup()) {AttachListener::init();
}
}
bool AttachListener::init_at_startup() {if (ReduceSignalUsage) {return true;} else {return false;}
}其中 DisableAttachMechanism，StartAttachListener，ReduceSignalUsage 均默认是 false(globals.hpp)
product(bool, DisableAttachMechanism, false,
"Disable mechanism that allows tools to Attach to this VM”)
product(bool, StartAttachListener, false,
"Always start Attach Listener at VM startup")
product(bool, ReduceSignalUsage, false,
"Reduce the use of OS signals in Java and/or the VM”)因此 AttachListener::init()并不会被执行，而 Attach Listener 线程正是在此方法里创建的
既然在启动的时候不会创建这个线程，那么我们在上面看到的那个线程是怎么创建的呢，这个就要关注另外一个线程“Signal Dispatcher”了，顾名思义是处理信号的，这个线程是在 jvm 启动的时候就会创建的，具体代码就不说了。
下面以 jstack 的实现来说明触发 Attach 这一机制进行的过程，jstack 命令的实现其实是一个叫做 JStack.java 的类，查看 jstack 代码后会走到下面的方法里
请注意 VirtualMachine.Attach(pid); 这行代码，触发 Attach pid 的关键，如果是在 linux 下会走到下面的构造函数
这里要解释下代码了，首先看到调用了 createAttachFile 方法在目标进程的 cwd 目录下创建了一个文件 /proc//cwd/.Attach_pid，这个在后面的信号处理过程中会取出来做判断(为了安全)，另外我们知道在 linux 下线程是用进程实现的，在 jvm 启动过程中会创建很多线程，比如我们上面的信号线程，也就是会看到很多的 pid(应该是 LWP)，那么如何找到这个信号处理线程呢，从上面实现来看是找到我们传进去的 pid 的父进程，然后给它的所有子进程都发送一个 SIGQUIT 信号，而 jvm 里除了信号线程，其他线程都设置了对此信号的屏蔽，因此收不到该信号，于是该信号就传给了“Signal Dispatcher”，在传完之后作轮询等待看目标进程是否创建了某个文件，AttachTimeout 默认超时时间是 5000ms，可通过设置系统变量 sun.tools.Attach.AttachTimeout 来指定，下面是 Signal Dispatcher 线程的 entry 实现
当信号是 SIGBREAK(在 jvm 里做了 #define，其实就是 SIGQUIT)的时候，就会触发
AttachListener::is_init_trigger() 的执行
一开始会判断当前进程目录下是否有个.Attach_pid 文件（前面提到了），如果没有就会在 /tmp 下创建一个 /tmp/.Attach_pid，当那个文件的 uid 和自己的 uid 是一致的情况下（为了安全）再调用 init 方法
此时水落石出了，看到创建了一个线程，并且取名为 Attach Listener。再看看其子类 LinuxAttachListener 的 init 方法
看到其创建了一个监听套接字，并创建了一个文件 /tmp/.java_pid，这个文件就是客户端之前一直在轮询等待的文件，随着这个文件的生成，意味着 Attach 的过程圆满结束了。
Attach listener 接收请求
看看它的 entry 实现 Attach_listener_thread_entry
从代码来看就是从队列里不断取 AttachOperation，然后找到请求命令对应的方法进行执行，比如我们一开始说的 jstack 命令，找到 {“threaddump”, thread_dump}的映射关系，然后执行 thread_dump 方法
再来看看其要调用的 AttachListener::dequeue()，
AttachOperation* AttachListener::dequeue() {JavaThread* thread = JavaThread::current();
ThreadBlockInVM tbivm(thread);
thread->set_suspend_equivalent();
// cleared by handle_special_suspend_equivalent_condition() or
// java_suspend_self() via check_and_wait_while_suspended()
AttachOperation* op = LinuxAttachListener::dequeue();
// were we externally suspended while we were waiting?
thread->check_and_wait_while_suspended();
return op;
}最终调用的是 LinuxAttachListener::dequeue()，
我们看到如果没有请求的话，会一直 accept 在那里，当来了请求，然后就会创建一个套接字，并读取数据，构建出 LinuxAttachOperation 返回并执行。
整个过程就这样了，从 Attach 线程创建到接收请求，处理请求。
一起来学习吧：
PerfMa KO 系列课之 JVM 参数【Memory 篇】
记一次微服务耗时毛刺排查