程序猿你還不會使用多線程優化系統嗎? 比葫蘆畫瓢,多線程實戰。

本文是關於多線程適用的業務場景的討論。為了讓文章更容易理解,請務必先閱讀前文。文章結尾會提出代碼示例,歡迎童鞋們參與討論。共同學習進步。

在讀完本文後如果自己系統設計到很多的接口調用即可以進行多線程優化，使之性能加速，提供系統響應速度。本文使用的多線程工具類，會以maven包方式提供下載。謝謝您的閱讀。

一、為何要使用多線程，使用異步並行來替換同步阻塞編程

眾所周知，提高應用系統的響應速度可以有兩點，一點是代碼儘可能精簡優化,第二點是儘可能優化同步調用接口導致的耗時浪費。而本文就是對第二點進行優化,即利用多線程的編程模型,從而達到用異步並行來替換同步阻塞編程。

下文小編以一個業務場景入手，看如何優化系統。

業務背景:

某支付公司的支付決策功能, 什麼是支付決策,就是從用戶商品產品風控等各個維度來提用戶決策出用戶自己當前能使用的支付工具。該模塊因為涉及到支付安全，所以內部集成了多達十多個遠程服務的調用。十多個接口就算每個耗時100毫秒，只要任何一個接口抖動一下，就可能造成接口響應緩慢，從而影響用戶體驗。這麼說可能沒有體感,舉一個例子，假如你正在使用支付寶購買一瓶飲料，當打開支付寶準備支付的時候，頁面突然卡頓了1s,才彈出來，這個時候內心是不是崩潰的。

下面這種圖是不是就很有體感了，為用戶決策出這個圖上的支付工具。看似簡單其實極其複雜，涉及十多個系統交互。

一張圖就可以解釋清楚了,哈哈

二、閱讀前先要了解的業務知識

1. 下文將要涉及的支付碼

2. 下文將要涉及的系統模塊

三、兩種編程模型圖展示

1. 同步阻塞串行調用

耗時: 每個接口調用耗時之和

2. 多線程並行調用

耗時: 最大耗時接口時長

四、業務場景模擬

1. 業務說明

• 根據商戶號查詢商戶支持的支付工具 【餘額支付、白條支付、銀行卡支付】
• 根據產品碼查詢當前支付產品可用支付工具 【餘額支付、銀行卡支付】
• 獲取商戶和當前產品支付工具的交集 【餘額支付、銀行卡支付】
• 如果存在餘額則查詢賬務系統 【查詢】
• 如果存在銀行卡則查詢風控系統 【查詢】
• 返回結果 【餘額支付】

經過一些列操作，返回用戶可用的支付工具只有餘額支付。(真實情況更復雜,在這裡只是簡單舉例)

2. 業務流程圖

3. 說明

當前業務依賴的業務系統很多,大概有13個業務系統的查詢，這種場景下如何根據上面的流程圖一樣串行調用，可能處理的時間會很長，如上圖耗時: 1 + 2 + 3 + 4 + 5 = 15s。 想象一下如果用戶打開支付工具點擊支付，app經過了15s之後才給你一個反饋，是不是內心是崩潰的。接著看下文，提供優化方案

五、多線程使用示例

1. 改造後的流程圖

通過多線程並行,如上圖耗時我們可以將原來串行的(1 + 2 + 3 + 4 + 5 = 15s), 優化為(2 + 3 + 5 = 10s)

耗時是小編為了方便根據序號定義的，真實系統提升會更大。

2. 改造前代碼 VS 改造後代碼

將通用的邏輯封裝成線程任務,多線程執行。

改造前: 同步阻塞編程模型

改造後: 異步並行非阻塞編程

3. 耗時對比

耗時可以看出，幾乎時間縮短了1倍，真實的情況可能會更好。

4. 模擬接口

商戶查詢

商戶查詢接口模擬

產品模擬查詢

產品查詢接口模擬

賬務查詢線程

賬務查詢接口模擬

風控查詢

風控查詢接口模擬

六、線程池工具分享

儘管多線程編程非常好用，但是對於那些對多線程不瞭解的同學來說，不瞭解導致了不敢用。再次分享一篇多線程執行原理的文章，是小編之前寫的。看完你就知道原理了。

Java核心線程池原理

多線程執行原理圖

知道原理了，就敢用了，所謂知己知彼嘛。但是原生的多線程API,其實並不是很好用。在此小編將自己的工具分享給大家，大家可以研究使用。

1. 對原生線程池進行包裝增強

API簡單

2. 對無結果任務添加監聽器

監聽器模式

3. 對有返回值任務添加監聽器

監聽器的模式

4. 自定義線程池日誌健康

可以自定義日誌打印

maven倉庫地址(2020年4月27提供下載，因為文章寫在前面所以要等兩天才能下載到)

<code>        
<
dependency
>

            
<
groupId 
>
com.hanframework
groupId
>

            
<
artifactId
>
commong.kit
artifactId
>

            
<
version
>
1.0.0-RELEASE
version
>

        
dependency
>
/<code>

七、多線程一定快嗎

多線程一定快嗎? 從理論上來看，我們可以理解計算機CPU是一個人，一個人同一時刻只能做一件事，但是現在的計算機基本都是多核多線程的，所以多線程可以理解成多個人幹活，那麼多個人幹活肯定比一個人幹活快。

但是實際場景是這樣嗎? 當然不是。具體問題還要具體分析

• 對於計算密集型來說: 要進行大量的計算，消耗CPU資源。比如計算圓周率、對視頻進行高清解碼就算你是2核心，多個線程來工作，其實也不會提高效率。
• 對於IO密集型來說: CPU消耗很少，任務的大部分時間都在等待IO操作完成,1個線程在等待，那麼另外一個線程就會佔用CPU。所以能很大程度提高效率

那麼我們分析我們的業務系統,是什麼密集型? 發現我們的邏輯基本就是接口調用,大部分時間花費在等待接口響應的時間。那麼可以理解就是IO密集型(網絡通信也是IO哦)，這種場景使用多線程是非常適合的。

八、什麼場景下適用於多線程。

1. IO密集型操作(大多數業務系統只要不是計算類型的業務，剩下其他的都是IO密集型,自己可以評估)
2. IO操作是否具有依賴關係,eg: 調用B系統依賴A接口的處理結果,調用C系統依賴AB的接口處理結果。那麼這種場景多線程其實沒有什麼用，相反會增加線程上下文切換的耗時。
3. 業務系統很簡單,只有1或者2個接口調用,耗時並不高，這種情況也沒必須使用多線程，因為使用了多線程就要對多線程進行維護和監控。維護成本大與接口成本

總結:

IO密集型 && 前後IO交互無依賴 && 耗時接口調用大於2個。當滿足這三個條件就開始考慮使用多線程優化系統吧