作者：京東零售 王江波

1. 線程運行狀態

1.1 total

??

1.2 timed_waiting

??

??

通過上圖我們可以發現timed_waiting的topN線程都是查詢國補資質的。

1.3 waiting

??

??

通過上圖我們可以發現waiting的topN線程都是查詢國補活動的。

1.4 線程分析

下面我們分析上述兩種狀態：

1. WAITING 狀態

?定義：當一個線程處于 WAITING 狀態時，它在等待另一個線程的特定操作（如通知或中斷），并且不會繼續執行。

?觸發條件：線程進入 WAITING 狀態的常見情況包括：

調用 Object.wait() 方法：線程在等待某個對象的監視器（鎖）被其他線程通知。

調用 Thread.join() 方法：等待另一個線程完成。

調用 LockSupport.park() 方法：線程被阻塞，直到它被其他線程喚醒。

?恢復：線程在 WAITING 狀態下將一直保持此狀態，直到其他線程調用 notify() 或 notifyAll()（對于 Object.wait()），或者被中斷。

2. TIMED_WAITING 狀態

?定義：當一個線程處于 TIMED_WAITING 狀態時，它在等待某個條件的發生，但它會在指定的時間后自動返回。

?觸發條件：線程進入 TIMED_WAITING 狀態的常見情況包括：

調用 Thread.sleep(milliseconds)：線程休眠指定的毫秒數。

調用 Object.wait(milliseconds)：線程在等待某個對象的監視器（鎖），并且在指定的時間內等待。

調用 Thread.join(milliseconds)：等待另一個線程完成，但有時間限制。

調用 LockSupport.parkNanos() 或 LockSupport.parkUntil()。

?恢復：線程在 TIMED_WAITING 狀態下會在指定的時間結束后自動恢復，或者在其他線程調用 notify() 或 notifyAll() 時恢復。

| 狀態           | 描述                                     | 觸發條件                                    | 恢復方式                                   |
|----------------|------------------------------------------|---------------------------------------------|--------------------------------------------|
| **WAITING**    | 線程等待另一個線程的特定操作，不會繼續執行 | `Object.wait()`, `Thread.join()`, `LockSupport.park()` | 其他線程調用 `notify()`/`notifyAll()` 或被中斷 |
| **TIMED_WAITING** | 線程等待某個條件的發生，但有時間限制   | `Thread.sleep(milliseconds)`, `Object.wait(milliseconds)`, `Thread.join(milliseconds)` | 超過指定時間后自動恢復，或其他線程調用 `notify()`/`notifyAll()` |

下面我們結合實際代碼情況分析：

??

上文中 queryActTp 為 getActivityInfo 執行并發任務，其中包含兩個子任務、 queryQualityTp 為 getQualityInfo 執行并發任務，其中五個子任務。同時將這倆任務放到queryActAndQualityTp中并行。

getActivityInfo所在的秒級監控如下：

??

getQualityInfo所在的秒級監控如下;

??

上文中同樣的調用方式，但是出現了兩種線程狀態，理論上應該都是TIMED_WAITING。針對queryActTp我們可以發現堆棧信息中也是LockSupport.park而不是LockSupport.parkNanos。具體原因有待進一步分析。

上述代碼中還有一個問題就是A線程池中又并行調用了B、C線程池，在大流量情況下，CPU頻繁切換也會造成一定的CPU壓力，我們改寫這塊邏輯用一個線程池實現活動和資質的并發查詢。鑒于改動較大，本次先不動。

2. 火焰圖分析

??

2.1 wait線程

??

2.2 鎖性能

??

2.3 CPU采樣

??

2.3.1 getFatherActivity分析

??

Q1：調用場景：循環中調用getFatherActivity

Q2：查看配置數據，json格式化后50000字符，大對象的反序列化

Q3：使用new ArrayList() 創建新對象

Q4：分組后只用了對象中的第一個元素，這里用toMap更佳

優化1：

??

我們可以發現上文在循環中還是會存在多次的stream調用，繼而將toMap邏輯提到循環外，如下：

??

其他方法確實占用CPU較高，這里先不處理。

下文再優化一項獲取并發線程執行結果的工具類：

??

1、 allOf異常后，取消所有線程的繼續執行。這么做為了防止有些線程超時后仍在執行，浪費部分CPU資源，線上發現確實存在較多的超時情況。
2、 這里的異常日志較多，根據異常類型進行區分，去掉沒用的堆棧日志。

并發線程中所有的等待統一都使用了上文的方法，前文中的queryActTp處于WAITING狀態可能也是執行沒取消導致，修改部署后再觀察分析。同樣的調用方式 queryQualityTp 處于Timed_waiting狀態可能與一次父任務中子任務的執行耗時有關，見上文監控，活動和資質相差較大，具體原因有待進一步分析。

審核編輯 黃宇