背景：

一个上线了很久但是请求量很低(平均每天一两次)的历史功能突然出现空指针报错：



 

 

我们翻开代码定位到对应的报错代码：



 

 

结合堆栈和代码可以确定是由于bdIdJobMap的值为null导致往bdIdEmployeeJobMap这个map中putAll的时候空指针了。

而bdIdJobMap又取自employeeJobMapThread.get(); 那么这个employeeJobMapThread又是何物？



 

 

哦豁，employeeJobMapThread居然是个InheritableThreadLocal。

梳理一下报错代码的上下文逻辑如下：



是否和最近的上线有关？

相信大家都有这样的共识：线上出现报错，首先怀疑是否和最近的上线有关系。

我们做的第一件事情也是排查了近期的上线功能，从上线的功能点和相关代码上来看都和这次报错的代码没什么关系，

因此初步排除了这个原因。所以接下来只能进一步了解代码来排查原因了。

要搞清楚当前报错的根因，毫无疑问肯定是要翻过InheritableThreadLocal这座小山啦。



简单聊下InheritableThreadLocal：

提起ThreadLocal，大家应该相对都比较熟悉了，比如存放登录用户信息到ThreadLocal变量中，然后在接口层可以比较方便的获取登录用户，帮助开发提效。

但是对于InheritableThreadLocal，有不少同学都不太了解。

挑重点来说，InheritableThreadLocal相比ThreadLocal多一个能力：在创建子线程Thread时，子线程Thread会自动继承父线程的InheritableThreadLocal信息到子线程中，进而实现在在子线程获取父线程的InheritableThreadLocal值的目的。

举个简单的栗子对比下InheritableThreadLocal和ThreadLocal：

public class InheritableThreadLocalTest {

    private static final ThreadLocal<String> threadLocal = new ThreadLocal<>();
    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();

    public static void main(String[] args) {
        testThreadLocal();
        testInheritableThreadLocal();
    }

    /**
     * threadLocal测试
     */
    public static void testThreadLocal() {
        // 在主线程中设置值到threadLocal
        threadLocal.set("我是父线程threadLocal的值");

        // 创建一个新线程并启动
        new Thread(() -> {
            // 在子线程里面无法获取到父线程设置的threadLocal，结果为null
            System.out.println("从子线程获取到threadLocal的值: " + threadLocal.get());
        }).start();
    }

    /**
     * inheritableThreadLocal测试
     */
    public static void testInheritableThreadLocal() {
        // 在主线程中设置一个值到inheritableThreadLocal
        inheritableThreadLocal.set("我是父线程inheritableThreadLocal的值");

        // 创建一个新线程并启动
        new Thread(() -> {
            // 在子线程里面可以自动获取到父线程设置的inheritableThreadLocal
            System.out.println("从子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());
        }).start();
    }

}

执行结果：



 

 

可以看到子线程中可以获取到父线程设置的inheritableThreadLocal值，但不能获取到父线程设置的threadLocal值。

为什么InheritableThreadLocal能够做到这点呢？

是因为在父线程创建子线程Thread的时候，Thread的构造器内部会自动继承父线程的InheritableThreadLocal到子线程。

Thread源码这两处地方解释了原因：



 

 

init方法内部实现：



 

 



通过这个简单的介绍可以帮助对于InheritableThreadLocal不了解的同学有一个初步的了解，本文不是专门介绍InheritableThreadLocal的深入原理，所以就不展开聊了，大家感兴趣可以自己进一步探索。

验证InheritableThreadLocal+线程池：

前面介绍了InheritableThreadLocal可以自动把父线程的InheritableThreadLocal信息继承到子线程Thread中。

但是在业务项目中真正需要用到子线程的时候正经人谁自己new Thread，咱可是用线程池的。

当然了，就像文章开头说明的，这次报错的代码里面也用线程池来执行异步任务。

那么InheritableThreadLocal+线程池的组合会摩擦出什么样的火花呢？

我把这次报错的代码精简之后得到下面的示例（实际代码中往InheritableThreadLocal赋的值类型不是字符串，后面会提到）：

package com.dada.bd.data.service;

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class InheritableThreadLocalWithThreadPoolTest {

    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
    private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            2,
            2,
            0L,
            TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>(3000),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );

    public static void main(String[] args) {
        testInheritableThreadLocalWithThreadPool();
        threadPoolExecutor.shutdown();
    }

