ThreadLocal

1、使用场景

• 当客户端触发请求，需要为之生成唯一的事务id，并且需要将此事务id传递给多个业务方法，dao层方法等等，我们就需要将这个事务id作为参数传递给所有业务方法，代码会产生不必要的冗余，使用ThreadLocal变量设置此事务id，之后无论什么方法都可以从threadlocal访问这个事务id，由于每个请求在tomcat容器中是单独的线程处理，因此事务id对于每个线程都是惟一的；
• 当多个线程访问同一个变量时，需要加锁保证线程安全，消耗时间，当我们使用ThreadLocal，保证线程隔离就不需要加锁，单消耗空间，类似于空间换时间。

2、基本原理，相关类图

• 跟常用的map一样，ThreadLocalMap底层也维护了一个Entry数组

3、内存泄漏问题

• 好文链接：https://www.jianshu.com/p/30ee77732843
• 从上文图中可知，如果threadLocal外部强引用被置为null，那么指向threadLocal实例的就只有Entry中的key作为弱引用了，下次gc回收，entry就存在key为null的情况，因此，无法通过为null的Key去访问到该entry的value，除非线程结束，否则value一直存在；
• 引用链：thread->threadLocalMap->entry->value，导致在垃圾回收的时候进行可达性分析的时候不会被回收掉，但是该value永远不能被访问到，这样就存在了内存泄漏。当然，如果线程执行结束后thread会断掉，因此entry都会被回收掉，在实际使用中我们会用线程池去维护我们的线程，会存在为了复用线程而不会结束这个线程的情况。
• 因此ThreadLocal变量使用完成后一般调用remove()方法：

        /**
         * Remove the entry for key.
         */
        private void remove(ThreadLocal<?> key) {
            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                if (e.get() == key) {
                    e.clear();
                    expungeStaleEntry(i);
                    return;
                }
            }
        }