- 在每个Thread对象里都有一个ThreadLocalMap对象，键值是ThreadLocal，ThreadLocalMap这个对象只能通过ThreadLocal来操作，不能通过Thread操作。
- 在往ThreadLocal对象里set值时，会初始化Thread的ThreadLocalMap对象，然后往里面put值，键值就是ThreadLocal对象。取值时从当前线程Thread里取得ThreadLocalMap对象，ThreadLocal做键去get值。
- 每个ThreadLocal只能存储一个对象，即如果想存储对个对象的话那么需要定义多个ThreadLocal。
- 总结：ThreadLocal并不是解决共享对象线程安全的，其实往ThreadLocal中set或initialValue中的对象并不是共享的，基本上是每个线程都new一个放进去。如果你真的放共享对象进去，那么在get的时候返回的仍然是共享对象，还是会有线程安全问题。话说谁又会傻了吧唧的把共享对象往ThreadLocal里扔呢？
- 由于放进去的是每个线程对应的一个实例，因此在用的时候完全不用担心线程安全。同时能带着你放进去的实例对象到处跑。比如在MVC系统中，你在Controller层放一个对象到ThreadLocal中，那么在DAO和Service中都可以取到，比用方法参数传递优雅多了。但是有一个前提：即是在同一个线程中完成所有操作的，如果不是那么就要小心了。
- 一般ThreadLocal对象都是static的，意味着ThreadLocal不会被gc。
- 为什么不在ThreadLocal里维护一个Map，以线程Thread作为key呢？我想原因如下：
- 在ThreadLocal中维护Map，那么这个Map会变得很大，要经常rehash，加锁等等，同时Thread基本上是朝生熄灭的对象，这样Map如何remove这些对象就是一个大问题。而放在Thread中，在Thread结束后自动由jvm来做gc。同时Thread中的Map基本变化很小。
- 如果是线程池，那么线程不会被gc，这时这个Map和其中的对象一直存在，知道这个线程再次被使用，再次往ThreadLocal里set值把以前的对象给覆盖掉。
这个Map是弱引用，可能是防止万一ThreadLocal不是static的，在ThreadLocal对象不可达后不能被gc吧。不过如果ThreadLocal是静态的话，那弱引用还会被gc吗？那么这个Map中的value是不是一直不会被gc ?????????
在一个线程中创建新线程，当前线程就是新线程的parent Thread，如果当前线程中有InheritableThreadLocal，那么InheritableThreadLocal中的值会被新线程继承，同时可以在重写InheritableThreadLocal的childValue方法，让子线程覆盖父线程的值。
其实InheritableThreadLocal和ThreadLocal一样，每个线程中都threadLocals和inheritableThreadLocals这2个独立的变量，如果在线程中使用ThreadLocal，那么就会创建threadLocals变量，如果在线程中使用InheritableThreadLocal，那么就会创建inheritableThreadLocals变量。只是inheritableThreadLocas可以被子线程继承，同时如果在子线程中再创建新线程的话，inheritableThreadLocals中的值会一直被继承下去。
源码解析：
- ThreadLocal中有一个static类型的AtomicInteger，每new一个ThreadLocal都会增加，这个AtomicInteger决定这个ThreadLocal对象在Thread的ThreadLocalMap中处于什么位置。
- ThreadLocalMap底层用Entry数组实现，Entry继承了WeakReference，WeakReference对象会在GC时会尝试回收。Entry并不是链表形式（HashMap中的Entry是链表，2个Entry是不同的东西）。Entry是对ThreadLocal对象的弱引用，就是说ThreadLocal被jvm判定为weakily reachable就可能会回收掉ThreadLocal对象，这样设计的考虑是在长时间运行的线程中如果有N多个ThreadLocal局部变量存放进了ThreadLocalMap中，这些ThreadLocal对象在一定时间内必须要GC掉，因此设计成弱引用。往Entry数组中set值如果发送hash冲突，ThreadLocalMap是往后（到达最后位置自动跳到0位置继续）自动找Entry中没元素的位置（叫做slot槽位）存放。在get的时候，如果查到的位置的key和当前的ThreadLocal不相等会继续往后找。
- 在getEntry和setEntry的时候会去检查Entry数组中是否有stable Entry，如果有则把对应slot置null，并rehash后面的元素直到一个为null的元素，因我后面不为Null的元素有可能是因为hash冲突放置在后面的slot中，因此需要rehash，而遇到null元素，那么肯定null之后的元素是别的正常元素，不用rehash。
- setEntry
- ThreadLocalMap中的所有操作都没加锁，因为不可能有多线程来操作当前线程中的ThreadLocalMap，当前线程的ThreadLocalMap只对ThreadLocal可见，其他线程通过ThreadLocal只能看到自己的ThreadLocalMap，是看不到其他线程的ThreadLocalMap的。不存在并发问题。
- ThreadLocalMap发生hash冲突，是放到nextIndex的slot中，而不是Entry链表，因为Entry是弱引用，随时可能被GC。
