ThreadLocal简单介绍

ThreadLocal同ReentrantLock，CyclicBarrier等都属于并发工具类，他们都是为了解决多线程数据一致性问题而出现的。与ReentrantLock不同的是，ThreadLocal采取的是一种以空间换时间的策略。
举个简单的例子，假设现在有100个人填写信息表，可是只有一支笔，为了防止哄抢，以ReentrantLock为代表的锁所使用的思路是，通过控制人员使用笔的顺序，来达到防止哄抢的目的。而ThreadLocal采取的思想则是给每个人发一只笔，这样大家只使用自己手头里的笔，也不就不存在竞争问题了。
正如ThreadLocal其名，ThreadLocal所拥有的变量是线程私有的，既然多个线程同时访问一个共享变量会造成线程安全问题，那么我为什么不给每一个线程分配一个变量，这样就避免了多线程之间的同步，没有了同步，代码的运行所需要的时间就会减少。虽然ThreadLocal的使用可以减少时间上的开销，可是我们也很容易发现其会增大内存空间上的开销。

ThradLocal使用场景

SimpleDateFormat作为一个格式化日期的常用类，却存在着线程不安全的问题，运行下面的代码

public static void main(String[] args)
{
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
    ExecutorService es = Executors.newFixedThreadPool(100);
    for (int i = 0; i < 1000; i++)
    {
        es.execute(()->{
            try
            {
                Date date = sdf.parse("2019-11-13 08:23:" + new Random().nextInt(60));
            } catch (ParseException e)
            {
                e.printStackTrace();
            }
        });
    }
    es.shutdown();
}

会报出如下异常

java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

究其原因，在于SimpleDateFormat类内部有一个Calendar对象引用,它用来储存和这个SimpleDateFormat相关的日期信息，而这个对象又是线程共享的且没有做任何同步处理。

有了上面的分析，要解决这些异常也就不是什么难事了。大家首先想到的可能是加锁，即用synchronize或ReeentrantLock把调用parse方法那一部分包起来，但是这种方法在多线程竞争激烈的时候会带来效率问题，代码这里我就不写了。除了加锁，还有一种更好的方法，那便是使用ThreadLocal。

public static void main(String[] args)
{
   ThreadLocal<SimpleDateFormat> threadLocal = new ThreadLocal<>();
   ExecutorService es = Executors.newFixedThreadPool(100);
   for (int i = 0; i < 1000; i++)
   {
       es.execute(()->{
           try
           {
               if(threadLocal.get() == null)
                   threadLocal.set(new SimpleDateFormat("yyyy-MM-dd hh:mm:ss"));
               Date date = threadLocal.get().parse("2019-11-13 08:23:" + new Random().nextInt(60));
           } catch (ParseException e)
           {
               e.printStackTrace();
           }
       });
   }
   es.shutdown();
}

ThreadLocal 可以确保每个线程都可以得到单独的一个 SimpleDateFormat 的对象，那么自然也就不存在竞争问题了。

除了常用的SimpleDateFormat，我们还可以在Spring框架中找到ThreadLocal的身影。

@RestController
public class TestController
{
    @Autowired
    private HttpServletRequest request;
    
    @GetMapping("/hello")
    public String hello()
    {
        String token = request.getHeader("token");
        return token;
    }
}

对于上面的代码，细心的人可能会问，直接把request当作一个成员变量注入，这样所有请求将共享一个request对象，程序肯定会乱套啊。但是当我们运行上述代码的时候，我们会发现程序并没有什么问题，这时为什么呢。原因很简单，spring是一个非常成熟的框架，当我们要注入一个HttpServletRequest对象作为一个成员变量时，它会以ThreadLocal的形式进行注入，这样每个请求的request对象都是不同的。

ThreadLocal原理分析

看了上面的介绍，或许有人不禁要问，ThreadLocal这么强大，那它是怎么实现的呢。其实ThreadLocal与JUC中其他类的最大不同点是，ThreadLocal本身不存储数据，它更像一个工具类，负责变量的维护与获取，就像java.utilCollections类，它本身并不存储任何数据结构，但是可以完成许多数据结构的操作。当我们对ThreadLocal对象进行set操作时，ThreadLocal并没有把那些对象保存在自己这里，而是保存在了调用该方法的Thread对象里。

Thread类

其三者UML关系如图所示，其中Entry对象代表了ThreadLocalMap里的一个键值对。

ThreadLocal的get方法源码如下

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();
    }

首先第二行获取执行该方法的当前线程，然后第三行调用getMap方法来获取该线程对应的ThreadLocalMap，其方法声明如下

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

获取到了Map之后首先进行判空处理，我们知道一个Map实际上是有许多Entry聚合而成的，而这些Entry保存的是所有的键值对（键为ThreadLocal，值为指定的泛型）信息。我们现在已经获取到了Map和键（当前ThreadLocal），我们要获取对应的值，需要先去在该Map中根据该键去查找对应的键值对，然后从这个键值对里获取value。而map.getEntry(this)所做的就是去从这个当前线程对应的Map中去查找键位该ThreadLocal的键值对。

ThreadLocal内存泄漏问题

我们前面说过，ThreadLocalMap虽然可以当作一个Map来使用，但是其和一般的Map还是有一定的差别的。在这里最重要的一点就是其键值对对象Entry的声明

static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

我们发现其继承了一个WeakReference的对象。那么这个WeakReference对象是个什么鬼呢，要讲这个就必须要牵涉到jvm的垃圾回收了。现代jvm采用的垃圾回收方法一般都是可达性分析，而一个对象是否可达则取决于是否存在一条从GCRoot到当前对象的引用链。java虚拟机规范里规定了四种引用类型，分别是强引用，软引用，弱引用和虚引用。其中弱引用也就是WeakReference，每次垃圾回收时，如果发现有弱引用对象，就将其回收。
我们看到Entry继承自WeakReference，并指定泛型为ThreadLocal，在构造函数时调用了super(k);，这表明只要这个ThreadLocal失去了其他的强引用，该Entry就会被回收。

如图，此时Entry对象不会被回收，虽然ThreadLocal对象和Entry之间是弱引用，但ThreadLocal引用和ThreadLocal是强引用。当代码执行出ThreadLocal的作用域时，在栈上的ThreadLocal引用会被清除，此时在堆上的ThreadLocal对象只有一个Entry对象的引用，由于此引用是弱引用，所以在下一次垃圾回收来临时，该ThreadLocal对象会被垃圾回收器回收。我们在不难发现，ThreadLocal的Entry之所以设计成一个弱引用的对象，就是为了防止ThreadLocal对象内存泄露。虽然解决了ThreadLocal对象的内存泄漏，但是会产生一个新的问题，那就是value对象的内存泄露。当ThreadLocal被回收后，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏

其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

但是这些被动的预防措施并不能保证不会内存泄漏：

• 使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏
• 分配使用了ThreadLocal又不再调用get(),set(),remove()方法，那么就会导致内存泄漏。

综合上面的分析，我们可以理解ThreadLocal内存泄漏的前因后果，那么怎么避免内存泄漏呢？

• 每次使用完ThreadLocal，都调用它的remove()方法，清除数据。
• 在使用线程池的情况下，没有及时清理ThreadLocal，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用ThreadLocal就跟加锁完要解锁一样，用完就清理。