Spring Cloud中Hystrix 线程隔离导致ThreadLocal数据丢失（上）

在Spring Cloud中我们用Hystrix来实现断路器，Zuul中默认是用信号量（Hystrix默认是线程）来进行隔离的，我们可以通过配置使用线程方式隔离。

这里简单介绍下Hystrix隔离策略：

一、 线程池隔离（默认策略模式） 
线程池隔离把执行依赖代码的线程与请求线程(如：tomcat 线程)分离，请求线程可以自由控制 离开的时间。 
通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务，防止依赖问题扩散。 
生产环境建议线程池（默认是 10 个线程）不要设置过大，否则大量堵塞线程有可能会拖慢服 务器。

优点： 
1、 使用线程池隔离可以完全隔离第三方应用，请求线程可以快速放回。 2、 请求线程可以继续接受新的请求，如果出现问题线程池隔离是独立的不会影响其他应用。 
3、 当失败的应用再次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。 
4、 独立的线程池提高了并发性。

注意：尽管线程池隔离是由一个单独的线程提供，客户端代码（异常方法里面的请求）应该也 有超时机制，不能让响应的线程无限期等待，应该适时去中断它，阻止 Hystrix 线程池的饱和。

缺点： 
线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队、调度和上 下文切换都是在一个单独的线程上运行的。

二、 信号量隔离 
使用一个原子计数器（或信号量）来记录当前有多少个线程在运行，当请求进来时先判断计数 器的数值，若超过设置的最大线程个数则拒绝该请求，若不超过则通行，这时候计数器+1，请求返 回成功后计数器-1。与线程池隔离最大不同在于执行依赖代码的线程依然是请求线程 
tips：信号量的大小可以动态调整, 线程池大小不可以

三、模式分析：

hystrix隔离模式目前有两种方式：信号量模式和线程池模式。

但信号量并不支持超时，当被调服务发生问题时，有少部分用户会长时间无法得到响应。

另外，使用线程池模式无法传递Header，我估计是由于线程切换，参数传递过程中被去掉了。

信号量和线程池对比：

	是否有线程切换	是否支持异步	是否支持超时	是否支持熔断	开销大小	是否支持限流
信号量	否	否	否	是	小	是
线程池	是	是	是	是	大	是

目前hystrix熔断器支持的隔离策略主要是信号量和线程池两种方式

信号量的使用示意图如下图所示，当n个并发请求去调用一个目标服务接口时，都要获取一个信号量才能真正去调用目标服务接口，但信号量有限，默认是10个，可以使用maxConcurrentRequests参数配置，如果并发请求数多于信号量个数，就有线程需要进入队列排队，但排队队列也有上限，默认是 5，如果排队队列也满，则必定有请求线程会走fallback流程，从而达到限流和防止雪崩的目的。

 

信号量模式从始至终都只有请求线程自身，是同步调用模式，不支持超时调用，不支持直接熔断，由于没有线程的切换，开销非常小。

线程池的使用示意图如下图所示，当n个请求线程并发对某个接口请求调用时，会先从hystrix管理的线程池里面获得一个线程，然后将参数传递给这个线程去执行真正调用。线程池的大小有限，默认是10个线程，可以使用maxConcurrentRequests参数配置，如果并发请求数多于线程池线程个数，就有线程需要进入队列排队，但排队队列也有上限，默认是 5，如果排队队列也满，则必定有请求线程会走fallback流程。

线程池模式可以支持异步调用，支持超时调用，支持直接熔断，存在线程切换，开销大。

 

四、 应用场景 
线程池隔离： 
1、 第三方应用或者接口 
2、 并发量大

信号量隔离： 
1、 内部应用或者中间件（redis） 
2、 并发需求不大

回到正文：

在使用线程隔离的时候，有个问题是必须要解决的，那就是在某些业务场景下通过ThreadLocal来在线程里传递数据，用信号量是没问题的，从请求进来，但后续的流程都是通一个线程。

当隔离模式为线程时，Hystrix会将请求放入Hystrix的线程池中去执行，这个时候某个请求就有A线程变成B线程了，ThreadLocal必然消失了。

下面我们通过一个简单的列子来模拟下这个流程：

public class CustomThreadLocal {
    static ThreadLocal threadLocal = new ThreadLocal<>();
    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                CustomThreadLocal.threadLocal.set("猿天地");
                new Service().call();
            }
        }).start();
    }
}
class Service {
    public void call() {
        System.out.println("Service:" + Thread.currentThread().getName());
        System.out.println("Service:" + CustomThreadLocal.threadLocal.get());
        new Dao().call();
    }
}
class Dao {
    public void call() {
        System.out.println("==========================");
        System.out.println("Dao:" + Thread.currentThread().getName());
        System.out.println("Dao:" + CustomThreadLocal.threadLocal.get());
    }
}

我们在主类中定义了一个ThreadLocal用来传递数据，然后起了一个线程，在线程中调用Service中的call方法，并且往Threadlocal中设置了一个值，在Service中获取ThreadLocal中的值，然后再调用Dao中的call方法，也是获取ThreadLocal中的值，我们运行下看效果：

Service:Thread-0

Service:猿天地

==========================

Dao:Thread-0

Dao:猿天地

