1. 程式人生 > >這個Bug的排查之路,真的太有趣了。

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

這是why哥的第 92 篇原創文章

在《深入理解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++ 不是原子性的操作,巴拉巴拉巴拉...

反正我就是這樣的:

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

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

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

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

等等......

死迴圈?

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

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

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

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

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

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

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

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

啥情況啊?

分析一波走起。

為啥停不下來?

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

我就把程式又 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

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

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

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

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

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

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

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

返回的值是一個 estimate。

estimate 是啥?

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

返回的是一個預估值。

為什麼呢?

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

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

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

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

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

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

好了,回到程式裡面。

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

看到 activeCount 方法的實現之後:

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

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

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

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

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

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

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

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

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

於是,我問他:

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

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

當前執行緒有哪些?

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

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

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 個執行緒:

也就是說,在 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/

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

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

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

繼續挖掘

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

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

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

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

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

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

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

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

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

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

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

果然,是用了 -javaagent 啊。

那麼 javaagent 是什麼?

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

只是簡單的提一下。

你在命令列執行 java 命令,會輸出一大串東西,其中就包含這個:

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

叫我們參閱 java.lang.instrument。

那它又是拿來幹啥的?

簡單的一句話解釋就是:

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

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

-javaagent:<jar 路徑>[=<選項>]

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

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

在哪看呢?

就這個地方:

你把它點開,命令非常的長。但是我們關心的 -javaagent 就在最開始的地方:

-javaagent:D:\Program Files\JetBrains\IntelliJ IDEA 2019.3.4\lib\idea_rt.jar=61960

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

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

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

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

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

主要關注 AppMainV2.class 檔案:

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

我說過什麼來著?

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

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

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

Socket client = new Socket("127.0.0.1", portNumber);

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

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

那麼這個埠是哪個埠呢?

就是這裡的 62325:

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

玩玩它

既然它是 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,那怎麼指定呢?

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

把這行日誌粘貼出來:

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

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

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

萬事俱備。

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

然後,執行 bat 檔案:

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

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

叫我們輸入指令。

輸入啥指令呢?

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

可以看到,支援 STOP 命令。

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

來,搞一波,動圖走起:

搞定。

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

如果要深挖的話,往 -javaagent 方向挖一挖。

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

有點意思。

最後說一句

才疏學淺,難免會有紕漏,如果你發現了錯誤的地方,可以在後臺提出來,我對其加以修改。

感謝您的閱讀,我堅持原創,十分歡迎並感謝您的關注。