這個Bug的排查之路,真的太有趣了

這是why哥的第

92

篇原創文章

這個Bug的排查之路,真的太有趣了

在《深入理解Java虛擬機器》一書中有這樣一段程式碼:

public class VolatileTest {    public static volatile int race = 0;    public static void increase() {        race++;    }    private static final int THREADS_COUNT=20;    public static void main(String[] args) {        Thread[] threads = new Thread[THREADS_COUNT];        for(int i = 0; i < THREADS_COUNT; i++){           new Thread(new Runnable() {               @Override               public void run() {                   for (int i = 0; i < 10000; i++) {                       increase();                   }               }           })。start();        }        //等待所有累加執行緒都結束        while(Thread。activeCount()>1)            Thread。yield();        System。out。println(race);    }}

你看到這段程式碼的第一反應是什麼?

是不是關注點都在 volatile 關鍵字上。

甚至馬上就要開始脫口而出:volatile 只保證可見性,不保證原子性。而程式碼中的

race++

不是原子性的操作,巴拉巴拉巴拉。。。

反正我就是這樣的:

這個Bug的排查之路,真的太有趣了

當他把程式碼發給我,我在 idea 裡面一貼上,然後把 main 方法執行起來後,神奇的事情出現了。

這個程式碼真的沒有執行到輸出語句,也沒有任何報錯。

看起來就像是死迴圈了一樣。

不信的話,你也可以放到你的 idea 裡面去執行一下。

等等……

死迴圈?

程式碼裡面不是就有一個死迴圈嗎?

//等待所有累加執行緒都結束while(Thread。activeCount()>1)    Thread。yield();

這段程式碼能有什麼小心思呢?看起來人畜無害啊。

但是程式設計師的直覺告訴我,這個地方就是有問題的。

活躍執行緒一直是大於 1 的,所以導致 while 一直在死迴圈。

算了,不想了,先 Debug 看一眼吧。

Debug 了兩遍之後,我才發現,這個事情,有點意思了。

因為 Debug 的情況下,程式竟然正常結束了。

這個Bug的排查之路,真的太有趣了

啥情況啊?

分析一波走起。

為啥停不下來?

我是怎麼分析這個問題的呢。

我就把程式又 Run 了起來,控制檯還是啥輸出都沒有。

我就盯著這個控制檯想啊,會是啥原因呢?

這樣幹看著也不是辦法啊。

反正我現在就是咬死這個 while 迴圈是有問題的,所以為了排除其他的干擾項。

我把程式簡化到了這個樣子:

public class VolatileTest {    public static volatile int race = 0;    public static void main(String[] args) {        while(Thread。activeCount()>1)            Thread。yield();        System。out。println(“race = ” + race);    }}

執行起來之後,還是沒有執行到輸出語句,也就側面證實了我的想法:while 迴圈有問題。

而 while 迴圈的條件就是

Thread。activeCount()>1

朝著這個方向繼續想下去,就是看看當前活躍執行緒到底有幾個。

於是程式又可以簡化成這樣:

這個Bug的排查之路,真的太有趣了

直接執行看到輸出結果是 2。

這個Bug的排查之路,真的太有趣了

用 Debug 模式執行時返回的是 1。

對比這執行結果,我心裡基本上就有數了。

先看一下這個 activeCount 方法是幹啥的:

這個Bug的排查之路,真的太有趣了

注意看畫著下劃線的地方:

返回的值是一個 estimate。

estimate 是啥?

這個Bug的排查之路,真的太有趣了

你看,又在我這裡學一個高階詞彙。真是 very good。

返回的是一個預估值。

為什麼呢?

因為我們呼叫這個方法的一刻獲取到值之後,執行緒數還是在動態變化的。

也就是說返回的值只代表你呼叫的那一刻有幾個活躍執行緒,也許當你呼叫完成後,有一個執行緒就立馬嗝屁了。

所以,這個值是個預估值。

這一瞬間,我突然想到了量子力學中的測不準原理。

這個Bug的排查之路,真的太有趣了

你不可能同時知道一個粒子的位置和它的速度,就像在多執行緒高併發的情況下你不可能同時知道呼叫 activeCount 方法得到的值和你要用這個值的時刻,這個值的真實值是多少。

你看,剛學完英語又學量子力學。

這個Bug的排查之路,真的太有趣了

好了,回到程式裡面。

雖然註釋裡面說了返回值是 estimate 的,但是在我們的程式中,並不存在這樣的問題。

看到 activeCount 方法的實現之後:

public static int activeCount() {    return currentThread()。getThreadGroup()。activeCount();}

我又想到,既然在直接 Run 的情況下,程式返回的數是 2,那我看看到底有那些執行緒呢?

其實最開始我想著去 Debug 一下的,但是 Debug 的情況下,返回的數是 1。我意識到,這個問題肯定和 idea 有關,而且必須得用日誌除錯大法才能知道原因。

於是,我把程式改成了這樣:

這個Bug的排查之路,真的太有趣了

直接 Run 起來,可以看到,確實有兩個執行緒。

一個是 main 執行緒,我們熟悉。

一個是 Monitor Ctrl-Break 執行緒,我不認識。

但是當我用 Debug 的方式執行的時候,有意思的事情就發生了:

這個Bug的排查之路,真的太有趣了

Monitor Ctrl-Break 執行緒不見了!?

於是,我問他:

這個Bug的排查之路,真的太有趣了

是啊,問題解決了,但是啥原因啊?

為什麼 Run 不可以執行,而 Debug 可以執行呢?

這個Bug的排查之路,真的太有趣了

當前執行緒有哪些?

我們先梳理一下當前執行緒有哪些吧。

可以使用下面的程式碼獲取當前所有的執行緒:

public  static Thread[] findAllThread(){    ThreadGroup currentGroup =Thread。currentThread()。getThreadGroup();    while (currentGroup。getParent()!=null){        // 返回此執行緒組的父執行緒組        currentGroup=currentGroup。getParent();    }    //此執行緒組中活動執行緒的估計數    int noThreads = currentGroup。activeCount();    Thread[] lstThreads = new Thread[noThreads];    //把對此執行緒組中的所有活動子組的引用複製到指定陣列中。    currentGroup。enumerate(lstThreads);    for (Thread thread : lstThreads) {        System。out。println(“執行緒數量:”+noThreads+“ ” +                “執行緒id:” + thread。getId() +                 “ 執行緒名稱:” + thread。getName() +                 “ 執行緒狀態:” + thread。getState());    }    return lstThreads;}

執行之後可以看到有 6 個執行緒:

這個Bug的排查之路,真的太有趣了

也就是說,在 idea 裡面,一個 main 方法 Run 起來之後,即使什麼都不幹,也會有 6 個執行緒執行。

這 6 個執行緒分別是幹啥的呢?

我們一個個的說。

Reference Handler 執行緒:

JVM 在建立 main 執行緒後就建立 Reference Handler 執行緒,其優先順序最高,為 10,它主要用於處理引用物件本身(軟引用、弱引用、虛引用)的垃圾回收問題。

Finalizer 執行緒:

這個執行緒也是在 main 執行緒之後建立的,其優先順序為10,主要用於在垃圾收集前,呼叫物件的 finalize() 方法。

關於 Finalizer 執行緒的幾點:

1)只有當開始一輪垃圾收集時,才會開始呼叫 finalize() 方法;因此並不是所有物件的 finalize() 方法都會被執行;

2)該執行緒也是 daemon 執行緒,因此如果虛擬機器中沒有其他非 daemon 執行緒,不管該執行緒有沒有執行完 finalize() 方法,JVM 也會退出;

3) JVM在垃圾收集時會將失去引用的物件包裝成 Finalizer 物件(Reference的實現),並放入 ReferenceQueue,由 Finalizer 執行緒來處理;最後將該 Finalizer 物件的引用置為 null,由垃圾收集器來回收;

4) JVM 為什麼要單獨用一個執行緒來執行 finalize() 方法呢?如果 JVM 的垃圾收集執行緒自己來做,很有可能由於在 finalize() 方法中誤操作導致 GC 執行緒停止或不可控,這對 GC 執行緒來說是一種災難。