可以看到整个流程都是在同一个线程中执行的，也正确的获取到了ThreadLocal中的值，这种情况是没有问题的。

接下来我们改造下程序，进行线程切换，将调用Dao中的call重启一个线程执行：

public class CustomThreadLocal {
    static ThreadLocal threadLocal = new ThreadLocal<>();
    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                CustomThreadLocal.threadLocal.set("猿天地");
                new Service().call();
            }
        }).start();
    }
}
class Service {
    public void call() {
        System.out.println("Service:" + Thread.currentThread().getName());
        System.out.println("Service:" + CustomThreadLocal.threadLocal.get());
        //new Dao().call();
        new Thread(new Runnable() {
            @Override
            public void run() {
                new Dao().call();
            }
        }).start();
    }
}
class Dao {
    public void call() {
        System.out.println("==========================");
        System.out.println("Dao:" + Thread.currentThread().getName());
        System.out.println("Dao:" + CustomThreadLocal.threadLocal.get());
    }
}

再次运行，看效果：

Service:Thread-0

Service:猿天地

==========================

Dao:Thread-1

Dao:null

可以看到这次的请求是由2个线程共同完成的，在Service中还是可以拿到ThreadLocal的值，到了Dao中就拿不到了，因为线程已经切换了，这就是开始讲的ThreadLocal的数据会丢失的问题。

那么怎么解决这个问题呢，其实也很简单，只需要改一行代码即可:

static ThreadLocal threadLocal = new InheritableThreadLocal<>();

将ThreadLocal改成InheritableThreadLocal，我们看下改造之后的效果：

Service:Thread-0

Service:猿天地

==========================

Dao:Thread-1

Dao:猿天地

值可以正常拿到，InheritableThreadLocal(可继承局部线程)就是为了解决这种线程切换导致ThreadLocal拿不到值的问题而产生的。

要理解InheritableThreadLocal的原理，得先理解ThreadLocal的原理，我们稍微简单的来介绍下ThreadLocal的原理：

• 每个线程都有一个 ThreadLocalMap 类型的 threadLocals 属性，ThreadLocalMap 类相当于一个Map，key 是 ThreadLocal 本身，value 就是我们设置的值。

public class Thread implements Runnable {
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

• 当我们通过 threadLocal.set("猿天地"); 的时候，就是在这个线程中的 threadLocals 属性中放入一个键值对，key 是 当前线程，value 就是你设置的值猿天地。

 

 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.get() 方法的时候，就是根据当前线程作为key来获取这个线程设置的值。

 

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
             @SuppressWarnings("unchecked")
             T result = (T)e.value;
             return result;
        }
    }
    return setInitialValue();
}

通过上面的介绍我们可以了解到threadlocal能够传递数据是用Thread.currentThread()当前线程来获取，也就是只要在相同的线程中就可以获取到前方设置进去的值。

如果在threadlocal设置完值之后，下步的操作重新创建了一个线程，这个时候Thread.currentThread()就已经变了，那么肯定是拿不到之前设置的值。具体的问题复现可以参考上面我的代码。

那为什么InheritableThreadLocal就可以呢？

InheritableThreadLocal这个类继承了ThreadLocal，重写了3个方法，在当前线程上创建一个新的线程实例Thread时，会把这些线程变量从当前线程传递给新的线程实例。

public class InheritableThreadLocal extends ThreadLocal {
    /**
     * Computes the child's initial value for this inheritable thread-local
     * variable as a function of the parent's value at the time the child
     * thread is created.  This method is called from within the parent
     * thread before the child is started.
     * 

     * This method merely returns its input argument, and should be overridden
     * if a different behavior is desired.
     *
     * @param parentValue the parent thread's value
     * @return the child thread's initial value
     */
    protected T childValue(T parentValue) {
        return parentValue;
    }
    /**
     * Get the map associated with a ThreadLocal.
     *
     * @param t the current thread
     */
    ThreadLocalMap getMap(Thread t) {
       return t.inheritableThreadLocals;
    }
    /**
     * Create the map associated with a ThreadLocal.
     *
     * @param t the current thread
     * @param firstValue value for the initial entry of the table.
     */
    void createMap(Thread t, T firstValue) {
        t.inheritableThreadLocals = new ThreadLocalMap(this, firstValue);
    }
}

通过上面的代码我们可以看到InheritableThreadLocal 重写了childValue, getMap,createMap三个方法，当我们往里面set值的时候，值保存到了inheritableThreadLocals里面，而不是之前的threadLocals。

关键的点来了，为什么当创建新的线程池，可以获取到上个线程里的threadLocal中的值呢？原因就是在新创建线程的时候，会把之前线程的inheritableThreadLocals赋值给新线程的inheritableThreadLocals，通过这种方式实现了数据的传递。

源码最开始在Thread的init方法中，如下：

 if (parent.inheritableThreadLocals != null)
     this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);

createInheritedMap如下：

static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
        return new ThreadLocalMap(parentMap);
    }

赋值代码：

 private ThreadLocalMap(ThreadLocalMap parentMap) {
      Entry[] parentTable = parentMap.table;
      int len = parentTable.length;
      setThreshold(len);
      table = new Entry[len];
      for (int j = 0; j < len; j++) {
            Entry e = parentTable[j];
            if (e != null) {
                @SuppressWarnings("unchecked")
                ThreadLocal