這是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 執行緒：

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

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

//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 做的。

有點意思。

最後說一句

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

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