    /**
     * inheritableThreadLocal+线程池测试
     */
    public static void testInheritableThreadLocalWithThreadPool() {
        // 1. 在主线程中设置一个值到inheritableThreadLocal
        inheritableThreadLocal.set("我是父线程inheritableThreadLocal的值");

        // 2. 提交异步任务到线程池
        threadPoolExecutor.execute(() -> {
            // 3. 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？
            System.out.println("从线程池-子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());
        });

        // 4. 清除inheritableThreadLocal
        inheritableThreadLocal.remove();
    }

}



 

 

执行结果如图所示，可以看到在线程池里面也可以获取到父线程设置的inheritableThreadLocal值。

接下来我们来分析下InheritableThreadLocal+线程池的执行过程：





 

也就说只有在以下这两个场景下才会继承父线程的InheritableThreadLocal：

1.线程池当前线程数 < 核心线程数

2.线程池当前线程数 >= 核心线程数 && 队列已满 && 线程数 < 最大线程数（本次线上报错的代码使用的线程池设置的coreSize和maxSize一致，所以走不到该场景）

其他情况都是在复用线程池现有的Thread，自然也就不会继承父线程的InheritableThreadLocal。

我们提交多个异步任务到线程池来验证下：

package com.dada.bd.data.service;

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class InheritableThreadLocalWithThreadPoolTest {

    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
    private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            2,
            2,
            0L,
            TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>(3000),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );

    public static void main(String[] args) {
        testInheritableThreadLocalWithThreadPool("张三");
        testInheritableThreadLocalWithThreadPool("李四");
        testInheritableThreadLocalWithThreadPool("王五");
        testInheritableThreadLocalWithThreadPool("赵六");
        testInheritableThreadLocalWithThreadPool("孙七");
        threadPoolExecutor.shutdown();
    }

    /**
     * inheritableThreadLocal+线程池测试
     */
    public static void testInheritableThreadLocalWithThreadPool(String param) {
        // 1. 在主线程中设置一个值到inheritableThreadLocal
        inheritableThreadLocal.set(param);

        // 2. 提交异步任务到线程池
        threadPoolExecutor.execute(() -> {
            // 3. 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？
            System.out.println("线程名: " + Thread.currentThread().getName() + ", 父线程设置的inheritableThreadLocal值: " + param + ", 子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());
        });

        // 4. 清除inheritableThreadLocal
        inheritableThreadLocal.remove();
    }

}





 

执行结果用表格形式展示如下：

可以看到InheritableThreadLocal+线程池的组合，会面临InheritableThreadLocal污染的问题，即异步任务可能取到其他父线程设置的InheritableThreadLocal值。

有同学会提到我们不是在代码里面加了inheritableThreadLocal.remove()来清除inheritableThreadLocal的吗？为什么没有清除掉呢？

这是因为此时我们清除的只是父线程的inheritableThreadLocal，而没有清除子线程的inheritableThreadLocal的缘故。



为什么InheritableThreadLocal污染对线上没有产生影响？

既然InheritableThreadLocal+线程池的组合，会存在InheritableThreadLocal污染的问题，那岂不是线上报错的这段代码也存在这个问题？

再次检查代码，确认历史代码的确存在这个问题，

但是，这个代码上线2年多为啥一直稳定运行且没有用户反馈过功能有问题？只有最近突然出现报错？一时之间脑袋懵懵的。



 

 

仔细检代码之后发现：

这段代码在父子线程之间通过InheritableThreadLocal类型变量employeeJobMapThread传递的值是【全量的<人员Id, 该人员基本信息>结构的map】，可以近乎看做是一个不变的常量，所以虽然异步任务会拿到污染的数据，也是正常可以用的，没有产生业务影响。

这种感觉怎么说呢，只能说感叹前人的智慧，把几乎不可能做到了可能~

好了，到这里我们解释了为什么这段代码上线这么久一直没问题，因为代码确实有InheritableThreadLocal污染问题，但被污染了也不影响使用。。。所以从最终结果来看确实可以正常运行。



 

 



什么原因导致子线程获取到的InheritableThreadLocal值是null？

但是。。。说了这么多，还是不能解释为什么线上代码获取到的inheritableThreadLocal值会是null。

1.难道父线程设置的inheritableThreadLocal值可能会是null？

检查代码发现父线程设置的inheritableThreadLocal不可能为null，顶多会是空集合：



 

 



2.难道是线程池创建之后通过prestartAllCoreThreads初始化了核心线程，在执行异步任务的时候，都是复用的已有线程导致的？

检查了对应线程池的初始化代码，发现并没有初始化核心线程，也排除了这个可能。而且如果真的是该原因22年上线之后功能一定是有问题的，前面说过，该功能上线之后没人反馈过异常，所以也可以排除该原因。



从这些已知的信息来推断，可以推断出这段历史代码写法虽然有隐患，但是不是引发当前空指针的的原因。

3.剩下的只有一种可能：存在线程池的共用。

在执行这个报错的异步任务的时候，复用了某个已有的线程A，并且当时创建该线程A的时候，没有继承InheritableThreadLocal，进而导致后面复用该线程的时候，从InheritableThreadLocal获取到的值为null。

而只要是通过这段历史代码创建的线程一定是没问题的，所以一定是存在其他业务共用了这个线程池，并且这个业务优先执行进而初始化了线程池的线程，导致线程池的线程没有继承InheritableThreadLocal。

如下代码示例：

package com.dada.bd.data.service;

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class InheritableThreadLocalWithThreadPoolTest {

    private static final InheritableThreadLocal<String> inheritableThreadLocal = new InheritableThreadLocal<>();
    // 这里线程池core/max数量都只有2
    private static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            2,
            2,
            0L,
            TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>(3000),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );

    public static void main(String[] args) {
        // 先执行了不涉及InheritableThreadLocal的子任务初始化线程池线程
        testAnotherFunction();
        testAnotherFunction();
        // 后执行了本次的历史代码，其涉及InheritableThreadLocal
        testInheritableThreadLocalWithThreadPool("张三");
        testInheritableThreadLocalWithThreadPool("李四");
        threadPoolExecutor.shutdown();
    }

    /**
     * inheritableThreadLocal+线程池测试
     */
    public static void testInheritableThreadLocalWithThreadPool(String param) {
        // 1. 在主线程中设置一个值到inheritableThreadLocal
        inheritableThreadLocal.set(param);

        // 2. 提交异步任务到线程池
        threadPoolExecutor.execute(() -> {
            // 3. 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？
            System.out.println("线程名: " + Thread.currentThread().getName() + ", 父线程设置的inheritableThreadLocal值: " + param + ", 子线程获取到inheritableThreadLocal的值: " + inheritableThreadLocal.get());
        });

        // 4. 清除inheritableThreadLocal
        inheritableThreadLocal.remove();
    }

    /**
     * 模拟另一个独立的功能
     */
    public static void testAnotherFunction() {
        // 提交异步任务到线程池
        threadPoolExecutor.execute(() -> {
            // 在线程池-子线程里面可以获取到父线程设置的inheritableThreadLocal吗？
            System.out.println("线程名: " + Thread.currentThread().getName() + ", 线程池-子线程摸个鱼");
        });
    }

}

执行结果：



 

 

在项目里面搜一下看看，果真如此，有2出地方在用这个线程池，并且另外的一处代码中提交的异步任务不涉及inheritableThreadLocal：



 

 

示意图如下：

逻辑执行顺序为：创建线程池 - 执行功能A - 执行功能A - 执行功能B

其中：

功能A全流程均不涉及InheritableThreadLocal

功能B对应报错的代码，主线程设置InheritableThreadLocal并且在子线程使用



 

 

至此，线上报错的根因确定了：就是因为InheritableThreadLocal + 线程池共用导致。



扩展一下：

假如执行顺序是这样呢：创建线程池 - 执行功能B - 执行功能B - 执行功能A



 

 

结局居然是一切安好。



假如执行顺序是这样呢：创建线程池 - 执行功能B - 执行功能A - 执行功能B



 

 

发现了吗？如果应用启动之后功能B先执行并且初始化了线程池所有核心线程，那么一切正常，否则就可能报错。

也就是说功能B是否正常还看运气的，运气好就正常执行，运气不好就报空指针的错。



这你敢信？



 

 

小插曲：

这个问题的排查当中还遇到了2个小插曲：

插曲1：

最初怀疑是线程池复用导致的，但是在IDEA里面搜代码的时候粗心大意没有看到其他地方在复用线程池。

因此期间一度自我怀疑见鬼了，导致本来可以一两个小时确定根因的，结果饶了弯路多花了两个小时才确定根因。

所以说排查问题的时候每一步都要保持细心，得出的每一个结论都应该是证据确凿，理由充分，

否则会让自己兜兜转转浪费宝贵的时间。



插曲2：

排查代码的时候发现异步任务代码没有做任何的异常处理，这其实是很坑的。

有经验的同学应该知道，线程池里面提交异步任务如果没有做异常处理，出现异常的话不会有任何的日志信息。

本地运行的时候会打印到控制台，但是线上控制台的信息可不会记录到日志里面。

所以经常遇到异步任务执行结果不符合预期，但是线上没有任何相关日志就是这个原因。

我们这里有日志是因为使用的线程池是二次封装过的，里面对异步任务做了兜底的异常记录。



总结：

前面分析到了导致空指针的原因是线程池共用导致的老代码报错，而共用这个线程池的代码是新上线的功能引入的。

这就打脸了开头我们检查了上线的功能与此无关，实则有关。

只是我们评估复用线程池的影响时，很难想到会有这样的影响，通常我们会考虑：

针对InheritableThreadLocal，我个人的建议是：



针对如何有效的应对业务研发遇到的一些“疑难杂症”，我的建议是：



最后，愿天下没有故障，没有线上问题，没有bug。