那些年你踩过的InheritableThreadLocal的坑

那些年你踩过的InheritableThreadLocal的坑

---

场景

在Java并发编程中，通常都需要考虑线程安全问题。所谓线程安全问题，其实就是多个线程操作同一份数据时彼此间互不感知，也会出现类似不可重复读、更新丢失等问题。解决线程安全的问题有很多，其中有使用ThreadLocal对象，可以保证多个线程间操作ThreadLocal对象的数据时（线程上下文）互不影响，每个线程可以操作一份自己的数据。

Jdk提供的ThreadLocal有2个，ThreadLocal和InheritableThreadLocal。并发编程除了多线程并发执行外，还涉及线程切换，对于ThreadLocal，因为线程切换前后线程不一样，此时ThreadLocal对象的数据时并不会传递到子线程。而InheritableThreadLocal则支持在线程切换时传递父线程的上下文到子线程中。

简单解释下线程切换，一个任务从当前线程移交给另一个线程执行，那么这个任务对象及相关的数据要从当前线程切换到另一个线程上。

冲突

InheritableThreadLocal可以用来解决线程切换时线程上下文无法传递的问题，比如在链路追踪场景下，我们希望通过一个traceId追踪一次请求的所有处理过程，即使这个处理过程中用到了一些异步的处理。

但是InheritableThreadLocal在使用线程池的情况下通常会使用不当导致踩坑，线程上下文中的数据并不是期望的数据！比如我们写一个简单的模拟链路追踪的代码。

public class TraceDemoTest {

    public static void main(String[] args) {
        // 异步处理线程池
        ExecutorService executorService = Executors.newSingleThreadExecutor();

        int requestNum = 3;
        int currentRequest = 0;
        while (currentRequest++ < requestNum) {
            // 请求前初始化traceContext
            Trace.init();
            System.out.println(String.format("处理开始,请求号=%s, traceId=%d", currentRequest, Trace.id()));

            // 异步处理，传递traceContext
            int finalCurrentRequest = currentRequest;
            executorService.submit(() -> {
                System.out.println(String.format("异步场景下，请求号=%s, traceId=%d", finalCurrentRequest, Trace.id()));
            });

            // 请求处理结束清理traceContext
            System.out.println(String.format("处理结束,请求号=%s, traceId=%d", currentRequest, Trace.id()));
            Trace.destroy();
        }
    }

    static class Trace {
        // trace上下文，存储traceId
        private static InheritableThreadLocal<Long> traceContext = new InheritableThreadLocal();
        private static final Random random = new Random();

        public static void init() {
            // 随机产生traceId
            traceContext.set(Math.abs(random.nextLong()));
        }

        public static Long id() {
            return traceContext.get();
        }

        public static void destroy() {
            traceContext.remove();
        }

    }
}

// 输出如下：
处理开始,请求号=1, traceId=4755367750427905493
处理结束,请求号=1, traceId=4755367750427905493
处理开始,请求号=2, traceId=6674995531725301187
异步场景下，请求号=1, traceId=4755367750427905493
处理结束,请求号=2, traceId=6674995531725301187
异步场景下，请求号=2, traceId=4755367750427905493
处理开始,请求号=3, traceId=3553719310243804399
处理结束,请求号=3, traceId=3553719310243804399
异步场景下，请求号=3, traceId=4755367750427905493

这个例子小巧典型，我们注意输出，可以依次得到以下结论：

1. 异步线程池使用Trace.id()拿到了主线程Trace.init()产生的上下文，InheritableThreadLocal可以实现上下文传递。
2. 请求号=1时，异步场景下traceContext被正确传递，traceId正确。
3. 请求号=2,3时，异步场景下的traceId与主线程中不一致，更甚之，和请求号=1时的traceId一致。

其实这就是InheritableThreadLocal在使用线程池时会踩到的坑，如果我们信任InheritableThreadLocal能在父子线程间正确传递线程上下文的话。显然这里并不可信，通常我们会说线程上下文被污染，这也是使用线程池尤其要注意的问题。