Attach Listener 執行緒:

Attach Listener 執行緒是負責接收到外部的命令,而對該命令進行執行的並且把結果返回給傳送者。通常我們會用一些命令去要求 jvm 給我們一些反饋資訊。

如:java -version、jmap、jstack 等等。如果該執行緒在 jvm 啟動的時候沒有初始化,那麼,則會在使用者第一次執行 jvm 命令時,得到啟動。

Signal Dispatcher 執行緒:

前面我們提到第一個 Attach Listener 執行緒的職責是接收外部 jvm 命令,當命令接收成功後,會交給 signal dispather 執行緒去進行分發到各個不同的模組處理命令,並且返回處理結果。signal dispather 執行緒也是在第一次接收外部 jvm 命令時,進行初始化工作。

main 執行緒:

呃,這個不說了吧。大家都知道。

Monitor Ctrl-Break 執行緒:

先買個關子,下一小節專門聊聊這個執行緒。

上面執行緒的作用,我是從這個網頁搬運過來的,還有很多其他的執行緒,大家可以去看看:

http://ifeve。com/jvm-thread/

我好事做到底,直接給你來個長截圖,一網打盡。

你先把圖片儲存起來,後面慢慢看:

這個Bug的排查之路,真的太有趣了

現在跟著我去探尋 Monitor Ctrl-Break 執行緒的秘密。

