ThreadLocal遇到线程池出现数据问题和解决方案

ThreadLocal开发中常用，通过ThreadLocal操作数据实现线程之间的隔离，保证线程之间不会因为操作同一数据导致数据安全问题。但是这种隔离是有适用范围的，也就是说在某些特定的情况下还是会出现数据安全问题的。这种特定情况下就是使用到线程池，并且在ThreadLocal使用前后没有做数据清理，就会导致安全问题，下面来看看出现的情况和具体怎么去解决。

ThreadLocal正常使用

一个main方法的主线程，再创建一个新的线程作为模拟线程，同时操作ThreadLocal，通过在打印对应的输出值来看ThreadLocal的作用。

public class ThreadLocalDemo {

    private static ThreadLocal<Integer> local = new ThreadLocal<>();

    public static void main(String[] args) {
        local.set(1);
        System.out.println(Thread.currentThread().getName() + "===>" + local.get());
        operateLocal();
        //模拟另一个线程
        new Thread(() -> {
            System.out.println(Thread.currentThread().getName() + "===>" + local.get());
            local.set(4);
            System.out.println(Thread.currentThread().getName() + "===>" + local.get());
            operateLocal();
        }).start();
    }

    private static void operateLocal() {
        Integer value = local.get();
        local.set(++value);
        System.out.println(Thread.currentThread().getName() + "===>" + local.get());
    }
}

输出的结果：

main===>1
main===>2
Thread-0===>null
Thread-0===>4
Thread-0===>5

从结果就可以知道，两个线程之间没有互相的干扰，各自操作各自空间里面的数据，达到了线程安全的特性。这个也是正常使用所用到的。单对于这种方式来说是线程安全的，数据也是安全的，但是下面看看会出现问题的场景。

线程池下的ThreadLocal

这里创建一个线程池，为了模拟方便，线程池里面只创建一个线程，然后通过ExecutorService两次来对ThreadLocal进行操作，你会发现一个问题。

public class ThreadLocalDemo {

    private static ThreadLocal<Integer> local = new ThreadLocal<>();

    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newSingleThreadExecutor();//线程池
        executorService.execute(() -> {//1
            local.set(123);
            System.out.println(Thread.currentThread().getName() + "==>" + local.get());
        });
        executorService.execute(() ->//2
                System.out.println(Thread.currentThread().getName() + "==>" + local.get())
        );
        executorService.shutdown();
    }
}

在代码块1向ThreadLocal里面添加值为123，然后打印出来对应的线程名称和ThreadLocal里面存储的值。然后在代码块2里面从ThreadLocal里面获取值。输出的结果如下：

pool-1-thread-1==>123
pool-1-thread-1==>123

两个位置输出的内容相同，也就意味着当使用线程池的时候，一个线程设置的数据可能残留在ThreadLocal里面，等下一个线程使用的时候可能直接拿到之前操作残留的数据，导致数据的污染问题。

在这里需要了解的是，在很多博客里面(当然包含我转载的一些博客)都说ThreadLocal里面的ThreadLocalMap的键是弱连接，当下一次GC回收的时候会自动回收，不会出现数据的安全问题。但是这种说法是有特定场景的，也就是说当前线程执行结束后，ThreadLocal对象需要被手动的置为null。因为GC不是时刻去执行的，是需要达到一定的条件，所以存在滞后。

在使用ThreadLocal的时候为了线程安全，基本都是放在成员变量里面，每次执行结束置为null的操作稍微不注意就不会去做，或者漏掉，这样带来的另一个麻烦就是每次使用的时候还要new创建一个ThreadLocal，总感觉很别扭。

总结一下：

• GC执行需要条件不可能在当前线程执行结束立即执行，清理掉ThreadLocal里面存储的数据
• 即使GC触发，在ThreadLocal被外部的成员变量建立了强连接，是一样清理不掉的
• 每次执行结束将null赋值给成员变量，在执行开始的时候，手动初始化ThreadLocal

提出的解决方法

线程池和ThreadLocal不同时用

这个好像有点扯，线程池在正常的一个java项目中都会被用到，换句话说就是放弃ThreadLocal不用啦。所以这种解决方案过于极端。

清理ThreadLocal数据

这个是我个人目前想到的最好的方法了，可以使用面向切面的思想，切入到使用ThreadLocal的方法，在方法执行前、执行结束后、抛出异常时对ThreadLocal进行数据清理动作。

示例代码：

public static void main(String[] args) {
    local.remove();//清理
    try {
        //……
    } catch (Exception e) {
        //……
    } finally {
        local.remove();//清理
    }
}

只是demo示例，没有具体的业务内容，也没有根据切面来具体实现，偷懒了一把，只提供思路。

总结

在使用ThreadLocal的时候还是要很注意的，虽然在ThreadLocal里面已经用弱连接这种机制和GC对弱连接的回收方式来实现及时的数据回收，在实际的开发中，还是存在一些问题的，所以不能完全依靠于ThreadLocal，还是要多方面的思考，做到严谨性。这个问题之前我也没有想到，在业务代码中使用到，结果是同事看到我的代码提醒我的(论有一群好的战友的重要性)。