首先ThreadLoacl是什么？之前看有些博客发现会有人这么介绍ThreadLoacl：
它可以解决线程并发问题
它可以解决线程共享数据问题。。。
。。。。
百事不得姐的我决定翻阅源码进行一探究竟！
首先看看怎么用
public class MainActivity extends AppCompatActivity {
ThreadLocal<String> threadLocal = new ThreadLocal<String>(){
@Override
protected String initialValue() {
return "null";
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
for (int i = 0; i < 10; i++) {
new myThread().start();
try {
Thread.sleep(200);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
class myThread extends Thread {
@Override
public void run() {
Log.e(Thread.currentThread().getName(),threadLocal.get());
threadLocal.set(Thread.currentThread().getName());
Log.e(Thread.currentThread().getName(),threadLocal.get());
}
}
}
首先我们创建一个ThreadLocal对象，然后创建十个线程，每个线程将线程名称存储在threadloacl中，然后我们在存储前后打印出来对应的get值，结果如下：
2019-01-02 14:04:25.734 16502-16530/com.lxf.myapplication E/Thread-4: null
2019-01-02 14:04:25.734 16502-16530/com.lxf.myapplication E/Thread-4: Thread-4
2019-01-02 14:04:25.937 16502-16531/com.lxf.myapplication E/Thread-5: null
2019-01-02 14:04:25.937 16502-16531/com.lxf.myapplication E/Thread-5: Thread-5
2019-01-02 14:04:26.137 16502-16532/com.lxf.myapplication E/Thread-6: null
2019-01-02 14:04:26.137 16502-16532/com.lxf.myapplication E/Thread-6: Thread-6
2019-01-02 14:04:26.340 16502-16533/com.lxf.myapplication E/Thread-7: null
2019-01-02 14:04:26.340 16502-16533/com.lxf.myapplication E/Thread-7: Thread-7
2019-01-02 14:04:26.544 16502-16534/com.lxf.myapplication E/Thread-8: null
2019-01-02 14:04:26.544 16502-16534/com.lxf.myapplication E/Thread-8: Thread-8
2019-01-02 14:04:26.744 16502-16535/com.lxf.myapplication E/Thread-9: null
2019-01-02 14:04:26.744 16502-16535/com.lxf.myapplication E/Thread-9: Thread-9
2019-01-02 14:04:26.947 16502-16536/com.lxf.myapplication E/Thread-10: null
2019-01-02 14:04:26.947 16502-16536/com.lxf.myapplication E/Thread-10: Thread-10
2019-01-02 14:04:27.149 16502-16537/com.lxf.myapplication E/Thread-11: null
2019-01-02 14:04:27.149 16502-16537/com.lxf.myapplication E/Thread-11: Thread-11
2019-01-02 14:04:27.350 16502-16538/com.lxf.myapplication E/Thread-12: null
2019-01-02 14:04:27.350 16502-16538/com.lxf.myapplication E/Thread-12: Thread-12
2019-01-02 14:04:27.552 16502-16539/com.lxf.myapplication E/Thread-13: null
2019-01-02 14:04:27.553 16502-16539/com.lxf.myapplication E/Thread-13: Thread-13
结果在我们的预想中
然后我们看一下源码到底是怎么回事
首先我们看一下set方法做了什么事情
public void set(T value) {
//首先去拿一下当前调用的线程
Thread t = Thread.currentThread();
//这里拿到一个ThreadLocalMap
ThreadLocalMap map = getMap(t);
//ThreadLocalMap 不为null的时候将其设置进去
if (map != null)
map.set(this, value);
//否则创建一个map
else
createMap(t, value);
}
这里我们可以看到set的一个流程就是将参数传入的value设置到了一个ThreadLocalMap 中。那么这个ThreadLocalMap 是什么呢？
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
我们发现这里直接返回了当前调用线程的一个变量threadLocals，
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
Thread中我们发现初始值是null
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
然后我们发现在creatMap中初始化了这个变量，默认的第一个键值对就是当前初始化这个变量的 ThreadLocal实例和要外界线程中存入ThreadLocal的值。
ThreadLocalMap是ThreadLocal中的一个内部类，
这里我们发现map中的键值对是存放在一个table数组中的，并且对Entry做了弱引用，这样的话当我们的线程释放之后，内部的ThreadLoacl中的数据也会被回收。以防出现内存泄露的情况！
private Entry[] table;
static class Entry extends WeakReference<ThreadLocal<?>> {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
.....................................................................................................................................
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
这里的map和hashmap 的实现有所不同，ThreadLocal内部维护着一个threadLocalHashCode ，是根据这个threadLocal的threadLocalHashCode 来计算出一个数组的存放索引！这是一个自定义计算出来的hashcode，消除避免了哈希碰撞的情况！所以计算出来的索引都是唯一的！
然后我们看看这个map的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();
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();
}
上面的方法我们可以看到，其实就是做了一系列的判断，判空，替换，数组扩容等操作，本质就是将要存放的value以threadlocal为key存放起来。
然后我们看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();
}
很明了，threadlocal会根据当前调用的线程来获取当前线程中的threadlocalmap，然后从中取出key为该threadlocal的value，这个value就是之前存入的值。
那么通过源码的分析，我们发现threadlocal并不能实现上面的并发问题，因为实际上根本就没有并发相关的问题。存入threadlocal中的数据实际上是存入了对应的调用线程中的内部的一个map中，与threadlocal相关的实际上只是将其作为一个key引用起来，作为取值的凭证而已。同理我们发现threadlocal的做法也并没有实现数据线程间共享的操作，相反是做到了数据的线程间隔离，各个线程只能访问各个线程的数据，做到了线程的数据安全。
实际上我们发现 ThreadLocal可以做到：
1，数据的线程内全局使用，维持了代码的简洁，避免了大量的函数传值
2，做到了线程与线程的数据隔离，使得线程的数据变得安全，不用考虑多个线程操作同一数据造成的并发安全问题。
3，内部使用弱引用解决了可能出现的内存泄露问题。
