JVM源碼分析之Attach機制實現完全解讀
Attach是什么
在講這個之前,我們先來點大家都知道的東西,當我們感覺線程一直卡在某個地方,想知道卡在哪里,首先想到的是進行線程dump,而常用的命令是jstack ,我們就可以看到如下線程棧了
大家是否注意過上面圈起來的兩個線程,”Attach Listener”和“Signal Dispatcher”,這兩個線程是我們這次要講的Attach機制的關鍵,先偷偷告訴各位,其實Attach Listener這個線程在jvm起來的時候可能并沒有的,后面會細說。
那Attach機制是什么?說簡單點就是jvm提供一種jvm進程間通信的能力,能讓一個進程傳命令給另外一個進程,并讓它執(zhí)行內部的一些操作,比如說我們?yōu)榱俗屃硗庖粋€jvm進程把線程dump出來,那么我們跑了一個jstack的進程,然后傳了個pid的參數,告訴它要哪個進程進行線程dump,既然是兩個進程,那肯定涉及到進程間通信,以及傳輸協(xié)議的定義,比如要執(zhí)行什么操作,傳了什么參數等
Attach能做些什么
總結起來說,比如內存dump,線程dump,類信息統(tǒng)計(比如加載的類及大小以及實例個數等),動態(tài)加載agent(使用過btrace的應該不陌生),動態(tài)設置vm flag(但是并不是所有的flag都可以設置的,因為有些flag是在jvm啟動過程中使用的,是一次性的),打印vm flag,獲取系統(tǒng)屬性等,這些對應的源碼(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線程的創(chuàng)建
前面也提到了,jvm在啟動過程中可能并沒有啟動Attach Listener這個線程,可以通過jvm參數來啟動,代碼 (Threads::create_vm)如下:
- if (!DisableAttachMechanism) {
- if (StartAttachListener || AttachListener::init_at_startup()) {
- AttachListener::init();
- }
- }
- ool 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()并不會被執(zhí)行,而Attach Listener線程正是在此方法里創(chuàng)建的
既然在啟動的時候不會創(chuàng)建這個線程,那么我們在上面看到的那個線程是怎么創(chuàng)建的呢,這個就要關注另外一個線程“Signal Dispatcher”了,顧名思義是處理信號的,這個線程是在jvm啟動的時候就會創(chuàng)建的,具體代碼就不說了。
下面以jstack的實現來說明觸發(fā)Attach這一機制進行的過程,jstack命令的實現其實是一個叫做JStack.java的類,查看jstack代碼后會走到下面的方法里
請注意VirtualMachine.Attach(pid);這行代碼,觸發(fā)Attach pid的關鍵,如果是在linux下會走到下面的構造函數
這里要解釋下代碼了,首先看到調用了createAttachFile方法在目標進程的cwd目錄下創(chuàng)建了一個文件/proc//cwd/.Attach_pid,這個在后面的信號處理過程中會取出來做判斷(為了安全),另外我們知道在linux下線程是用進程實現的,在jvm啟動過程中會創(chuàng)建很多線程,比如我們上面的信號線程,也就是會看到很多的pid(應該是LWP),那么如何找到這個信號處理線程呢,從上面實現來看是找到我們傳進去的pid的父進程,然后給它的所有子進程都發(fā)送一個SIGQUIT信號,而jvm里除了信號線程,其他線程都設置了對此信號的屏蔽,因此收不到該信號,于是該信號就傳給了“Signal Dispatcher”,在傳完之后作輪詢等待看目標進程是否創(chuàng)建了某個文件,AttachTimeout默認超時時間是5000ms,可通過設置系統(tǒng)變量sun.tools.Attach.AttachTimeout來指定,下面是Signal Dispatcher線程的entry實現
當信號是SIGBREAK(在jvm里做了#define,其實就是SIGQUIT)的時候,就會觸發(fā)
AttachListener::is_init_trigger()的執(zhí)行
一開始會判斷當前進程目錄下是否有個.Attach_pid文件(前面提到了),如果沒有就會在/tmp下創(chuàng)建一個/tmp/.Attach_pid,當那個文件的uid和自己的uid是一致的情況下(為了安全)再調用init方法
此時水落石出了,看到創(chuàng)建了一個線程,并且取名為Attach Listener。再看看其子類LinuxAttachListener的init方法
看到其創(chuàng)建了一個監(jiān)聽套接字,并創(chuàng)建了一個文件/tmp/.java_pid,這個文件就是客戶端之前一直在輪詢等待的文件,隨著這個文件的生成,意味著Attach的過程圓滿結束了。
Attach listener接收請求
看看它的entry實現Attach_listener_thread_entry
從代碼來看就是從隊列里不斷取AttachOperation,然后找到請求命令對應的方法進行執(zhí)行,比如我們一開始說的jstack命令,找到 { “threaddump”, thread_dump }的映射關系,然后執(zhí)行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在那里,當來了請求,然后就會創(chuàng)建一個套接字,并讀取數據,構建出LinuxAttachOperation返回并執(zhí)行。
整個過程就這樣了,從Attach線程創(chuàng)建到接收請求,處理請求。