通过阅读源码可以分析出来Thread（线程本身）、ThreadLocalMap（存储一个又一个ThreadLocal对象的map）、ThreadLocal的关系如下图可能有点潦草，但是足够理清这个问题了
上一点代码证明这个关系，代码选自JDK8 Thread类
public
class Thread implements Runnable {
/* Make sure registerNatives is the first thing <clinit> does. */
private static native void registerNatives();
static {
registerNatives();
}
private volatile String name;
private int priority;
private Thread threadQ;
private long eetop;
/* Whether or not to single_step this thread. */
private boolean single_step;
/* Whether or not the thread is a daemon thread. */
private boolean daemon = false;
/* JVM state */
private boolean stillborn = false;
/* What will be run. */
private Runnable target;
/* The group of this thread */
private ThreadGroup group;
/* The context ClassLoader for this thread */
private ClassLoader contextClassLoader;
/* The inherited AccessControlContext of this thread */
private AccessControlContext inheritedAccessControlContext;
/* For autonumbering anonymous threads. */
private static int threadInitNumber;
private static synchronized int nextThreadNum() {
return threadInitNumber++;
}
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
/*
* InheritableThreadLocal values pertaining to this thread. This map is
* maintained by the InheritableThreadLocal class.
*/
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
///此处省略其余diamante
}
我们看到倒数第二行代码中有一个threadLocals 的属性，这里可以说明ThreadLocalMap是包含于Thread里面的，或者换个表达方式，Thread里面有ThreadLocalMap的强引用（这点重要，因为涉及到后面内存溢出的问题）在线程池化的时候。在理清了Thread对ThreadLocalMap的关系后我们将视线瞄准到ThreadLocal这个类本身。
ThreadLocal
我个人认为就看清楚两个方法就能将这个事情谈明白，就是ThreadLocal类里面的set方法，还有ThreadLocaMap的set方法。通过代码可以知道ThreadLocalMap是ThreadLocal里面的内部类。
先看一下ThreadLocal内的set方法
public void set(T value) {
//获取当前线程
Thread t = Thread.currentThread();
//获取当前线程关联的ThreadLocalMap
ThreadLocalMap map = getMap(t);
//如果map存在，将value存放进去否则创建map
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
从这个set中我们看到ThreadLocal里面的set实际是调用的ThreadLocalMap 中的set方法
调用关系 ThreadLocal.set()-->ThreadLocalMap.set()
我们再看一下ThreadLocalMap中的set方法
private void set(ThreadLocal<?> key, Object value) {
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)]) {
ThreadLocal<?> k = e.get();
//是当前key那么直接进行替换
if (k == key) {
e.value = value;
return;
}
//因为Entry里面用的是弱引用，有可ThreadLocal对象没有直接引用后被GC了，
//在内存分配时候进行充分利用这里可以看成是对泄漏的内存的一种利用
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
//
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
p估计很多小伙伴看到这里会比较奇怪链表呢？呜哈哈木有，在ThreadLocalMap中是通过数组进行保存每一个Entry的，这里面可能要引用一下《深入理解java虚拟机》里面周志明大佬给讲解的计算机内存分配的方式，空闲列表、指针碰撞。空闲列表大概意思是在程序进行内存分配的时候先通过空闲列表查询是否有大小合适的空间进行内存分配，而指针碰撞的分配方式则是按照顺序的进行内存分配，程序保留一个上次分配的指针地址，下次分配内存从此处开始。考虑下仿佛有那么点相似性。
p再来仔细读一下这个代码吧，显示通过ThreadLocal作为key计算出Threadloca这个key应该分配到table的哪个格子里面。下面的for循环就是进行开放寻址了也就是如果分配的数组下表已经有值了那么就向后面进行分配。
我们已经意识到了K==key的判断其实是为了利用被泄漏的内存所以我们就要看下如何产生的内存泄漏
其实通过set方法的这种分配方式我们应该在看下get方法，充分体会一下数组进行分配的好处与坏处。也就是查询效率问题存储既然用的数组，那么在ThreadLoca进行get的时候肯定也要基于O(N)的复杂度进行查找，这可能也是为何一些老鸟告诫我们不要给线程使用过多的ThreadLocal的原因吧。因为太多的情况下回造成取值变慢？
内存泄漏的原因
通过源码已经能够很清楚的看到Thread跟ThreadLocalMap是强应用的，但是ThreadLocalMap中的Entry数组是继承了WeakReference 也就是弱引用这里将java的集中引用类型总结一下
⑴强引用（StrongReference）
强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
⑵软引用（SoftReference）
如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
⑶弱引用（WeakReference）弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
⑷虚引用（PhantomReference）
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。
既然如此那么也就是如果我们的threadlocal在方法调用中被new出来，然后存进map中了，方法执行后没有强应用与之关联，那么就会被垃圾回收器回收，那么会出现
我们知道get是通过比对key进行数据获取的，那么为null的key所关联的value就无法被获取，形成内存泄漏
当然我们刚才也看到了java8中进行了优化，也就是在出现hash碰撞时候进行利用，但是形成内存泄漏还是实际产生了的也。
总结一下之前踩过的坑，之前做用户登录后将用户信息保存到了threadlocal中，因为使用的是tomcat，tomcat的线程都是池化的，那么造成了多个线程之间用户请求过来串了，当然这是一个比较低级的错误。
另外说下目前主要用的场景或者我看到过的使用场景，一般在分布式服务中心，网关鉴权后会给request添加部分参数，可能是用户的信息，然后request将这部分信息携带给其他微服务，其他微服务，将数据会存储到ThreadLocal中，方便在处理请求的任何时候都能拿到当前用户的信息，而且不需要查询共享缓存。
还有就是写线程不安全的类，比如一个用户请求会用到多次simpledateformat对象，那么可以在用户请求来的时候先new这样一个对象放到ThreadLocal里面去，后面的处理都用这个对象进行日期的处理。然后我们假定的场景是单一线程，不能用户请求线程，将smf传到多线程中去，这种操作纯属抬杠了。
好就整理到这里，周末将一些最佳实践再补充进来，做个留存方便少踩坑
