這是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 做的。
有點意思。
最后說一句
才疏學淺，難免會有紕漏，如果你發現了錯誤的地方，可以在后台提出來，我對其加以修改。
感謝您的閱讀，我堅持原創，十分歡迎並感謝您的關注。