繼續挖掘

問題解決了,但是問題背後的問題,還沒有得到解決:

Monitor Ctrl-Break 執行緒是啥?它是怎麼來的?

我們先 jstack 一把看看執行緒堆疊唄。

而在 idea 裡面,這裡的“照相機”圖示,就是 jstack 一樣的功能。

這個Bug的排查之路,真的太有趣了

我把程式恢復為最初的樣子,然後把“照相機”就這麼輕輕的一點:

這個Bug的排查之路,真的太有趣了

從執行緒堆疊裡面可以看到 Monitor Ctrl-Break 執行緒來自於這個地方:

com。intellij。rt。execution。application。AppMainV2$1。run(AppMainV2。java:64)

而這個地方,一看名稱,是 idea 的原始碼了啊?

不屬於我們的專案裡面了,這咋個搞呢?

思考了一下,想到了一種可能,於是我決定用 jps 命令驗證一下:

這個Bug的排查之路,真的太有趣了

看到執行結果的時候我笑了,一切就說的通了。

果然,是用了 -javaagent 啊。

那麼 javaagent 是什麼?

好的,要問答好這個問題,就得另起一篇文章了,本文不討論,先欠著。

只是簡單的提一下。

你在命令列執行

java

命令,會輸出一大串東西,其中就包含這個:

這個Bug的排查之路,真的太有趣了

什麼語言代理的,看不懂。

叫我們參閱 java。lang。instrument。

那它又是拿來幹啥的?

簡單的一句話解釋就是:

使用 instrument 可以更加方便的使用位元組碼增強的技術,可以認為是一種 jvm 層面的截面。不需要對程式原始碼進行任何侵入,就可以對其進行增強或者修改。總之,有點 AOP 內味。

-javaagent

命令後面需要緊跟一個 jar 包。

-javaagent:[=<選項>]

instrument 機制要求,這個 jar 包必須有 MANIFEST。MF 檔案,而 MANIFEST。MF 檔案裡面必須有 Premain-Class 這個東西。

所以,回到我們的程式中,看一下 javaagent 後面跟的包是什麼。

在哪看呢?

就這個地方:

這個Bug的排查之路,真的太有趣了

你把它點開,命令非常的長。但是我們關心的

-javaagent