如果我们对所谓的线程上下文（ThreadLocal）和线程池稍有点认识的话，其实也不难理解。线程上下文的数据当然和线程有关（本质就是存在线程中），而线程池本身就是提供复用的线程，其中的线程仅用来执行一些任务。如果我们向其中的线程设置一些上下文数据，那么这些线程无论是执行完放回线程池还是开始执行其他的任务，那么我们的线程本身没发生变化，携带的上下文自然也仍然存在。但此时的上下文由于在不同的任务处理过程中都会使用，自然存在污染问题。

问题

那么问题来啦，为什么请求号=3时，traceId和请求号=1时是一样的？如果再继续请求会怎么样？

如果你注意到，我们的异步线程池是一个Executors.newSingleThreadExecutor()，也许你心里可能已经有答案了。

回答

这里其实无非是要解答一个问题，线程上下文是在什么时候、哪些地方被传递的？

那这里我们可能要尝试看一点ThreadLocal和ThreadPoolExecutor的源码，来狡辩一波~

首先，我们要看ThreadLocal在set操作是到底是如何将数据设置到线程上下文上。

package java.lang;

public class ThreadLocal<T> {

    public void set(T value) {
        Thread t = Thread.currentThread();
        // 根据线程获取线程上下文，其实就是个map，线程上下文就是kv键值对,不同的Thread获取到各自Thread的ThreadLocalMap
        ThreadLocalMap map = getMap(t);
        if (map != null)
        	// 上下文的key是threadLocal对象，value是值，保留一份对ThreadLocal对象的引用
            map.set(this, value);
        else
            createMap(t, value);
    }
    
    public T get() {
        Thread t = Thread.currentThread();
        // 获取当前线程上下文
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            // 根据threadLocal对象引用获取value
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }
    
     public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }
    
    // ThreadLocalMap是什么东西？ 就是Thread的一个属性，自然是存储在Thread中的
    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

}

基本上看到这里，ThreadLocal的工作原理大概就清楚了，关键的地方在于根据线程获取到的线程上下文ThreadLocalMap，它仅与当前线程有关，通过这个ThreadLocalMap来存储当前 ThreadLocal对象的引用和数据。

而InheritableThreadLocal呢？

package java.lang;

public class InheritableThreadLocal<T> extends ThreadLocal<T> {

    ThreadLocalMap getMap(Thread t) {
       return t.inheritableThreadLocals;
    }
}

跟ThreadLocal原理没什么区别，只是使用了Thread中的另一个inheritableThreadLocals。那我们下面看一下t.inheritableThreadLocals在哪里来做线程切换时上下文的传递呢？

那会不会在当前线程向异步线程池提交任务后，异步线程池的线程在执行时由于线程切换而传递上下文呢？想多了…如果这样的话我们的请求号=2时的traceId就不会和请求号=1时一样了。显然传递只发生了一次。直接找一下inheritableThreadLocals的使用。

在Thread被创建时执行init方法过程中复制了父线程的inheritableThreadLocals¹。

那么其实比较清晰了，使用线程池时，核心线程在首次使用被创建的时候能正确复制父线程的上下文，但之后已复制上下文的核心线程不会回收的情况下，线程池中的线程上下文将不会再被传递（改变）！这是我们尤其要注意使用InheritableThreadLocal的点，如果我们过于信任它的传递上下文能力，无疑在碰到线程池时要踩坑！反而不如使用ThreadLocal时刻提醒自己要手动传递、初始化、清理线程上下文。

关于ThreadPoolExecutor如何创建核心线程和非核心线程以及其回收的过程，这里无需赘述。我们可以简单认识，ThreadPoolExecutor在创建核心线程时会new Thread(),当任务等待队列满的时候也会尝试创建非核心线程，非核心线程在无任务时保活一段时间后被回收，而核心线程不会被回收。

---

1. 注意这里比较有意思也可能踩坑的地方，Java中所有的对象都是引用对象，所以如果我们在子线程中修改上下文，要注意通常也会影响到父线程的上下文。 ↩︎