作者：京東零售 王江波

1. 線程運行狀態(tài)

1.1 total

??

1.2 timed_waiting

??

??

通過上圖我們可以發(fā)現(xiàn)timed_waiting的topN線程都是查詢國補資質的。

1.3 waiting

??

??

通過上圖我們可以發(fā)現(xiàn)waiting的topN線程都是查詢國補活動的。

1.4 線程分析

下面我們分析上述兩種狀態(tài)：

1. WAITING 狀態(tài)

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

?觸發(fā)條件：線程進入 WAITING 狀態(tài)的常見情況包括：

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

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

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

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

2. TIMED_WAITING 狀態(tài)

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

?觸發(fā)條件：線程進入 TIMED_WAITING 狀態(tài)的常見情況包括：

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

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

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

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

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

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

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

??

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

getActivityInfo所在的秒級監(jiān)控如下：

??

getQualityInfo所在的秒級監(jiān)控如下;

??

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

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

2. 火焰圖分析

??

2.1 wait線程

??

2.2 鎖性能

??

2.3 CPU采樣

??

2.3.1 getFatherActivity分析

??

Q1：調用場景：循環(huán)中調用getFatherActivity

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

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

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

優(yōu)化1：

??

我們可以發(fā)現(xiàn)上文在循環(huán)中還是會存在多次的stream調用，繼而將toMap邏輯提到循環(huán)外，如下：

??

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

下文再優(yōu)化一項獲取并發(fā)線程執(zhí)行結果的工具類：

??

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

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

審核編輯 黃宇