就在最開始的地方:

這個Bug的排查之路,真的太有趣了

-javaagent:D:\Program Files\JetBrains\IntelliJ IDEA 2019。3。4\lib\idea_rt。jar=61960

可以看到,後面跟著的 jar 包是 idea_rt,按照檔案目錄找過去,也就是在這裡:

這個Bug的排查之路,真的太有趣了

我們解壓這個 jar 包,開啟它的 MANIFEST。MF 檔案:

這個Bug的排查之路,真的太有趣了

而這個類,不就是我們要找的它嗎:

這個Bug的排查之路,真的太有趣了

此時此刻,我們距離真相,只有一步之遙了。

進到對應的包裡,發現有三個 class 類:

這個Bug的排查之路,真的太有趣了

主要關注 AppMainV2。class 檔案:

這個Bug的排查之路,真的太有趣了

在這個檔案裡面,就有一個 startMonitor 方法:

這個Bug的排查之路,真的太有趣了

我說過什麼來著?

來,大聲的跟我念一遍:原始碼之下無秘密。

Monitor Ctrl-Break 執行緒就是這裡來的。

而仔細看一眼這裡的程式碼,這個執行緒在幹啥事呢?

Socket client = new Socket(“127。0。0。1”, portNumber);

啊,我的天吶,來看看這個可愛的小東西,socket 程式設計,太熟悉了,簡直是夢迴大學實驗課的時候。

它是連結到 127。0。0。1 的某個埠上,然後 while(true) 死迴圈等待接收命令。

那麼這個埠是哪個埠呢?

就是這裡的 62325:

這個Bug的排查之路,真的太有趣了

需要注意的是,這個埠並不是固定的,每次啟動這個埠都會變化。

玩玩它

既然它是 Socket 程式設計,那麼我就玩玩它唄。

先搞個程式:

public class SocketTest{    public static void main(String[] args) throws IOException {        ServerSocket serverSocket = new ServerSocket(12345);        System。out。println(“等待客戶端連線。”);        Socket socket = serverSocket。accept();        System。out。println(“有客戶端連線上了 ”+ socket。getInetAddress() + “:” + socket。getPort() +“”);         OutputStream outputStream = socket。getOutputStream();        Scanner scanner = new Scanner(System。in);        while (true)        {            System。out。println(“請輸入指令: ”);            String s = scanner。nextLine();            String message = s + “\n”;            outputStream。write(message。getBytes(“US-ASCII”));        }    }}

我們把服務端的埠指定為了 12345。

客戶端這邊的埠也得指定為 12345,那怎麼指定呢?

別想複雜了,簡單的一比。

把這行日誌粘貼出來:

這個Bug的排查之路,真的太有趣了

需要說明的是,我這邊為了演示效果,在程式裡面加了一個 for 迴圈。

然後我們在這裡把埠改為 12345:

這個Bug的排查之路,真的太有趣了

把檔案儲存為 start。bat 檔案,隨便放一個地方。

萬事俱備。

我們先把服務端執行起來:

這個Bug的排查之路,真的太有趣了

然後,執行 bat 檔案:

這個Bug的排查之路,真的太有趣了

在 cmd 窗口裡面輸出了我們的日誌,說明程式正常執行。

而在服務端這邊,顯示有客戶端連線成功。

叫我們輸入指令。

輸入啥指令呢?

看一下客戶端支援哪些指令唄:

這個Bug的排查之路,真的太有趣了

可以看到,支援 STOP 命令。

接受到該命令後,會退出程式。

來,搞一波,動圖走起:

這個Bug的排查之路,真的太有趣了

搞定。

好了,本文技術部分就到這裡了,恭喜你知道了 idea 中的 Monitor Ctrl-Break 執行緒,這個學了沒啥卵用的知識 。

如果要深挖的話,往

-javaagent

方向挖一挖。

應用很多的,比如耳熟能詳的 Java 診斷工具 Arthas 就是基於 JavaAgent 做的。

有點意思。