聊聊高并发（二）结合实例说说线程封闭和背后的设计思想
高并發問題拋去架構層面的問題，落實到代碼層面就是多線程的問題。多線程的問題主要是線程安全的問題（其他還有活躍性問題，性能問題等）。
那什么是線程安全？下面這個定義來自《Java并發編程實戰》，這本書強烈推薦，是幾個Java語言的作者合寫的，都是并發編程方面的大神。
線程安全指的是：當多個線程訪問某個類時，這個類始終都能表現出正確的行為。
正確指的是“所見即所知”，程序執行的結果和你所預想的結果一致。
?
理解線程安全的概念很重要，所謂線程安全問題，就是處理對象狀態的問題。如果要處理的對象是無狀態的（不變性），或者可以避免多個線程共享的（線程封閉），那么我們可以放心，這個對象可能是線程安全的。當無法避免，必須要共享這個對象狀態給多線程訪問時，這時候才用到線程同步的一系列技術。
?
這個理解放大到架構層面，我們來設計業務層代碼時，業務層最好做到無狀態，這樣就業務層就具備了可伸縮性，可以通過橫向擴展平滑應對高并發。
?
所以我們處理線程安全可以有幾個層次：
1. 能否做成無狀態的不變對象。無狀態是最安全的。
2. 能否線程封閉
3. 采用何種同步技術
?
我理解為能夠“逃避”多線程問題，能逃則逃，實在不行了再來處理。
?
了解了線程封閉的背景，來說說線程封閉的具體技術和思路
1. 棧封閉
2. ThreadLocal
3. 程序控制線程封閉
?
棧封閉說白了就是多使用局部變量。理解Java運行時模型的同學都知道局部變量的引用是保持在線程棧中的，只對當前線程可見，其他線程不可見。所以局部變量是線程安全的。
?
ThreadLocal機制本質上是程序控制線程封閉，只不過是Java本身幫忙處理了。來看Java的Thread類和ThreadLocal類
1. Thread線程類維護了一個ThreadLocalMap的實例變量
2. ThreadLocalMap就是一個Map結構
3. ThreadLocal的set方法取到當前線程，拿到當前線程的threadLocalMap對象，然后把ThreadLocal對象作為key，把要放入的值作為value，放到Map
4. ThreadLocal的get方法取到當前線程，拿到當前線程的threadLocalMap對象，然后把ThreadLocal對象作為key，拿到對應的value.
?
?public class Thread implements Runnable {
ThreadLocal.ThreadLocalMap threadLocals = null;
}
public class ThreadLocal<T> {
public T get() {
??????? Thread t = Thread.currentThread();
??????? ThreadLocalMap map = getMap(t);
??????? if (map != null) {
??????????? ThreadLocalMap.Entry e = map.getEntry(this);
??????????? if (e != null)
??????????????? return (T)e.value;
??????? }
??????? return setInitialValue();
??? }
ThreadLocalMap getMap(Thread t) {
??????? return t.threadLocals;
??? }
public void set(T value) {
??????? Thread t = Thread.currentThread();
??????? ThreadLocalMap map = getMap(t);
??????? if (map != null)
??????????? map.set(this, value);
??????? else
??????????? createMap(t, value);
??? }
}
ThreadLocal的設計很簡單，就是給線程對象設置了一個內部的Map，可以放置一些數據。JVM從底層保證了Thread對象之間不會看到對方的數據。
使用ThreadLocal前提是給每個ThreadLocal保存一個單獨的對象，這個對象不能是在多個ThreadLocal共享的，否則這個對象也是線程不安全的。
Structs2就用了ThreadLocal來保存每個請求的數據，用了線程封閉的思想。但是ThreadLocal的缺點也顯而易見，必須保存多個副本，采用空間換取效率。
?
程序控制線程封閉，這個不是一種具體的技術，而是一種設計思路，從設計上把處理一個對象狀態的代碼都放到一個線程中去，從而避免線程安全的問題。
有很多這樣的實例，Netty5的EventLoop就采用這樣的設計，我們的游戲后臺處理用戶請求是也采用了這種設計。
具體的思路是這樣的：
1. 把和用戶狀態相關的代碼放到一個隊列中去，由一個線程處理
2. 考慮是否隔離用戶之間的狀態，即一個用戶使用一個隊列，還是多個用戶使用一個隊列
?
拿Netty舉例，EventLoop被設計成了一個線程的線程池。我們知道線程池的組成是工作線程 + 任務隊列。EventLoop的工作線程只有一個。
用戶請求過來后被隨機放到一個EventLoop去，也就是放到EventLoop線程池的任務隊列，由一個線程來處理。并且處理用戶請求的代碼都使用Pipeline職責鏈封裝好了，一個Pipeline交給一個線程來處理，從而保證了跟同一個用戶的狀態被封閉到了一個線程中去。
更多Netty EventLoop相關的內容看這篇?Netty5源碼分析（二） -- 線程模型分析?
?
這里有個問題也顯而易見，就是如果把多個用戶都放到一個隊列，交給一個線程處理，那么前一個用戶的處理速度會影響到后一個用戶被處理的時間。
?
我們的游戲服務器的設計采用了一個用戶一個任務隊列的方式，處理任務的代碼被做成了Runnable，這樣多個Runnable可以交給一個線程池執行，從而多個用戶可以同時被處理，而同一個用戶的狀態處理被封閉到了唯一的一個任務隊列中，互不干擾。
?
但是也有問題，即線程池內的工作線程和任務隊列是有界的，所以單個線程處理的時間必須要快，否則大量請求被積壓在任務隊列來不及處理，一旦任務隊列也滿了，那么后續的請求都進不來了。
如果使用無界的任務隊列，所有請求能進來，但是問題是高并發情況下大量請求過來，會把系統內存撐爆，倒置OOM。
所以一個常用的設計思路如下：
1. 采用有界的任務隊列和不限個數的工作線程，這樣可以平滑地處理高并發，不至于內存被撐爆
2. 單個線程請求時間必須要快，盡量不超過100ms
3. 如果單個線程處理的時間由于任務太大必須耗時，那么把任務拆個小任務來多次執行
4. 拆成小任務還是慢，那么把同步操作變成異步操作，即方法執行后立即返回，不要等待結果。由另一個線程異步地處理線程，比如采用單獨的線程定時檢查處理狀態，或者采用異步回調的方式
總結
以上是生活随笔為你收集整理的聊聊高并发（二）结合实例说说线程封闭和背后的设计思想的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 聊聊JVM（九）理解进入safepoin
- 下一篇： 聊聊高并发（五）理解缓存一致性协议以及对