ThreadLocal和Synchonized都用语解决多线程并发访问的，可以ThreadLocal与Synchonzied有本质的差别，synchoronized是利用锁的机制，使变量或代码块仅仅能被一个线程访问。而ThreadLoacal为每个线程都提供了变量的副本，使得每个线程在某个时间访问到，这样对线程间的数据进行了隔离。
public class Thread implements Runnable {
ThreadLocal.ThreadLocalMap threadLocals = null;
}
public class ThreadLocal<T> {
static class ThreadLocalMap {
/**
* The entries in this hash map extend WeakReference, using
* its main ref field as the key (which is always a
* ThreadLocal object). Note that null keys (i.e. entry.get()
* == null) mean that the key is no longer referenced, so the
* entry can be expunged from table. Such entries are referred to
* as "stale entries" in the code that follows.
*/
static class Entry extends WeakReference<java.lang.ThreadLocal<?>> {
/**
* The value associated with this ThreadLocal.
*/
Object value;
Entry(java.lang.ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
}
}
可以看出ThreadLocalMap类是ThreadLocal类的静态内部类，而Entry是ThreadLocalMap的静态内部类，key是ThreadLocal（声明为弱引用），value是Object，也就是我们要存的值。
ThreadLocal的使用
设置当前线程的线程局部变量的值：
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); }
返回当前线程所对应的线程局部变量：
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(); }
将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它可以加快内存回收的速度。
public void remove() { ThreadLocalMap m = getMap(Thread.currentThread()); if (m != null) m.remove(this); }
hash冲突怎么解决？
与Hashmap不同，ThreadLocal用的是一种线性探测的方式处理，根据hashcode值确定元素在table数组中的位置，如果发现这个位置已经有其他元素和位置冲突就存放下一个为空的位置。
/** * Set the value associated with key. * * @param key the thread local object * @param value the value to be set */ private void set(ThreadLocal<?> key, Object value) { // We don't use a fast path as with get() because it is at // least as common to use set() to create new entries as // it is to replace existing ones, in which case, a fast // path would fail more often than not. 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(); if (k == key) { e.value = value; return; } if (k == null) { replaceStaleEntry(key, value, i); return; } } tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); }
扩容操作？
当数据超过阈值的四分之三时，扩容2倍，阈值设置为长度的三分之二。
/** * Re-pack and/or re-size the table. First scan the entire * table removing stale entries. If this doesn't sufficiently * shrink the size of the table, double the table size. */ private void rehash() { expungeStaleEntries(); // Use lower threshold for doubling to avoid hysteresis if (size >= threshold - threshold / 4) resize(); } /** * Double the capacity of the table. */ private void resize() { Entry[] oldTab = table; int oldLen = oldTab.length; int newLen = oldLen * 2; Entry[] newTab = new Entry[newLen]; int count = 0; for (int j = 0; j < oldLen; ++j) { Entry e = oldTab[j]; if (e != null) { ThreadLocal<?> k = e.get(); if (k == null) { e.value = null; // Help the GC } else { int h = k.threadLocalHashCode & (newLen - 1); while (newTab[h] != null) h = nextIndex(h, newLen); newTab[h] = e; count++; } } } setThreshold(newLen); size = count; table = newTab; } /** * Set the resize threshold to maintain at worst a 2/3 load factor. */ private void setThreshold(int len) { threshold = len * 2 / 3; }
引发的内存泄露分析
我们可以知道每个Thread 维护一个 ThreadLocalMap，这个映射表的 key是ThreadLocal实例本身，value 是真正需要存储的 Object，也就是说 ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从ThreadLocalMap获取value
图中的虚线表示弱引用。 这样，当把threadlocal变量置为null以后，没有任何强引用指向threadlocal实例，所以threadlocal将会被gc回收。这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而这块value永远不会被访问到了，所以存在着内存泄露。
只有当前thread结束以后，current thread就不会存在栈中，强引用断开，Current Thread、Map value将全部被GC回收。最好的做法是不在需要使用ThreadLocal变量后，都调用它的remove()方法，清除数据。 调用remove()方法最佳时机是线程运行结束之前的finally代码块中调用，这样能完全避免操作不当导致的内存泄漏，这种主动清理的方式比惰性删除有效。
private int expungeStaleEntry(int staleSlot) { Entry[] tab = table; int len = tab.length; // expunge entry at staleSlot tab[staleSlot].value = null; tab[staleSlot] = null; size--; // Rehash until we encounter null Entry e; int i; for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) { ThreadLocal<?> k = e.get(); if (k == null) { e.value = null; tab[i] = null; size--; } else { int h = k.threadLocalHashCode & (len - 1); if (h != i) { tab[i] = null; // Unlike Knuth 6.4 Algorithm R, we must scan until // null because multiple entries could have been stale. while (tab[h] != null) h = nextIndex(h, len); tab[h] = e; } } } return i; }
这个方法在ThreadLocal的set、get、remove时都会被调用，从上面代码中，可以看出先清理指定的Entry，再遍历，如果发现有Entry的key为null，就清理。Key==null，也就是ThreadLocal对象是null。所以当程序中，将ThreadLocal对象设置为null，在该线程继续执行时，如果执行另一个ThreadLocal时，就会触发该方法。就有可能清理掉Key是null的那个ThreadLocal对应的值。所以说expungStaleEntry()方法清除线程ThreadLocalMap里面所有key为null的value。
在ThreadLocal的实现，我们可以看见，无论是get()、set()在某些时候，调用了expungeStaleEntry方法用来清除Entry中Key为null的Value，但是这是不及时的，也不是每次都会执行的，所以一些情况下还是会发生内存泄露。只有remove()方法中显式调用了expungeStaleEntry方法。
由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal的对象实例也会被回收。value在下一次ThreadLocalMap调用set，get，remove都有机会被回收。所以说jvm利用弱引用来避免内存泄露，通过remove方法回收弱引用。
小结
key 使用强引用：引用ThreadLocal的对象被回收了，但是ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal的对象实例不会被回收，导致Entry内存泄漏。key 使用弱引用：引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal的对象实例也会被回收。value在下一次ThreadLocalMap调用set，get，remove都有机会被回收
使用线程池+ ThreadLocal时要小心，因为这种情况下，线程是一直在不断的重复运行的，如果没有及时的清理，那么之前对该线程的使用，就会影响到后面的线程了，从而也就造成了value可能造成累积的情况，所以要调用remove()方法及时清除来解决。
错误使用ThreadLocal导致线程不安全
public class ThreadLocalUnsafe implements Runnable {
public static Number number = new Number(0);
public static ThreadLocal<Number> value = new ThreadLocal<>();
@SneakyThrows
public void run() {
number.setNum(number.getNum() + 1);
value.set(number);
Thread.sleep(40);
System.out.println(Thread.currentThread().getName() + " = " + value.get());
}
public static void main(String[] args) {
for (int i = 0; i < 5; i++) {
new Thread(new ThreadLocalUnsafe()).start();
}
}
}
class Number{
private int num;
public Number(int num) {
this.num = num;
}
public int getNum() {
return num;
}
public void setNum(int num) {
this.num = num;
}
@Override
public String toString() {
return "Number{" +
"num=" + num +
'}';
}
}
输出：
Thread-0 = Number{num=5}
Thread-2 = Number{num=5}
Thread-4 = Number{num=5}
Thread-3 = Number{num=5}
Thread-1 = Number{num=5}
代码中的数据会发生线程不安全的现象，不同线程之间可以修改同一个值，static修饰的类在JVM中只保存一个实例对象，ThreadLocalMap中保存的其实是对象的一个引用，这样的话，当有其他线程对这个引用指向的对象实例做修改时，其实也同时影响了所有的线程持有的对象引用所指向的同一个对象实例，这样的话会导致每个线程输出的内容一致，而上面的程序要正常的工作，应该的用法是让每个线程中的ThreadLocal都应该持有一个新的Number对象。
总结
ThreadLocal是解决线程安全的一个很好的思路，它通过为每个线程提供了一个独立的变量副本解决了额变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。ThreadLocal和synchronize用一句话总结就是一个用存储拷贝进行空间换时间，一个是用锁机制进行时间换空间。