聊聊高并发（二）结合实例说说线程封闭和背后的设计思想

高并发问题抛去架构层面的问题，落实到代码层面就是多线程的问题。多线程的问题主要是线程安全的问题（其他还有活跃性问题，性能问题等）。

那什么是线程安全？下面这个定义来自《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 {
    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. 拆成小任务还是慢，那么把同步操作变成异步操作，即方法执行后立即返回，不要等待结果。由另一个线程异步地处理线程，比如采用单独的线程定时检查处理状态，或者采用异步回调的方式