[[343153]]

 介紹

周末在水群的時候，發(fā)現(xiàn)有個小伙伴遇到了一個線上問題

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

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

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

只需要在命令中執(zhí)行jmc即可

應用啟動配置如下參數(shù)

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

連接到配置的JMC就能看到各種監(jiān)測指標。

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

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連接發(fā)送數(shù)據(jù) 
            Socket socket = new Socket("127.0.0.1",10006); 
            // ... 
            // 執(zhí)行最后調用如下方法 
            latch.countDown(); 
        } 
    } 
 
    // 真實的代碼這里的過程為，每次往線程池里面放一批任務，這一批任務執(zhí)行完畢，再放下一批任務 
    // 即循環(huán)調用如下方法 
    @SneakyThrows 
    public void runTask(List<Task> taskList) { 
        CountDownLatch latch = new CountDownLatch(5); 
        taskList.forEach(item -> { 
            item.setLatch(latch); 
            service.submit(item); 
        }); 
        latch.await(); 
    } 
} 

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

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

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

Java線程狀態(tài)

在發(fā)現(xiàn)問題的時候基礎知識還是很重要的，回顧一下

簡易的線程狀態(tài)如下圖

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

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

Java將操作系統(tǒng)層面的阻塞狀態(tài)細分為BLOCK，WAITING，TIMED_WAITING三種狀態(tài)

NEW：新建狀態(tài)，線程被創(chuàng)建但未啟動的狀態(tài)。創(chuàng)建線程有三種方式

1. 繼承Thread類
2. 實現(xiàn)Runnable接口
3. 實現(xiàn)Callable接口

我們最常用的是通過實現(xiàn)接口這種方式，Runnable和Callable接口的區(qū)別如下

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

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

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

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

場景還原

造成線程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(服務端關閉了連接，但是客戶端還在從連接中讀取數(shù)據(jù))

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

1. 服務端確實并發(fā)太大了
2. 服務端的網路請求用BIO實現(xiàn)的，一個請求創(chuàng)建一個線程，本身就支持不了高并發(fā)

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

期待我后續(xù)的Netty文章哈，這種事情堅決不能再發(fā)生。

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