高并發(fā)問題拋去架構(gòu)層面的問題，落實(shí)到代碼層面就是多線程的問題。多線程的問題主要是線程安全的問題（其他還有活躍性問題，性能問題等）。

那什么是線程安全？下面這個定義來自《Java并發(fā)編程實(shí)戰(zhàn)》，這本書強(qiáng)烈推薦，是幾個Java語言的作者合寫的，都是并發(fā)編程方面的大神。

線程安全指的是：當(dāng)多個線程訪問某個類時，這個類始終都能表現(xiàn)出正確的行為。

正確指的是“所見即所知”，程序執(zhí)行的結(jié)果和你所預(yù)想的結(jié)果一致。

理解線程安全的概念很重要，所謂線程安全問題，就是處理對象狀態(tài)的問題。如果要處理的對象是無狀態(tài)的（不變性），或者可以避免多個線程共享的（線程封閉），那么我們可以放心，這個對象可能是線程安全的。當(dāng)無法避免，必須要共享這個對象狀態(tài)給多線程訪問時，這時候才用到線程同步的一系列技術(shù)。

這個理解放大到架構(gòu)層面，我們來設(shè)計業(yè)務(wù)層代碼時，業(yè)務(wù)層最好做到無狀態(tài)，這樣就業(yè)務(wù)層就具備了可伸縮性，可以通過橫向擴(kuò)展平滑應(yīng)對高并發(fā)。

所以我們處理線程安全可以有幾個層次：

1. 能否做成無狀態(tài)的不變對象。無狀態(tài)是最安全的。

2. 能否線程封閉

3. 采用何種同步技術(shù)

我理解為能夠“逃避”多線程問題，能逃則逃，實(shí)在不行了再來處理。

了解了線程封閉的背景，來說說線程封閉的具體技術(shù)和思路

1. 棧封閉

2. ThreadLocal

3. 程序控制線程封閉

棧封閉說白了就是多使用局部變量。理解Java運(yùn)行時模型的同學(xué)都知道局部變量的引用是保持在線程棧中的，只對當(dāng)前線程可見，其他線程不可見。所以局部變量是線程安全的。

ThreadLocal機(jī)制本質(zhì)上是程序控制線程封閉，只不過是Java本身幫忙處理了。來看Java的Thread類和ThreadLocal類

1. Thread線程類維護(hù)了一個ThreadLocalMap的實(shí)例變量

2. ThreadLocalMap就是一個Map結(jié)構(gòu)

3. ThreadLocal的set方法取到當(dāng)前線程，拿到當(dāng)前線程的threadLocalMap對象，然后把ThreadLocal對象作為key，把要放入的值作為value，放到Map

4. ThreadLocal的get方法取到當(dāng)前線程，拿到當(dāng)前線程的threadLocalMap對象，然后把ThreadLocal對象作為key，拿到對應(yīng)的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的設(shè)計很簡單，就是給線程對象設(shè)置了一個內(nèi)部的Map，可以放置一些數(shù)據(jù)。JVM從底層保證了Thread對象之間不會看到對方的數(shù)據(jù)。

使用ThreadLocal前提是給每個ThreadLocal保存一個單獨(dú)的對象，這個對象不能是在多個ThreadLocal共享的，否則這個對象也是線程不安全的。

Structs2就用了ThreadLocal來保存每個請求的數(shù)據(jù)，用了線程封閉的思想。但是ThreadLocal的缺點(diǎn)也顯而易見，必須保存多個副本，采用空間換取效率。

程序控制線程封閉，這個不是一種具體的技術(shù)，而是一種設(shè)計思路，從設(shè)計上把處理一個對象狀態(tài)的代碼都放到一個線程中去，從而避免線程安全的問題。

有很多這樣的實(shí)例，Netty5的EventLoop就采用這樣的設(shè)計，我們的游戲后臺處理用戶請求是也采用了這種設(shè)計。

具體的思路是這樣的：

1. 把和用戶狀態(tài)相關(guān)的代碼放到一個隊(duì)列中去，由一個線程處理

2. 考慮是否隔離用戶之間的狀態(tài)，即一個用戶使用一個隊(duì)列，還是多個用戶使用一個隊(duì)列

拿Netty舉例，EventLoop被設(shè)計成了一個線程的線程池。我們知道線程池的組成是工作線程 + 任務(wù)隊(duì)列。EventLoop的工作線程只有一個。

用戶請求過來后被隨機(jī)放到一個EventLoop去，也就是放到EventLoop線程池的任務(wù)隊(duì)列，由一個線程來處理。并且處理用戶請求的代碼都使用Pipeline職責(zé)鏈封裝好了，一個Pipeline交給一個線程來處理，從而保證了跟同一個用戶的狀態(tài)被封閉到了一個線程中去。

更多Netty EventLoop相關(guān)的內(nèi)容看這篇 Netty5源碼分析（二） -- 線程模型分析

這里有個問題也顯而易見，就是如果把多個用戶都放到一個隊(duì)列，交給一個線程處理，那么前一個用戶的處理速度會影響到后一個用戶被處理的時間。

我們的游戲服務(wù)器的設(shè)計采用了一個用戶一個任務(wù)隊(duì)列的方式，處理任務(wù)的代碼被做成了Runnable，這樣多個Runnable可以交給一個線程池執(zhí)行，從而多個用戶可以同時被處理，而同一個用戶的狀態(tài)處理被封閉到了唯一的一個任務(wù)隊(duì)列中，互不干擾。

但是也有問題，即線程池內(nèi)的工作線程和任務(wù)隊(duì)列是有界的，所以單個線程處理的時間必須要快，否則大量請求被積壓在任務(wù)隊(duì)列來不及處理，一旦任務(wù)隊(duì)列也滿了，那么后續(xù)的請求都進(jìn)不來了。

如果使用無界的任務(wù)隊(duì)列，所有請求能進(jìn)來，但是問題是高并發(fā)情況下大量請求過來，會把系統(tǒng)內(nèi)存撐爆，倒置OOM。

所以一個常用的設(shè)計思路如下：

1. 采用有界的任務(wù)隊(duì)列和不限個數(shù)的工作線程，這樣可以平滑地處理高并發(fā)，不至于內(nèi)存被撐爆

2. 單個線程請求時間必須要快，盡量不超過100ms

3. 如果單個線程處理的時間由于任務(wù)太大必須耗時，那么把任務(wù)拆個小任務(wù)來多次執(zhí)行

4. 拆成小任務(wù)還是慢，那么把同步操作變成異步操作，即方法執(zhí)行后立即返回，不要等待結(jié)果。由另一個線程異步地處理線程，比如采用單獨(dú)的線程定時檢查處理狀態(tài)，或者采用異步回調(diào)的方式