[[343153]]

 介紹

周末在水群的時候，發現有個小伙伴遇到了一個線上問題

線程池中線程的狀態只有一個為RUNNABLE，其他都為WAITING，問有可能是哪些原因造成的?

線程池有25個線程，只有一個線程卡在網絡讀取上面，狀態為RUNNABLE，其他線程都為WAITING。

可能有小伙伴們沒用過這個工具，簡單介紹一下這個性能監測工具JMC，JMC是源自JRockit JVM的一套監控和管理工具，Oracle在發布JAVA 7u4(Java 7 Update 40)時將其包含在JDK中，用戶不再需要單獨下載

只需要在命令中執行jmc即可

應用啟動配置如下參數

-Dcom.sun.management.jmxremote.port=7091  
-Dcom.sun.management.jmxremote.authenticate=false  
-Dcom.sun.management.jmxremote.ssl=false 

連接到配置的JMC就能看到各種監測指標。

本來我想讓這個小伙伴把代碼發過來看看的，可他卻說自己做的是銀行的項目，連不上外網，只能用手機開視頻對著電腦讓我看個大概。我復原一下這個代碼的場景，估計很多小伙伴一下就能發現問題了，因為我把多余的代碼都省略了，只留了會造成問題的代碼

public class BankDemo { 
 
    public ExecutorService service = Executors.newFixedThreadPool(5); 
 
    public static class Task implements Runnable { 
 
        private CountDownLatch latch; 
 
        public void setLatch(CountDownLatch latch) { 
            this.latch = latch; 
        } 
 
        @SneakyThrows 
        @Override 
        public void run() { 
            // 建立一個Socket連接發送數據 
            Socket socket = new Socket("127.0.0.1",10006); 
            // ... 
            // 執行最后調用如下方法 
            latch.countDown(); 
        } 
    } 
 
    // 真實的代碼這里的過程為，每次往線程池里面放一批任務，這一批任務執行完畢，再放下一批任務 
    // 即循環調用如下方法 
    @SneakyThrows 
    public void runTask(List<Task> taskList) { 
        CountDownLatch latch = new CountDownLatch(5); 
        taskList.forEach(item -> { 
            item.setLatch(latch); 
            service.submit(item); 
        }); 
        latch.await(); 
    } 
} 

提示一下WAITING狀態的線程阻塞在LockSupport.park()方法上(用了上圖的JMC工具)

寫個小插曲，這個小伙伴一直和我強調這個代碼已經在線上跑了一年了，一直沒發生問題。怎么到自己這就發生問題了，所以他的解決方案是一直看自己修改了哪些部分，但是始終沒看出來問題。

而我的思路就和他不一樣了，因為有些bug只有在特定場景下才會出現，不要堅信之前的代碼就沒有問題，要從問題本身著手

Java線程狀態

在發現問題的時候基礎知識還是很重要的，回顧一下

簡易的線程狀態如下圖

Java Thread線程內部有一個枚舉內部類State，定義了Java語言線程狀態的枚舉值

1. NEW(初始化狀態)
2. RUNNABLE (可運行/運行狀態)
3. BLOCKED(阻塞狀態)
4. WAITING (無時限等待)
5. TIMED_WAITING(有時限等待)
6. TERMINATED(終止狀態)

Java將操作系統層面的阻塞狀態細分為BLOCK，WAITING，TIMED_WAITING三種狀態

NEW：新建狀態，線程被創建但未啟動的狀態。創建線程有三種方式

1. 繼承Thread類
2. 實現Runnable接口
3. 實現Callable接口

我們最常用的是通過實現接口這種方式，Runnable和Callable接口的區別如下

1. Runnable無法獲取返回值，而Callable可以獲取返回值
2. Runnable無法拋出異常，而Callable可以拋出異常

RUNNABLE(就緒狀態)：調用start之后運行之前的狀態RUNNING(運行狀態)：線程正在運行BLOCKED(阻塞狀態)：進入以下狀態，有以下幾種情況

1. BLOCK(同步阻塞)：鎖被其他線程占用，如等待進入synchronized方法或者代碼塊
2. WAITING(主動阻塞)：執行Object.wait()，Thread.join()等
3. TIMED_WAITING(等待阻塞)：執行Object.wait(long)，Thread.sleep(long)等

DEAD(終止狀態)：線程執行完畢 最后將各種方法補充到線程狀態圖上

場景還原

造成線程WAITING，一般是調用了如下3種方法之一

1. Object.wait()
2. Thread.join()
3. LockSupport.park()

排查問題的過程如下

1. 在明確了代碼中沒有調用Object.wait()和Thread.join()后，那基本就確定了是調用了java.util.concurrent包下面的工具類導致的線程阻塞，因為java.util.concurrent包下的工具類頻繁使用了LockSupport.park()
2. 接著就可以確定是使用CountDownLatch造成的問題了，其他的線程已經結束了，只有一個線程在運行，此時其他線程就阻塞等待
3. 那這個RUNNABLE的線程做啥了，為啥一直沒有結束?此時文章最開始的一張圖指明了方向，這個線程阻塞在網絡讀取上了。
4. 既然卡在網絡讀取上，肯定就是沒有設置連接的超時時間，或者讀取的超時時間。一問，果然和我想的一樣，沒有設置

設置完后，他在本地跑了一下，剛開始還正常運行，后來就直接拋出異常了

SocketTimeoutException: connect timed out(連接服務端超時) SocketException: Connection reset(服務端關閉了連接，但是客戶端還在從連接中讀取數據)

那為什么剛開始程序能正常跑?后面就開始報這種連接異常了呢?

1. 服務端確實并發太大了
2. 服務端的網路請求用BIO實現的，一個請求創建一個線程，本身就支持不了高并發

至于是哪種原因?我讓小伙伴找服務端的開發人員確認了 一下，服務端居然是使用BIO實現的。網絡請求居然不用Netty，還是你們任性!

期待我后續的Netty文章哈，這種事情堅決不能再發生。

本文轉載自微信公眾號「 Java識堂」，可以通過以下二維碼關注。轉載本文請聯系 Java識堂公眾號。