ThreadLocal原理分析与代码验证
ThreadLocal提供了线程安全的数据存储和访问方式,利用不带key的get和set方法,居然能做到线程之间隔离,非常神奇。
比如
ThreadLocal<String> threadLocal = new ThreadLocal<>();
in thread 1
//in thread1
treadLocal.set("value1");
.....
//value的值是value1
String value = threadLocal.get();
in thread 2
//in thread2
treadLocal.set("value2");
.....
//value的值是value2
String value = threadLocal.get();
不论thread1和thread2是不是同时执行,都不会有线程安全问题,我们来测试一下。
线程安全测试
开10个线程,每个线程内都对同一个ThreadLocal对象set不同的值,会发现ThreadLocal在每个线程内部get出来的值,只会是自己线程内set进去的值,不会被别的线程影响。
static void testUsage() throws InterruptedException {
Utils.println("-------------testUsage-------------------");
ThreadLocal<Long> threadLocal = new ThreadLocal<>();
AtomicBoolean threadSafe = new AtomicBoolean(true);
int count = 10;
CountDownLatch countDownLatch = new CountDownLatch(count);
Random random = new Random(736832);
for (int i = 0; i < count; i ++){
new Thread(() -> {
try {
//生成一个随机数
Long value = System.nanoTime() + random.nextInt();
threadLocal.set(value);
Thread.sleep(1000);
Long value2 = threadLocal.get();
if (!value.equals(value2)) {
//get和set的value不一致,说明被别的线程修改了,但这是不可能出现的
threadSafe.set(false);
Utils.println("thread unsafe, this could not be happen!");
}
} catch (InterruptedException e) {
}finally {
countDownLatch.countDown();
}
}).start();
}
countDownLatch.await();
Utils.println("all thread done, and threadSafe is " + threadSafe.get());
Utils.println("------------------------------------------");
}
输出:
-------------testUsage------------------
all thread done, and threadSafe is true
-----------------------------------------
原理浅析
翻开ThreadLocal的源码,会发现ThreadLocal只是一个空壳子,它并不存储具体的value,而是利用当前线程(Thread.currentThread())的threadLocalMap来存储value,key就是这个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);
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
Thread的threadLocals字段是ThreadLocalMap类型(你可以简单理解为一个key value的Map),key是ThreadLocal对象,value是我们在外层设置的值
- 当我们调用threadLocal.set(value)方法的时候,会找到当前线程的threadLocals这个map,然后以this作为key去set key value
- 当我们调用threadLocal.get()方法的时候,会找到当前线程的threadLocals这个map,然后以this作为key去get value
- 当我们调用threadLocal.remove()方法的时候,会找到当前线程的threadLocals这个map,然后以this作为key去remove
这就相当于:
Thread.currentThread().threadLocals.set(threadLocal1, "value1");
.....
//value的值是value1
String value = Thread.currentThread().threadLocals.get(threadLocal1);
因为每个Thread都是不同的对象,所以他们的threadLocals也是不同的map,threadLocal在不同的线程里工作时,实际上是从不同的map里get/set,这也就是线程安全的原因了,了解到这一点就差不多了。
再深入一些,ThreadLocalMap的结构
如果继续翻ThreadLocalMap的源码,会发现它有个字段table,是Entry类型的数组。
我们不妨写段代码,把ThreadLocalMap的结构输出出来。
由于Thread.threadLocals和ThreadLocalMap类不是public的,我们只有通过反射来获取它的值。反射的代码如下(如果嫌长可以不看,直接看输出):
static Object getThreadLocalMap(Thread thread) throws NoSuchFieldException, IllegalAccessException {
//get thread.threadLocals
Field threadLocals = Thread.class.getDeclaredField("threadLocals");
threadLocals.setAccessible(true);
return threadLocals.get(thread);
}
static void printThreadLocalMap(Object threadLocalMap) throws NoSuchFieldException, IllegalAccessException {
String threadName = Thread.currentThread().getName();
if(threadLocalMap == null){
Utils.println("threadMap is null, threadName:" + threadName);
return;
}
Utils.println(threadName);
//get threadLocalMap.table
Field tableField = threadLocalMap.getClass().getDeclaredField("table");
tableField.setAccessible(true);
Object[] table = (Object[])tableField.get(threadLocalMap);
Utils.println("----threadLocals (ThreadLocalMap), table.length = " + table.length);
for (int i = 0; i < table.length; i ++){
WeakReference<ThreadLocal<?>> entry = (WeakReference<ThreadLocal<?>>)table[i];
printEntry(entry, i);
}
}
static void printEntry(WeakReference<ThreadLocal<?>> entry, int i) throws NoSuchFieldException, IllegalAccessException {
if(entry == null){
Utils.println("--------table[" + i + "] -> null");
return;
}
ThreadLocal key = entry.get();
//get entry.value
Field valueField = entry.getClass().getDeclaredField("value");
valueField.setAccessible(true);
Object value = valueField.get(entry);
Utils.println("--------table[" + i + "] -> entry key = " + key + ", value = " + value);
}
测试代码:
static void testStructure() throws InterruptedException {
Utils.println("-------------testStructure----------------");
ThreadLocal<String> threadLocal1 = new ThreadLocal<>();
ThreadLocal<String> threadLocal2 = new ThreadLocal<>();
Thread thread1 = new Thread(() -> {
threadLocal1.set("threadLocal1-value");
threadLocal2.set("threadLocal2-value");
try {
Object threadLocalMap = getThreadLocalMap(Thread.currentThread());
printThreadLocalMap(threadLocalMap);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}, "thread1");
thread1.start();
//wait thread1 done
thread1.join();
Thread thread2 = new Thread(() -> {
threadLocal1.set("threadLocal1-value");
try {
Object threadLocalMap = getThreadLocalMap(Thread.currentThread());
printThreadLocalMap(threadLocalMap);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}, "thread2");
thread2.start();
thread2.join();
Utils.println("------------------------------------------");
}
我们在创建了两个ThreadLocal的对象threadLocal1和threadLocal2,在线程1里为这两个对象设置值,在线程2里只为threadLocal1设置值。然后分别打印出这两个线程的threadLocalMap。
输出结果为:
-------------testStructure----------------
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = java.lang.ThreadLocal@33baa315, value = threadLocal2-value
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> null
--------table[9] -> null
--------table[10] -> entry key = java.lang.ThreadLocal@4d42db5c, value = threadLocal1-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
thread2
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> null
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> null
--------table[9] -> null
--------table[10] -> entry key = java.lang.ThreadLocal@4d42db5c, value = threadLocal1-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
------------------------------------------
从结果上可以看出:
- 线程1和线程2的threadLocalMap对象的table字段,是个数组,长度都是16
- 由于线程1里给两个threadLocal对象设置了值,所以线程1的ThreadLocalMap里有两个entry,数组下标分别是1和10,其余的是null(如果你自己写代码验证,下标不一定是1和10,不需要纠结这个问题,只要前后对的上就行)
- 由于线程2里只给一个threadLocal对象设置了值,所以线程1的ThreadLocalMap里只有一个entry,数组下标是10,其余的是null
- threadLocal1这个对象在两个线程里都设置了值,所以当它作为key加入二者的threadLocalMap时,key是一样的,都是java.lang.ThreadLocal@4d42db5c;下标也是一样的,都是10。
为什么是WeakReference
查看Entry的源码,会发现Entry继承自WeakReference:
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
构造函数里把key传给了super,也就是说,ThreadLocalMap中对key的引用,是WeakReference的。
Weak reference objects, which do not prevent their referents from being
made finalizable, finalized, and then reclaimed. Weak references are most
often used to implement canonicalizing mappings.
通俗点解释:
当一个对象仅仅被weak reference(弱引用), 而没有任何其他strong reference(强引用)的时候, 不论当前的内存空间是否足够,当GC运行的时候, 这个对象就会被回收。
看不明白没关系,还是写代码测试一下什么是WeakReference吧...
static void testWeakReference(){
Object obj1 = new Object();
Object obj2 = new Object();
WeakReference<Object> obj1WeakRef = new WeakReference<>(obj1);
WeakReference<Object> obj2WeakRf = new WeakReference<>(obj2);
//obj32StrongRef是强引用
Object obj2StrongRef = obj2;
Utils.println("before gc: obj1WeakRef = " + obj1WeakRef.get() + ", obj2WeakRef = " + obj2WeakRf.get() + ", obj2StrongRef = " + obj2StrongRef);
//把obj1和obj2设为null
obj1 = null;
obj2 = null;
//强制gc
forceGC();
Utils.println("after gc: obj1WeakRef = " + obj1WeakRef.get() + ", obj2WeakRef = " + obj2WeakRf.get() + ", obj2StrongRef = " + obj2StrongRef);
}
结果输出:
before gc: obj1WeakRef = java.lang.Object@4554617c, obj2WeakRef = java.lang.Object@74a14482, obj2StrongRef = java.lang.Object@74a14482
after gc: obj1WeakRef = null, obj2WeakRef = java.lang.Object@74a14482, obj2StrongRef = java.lang.Object@74a14482
从结果上可以看出:
- 我们先new了两个对象(为避免混淆,称他们为Object1和Object2),分别用变量obj1和obj2指向它们,同时定义了一个obj2StrongRef,也指向Object2,最后把obj1和obj2均指向null
- 由于Object1没有变量强引用它了,所以在gc后,Object1被回收了,obj1WeakRef.get()返回了null
- 由于Object2还有obj2StrongRef在引用它,所以gc后,Object2依然存在,没有被回收。
那么,ThreadLocalMap中对key的引用,为什么是WeakReference的呢?
因为大部分情况下,线程不死
大部分情况下,线程不会频繁的创建和销毁,一般都会用线程池。所以线程对象一般不会被清除,线程的threadLocalMap就一直存在。
如果key对ThreadLocal是强引用,那么key永远不会被回收,即使我们程序里再也不用它了。
但是key是弱引用的话,情况就会得到改善:只要没有指向threadLocal的强引用了,这个ThreadLocal对象就会被清理。
我们还是写代码测试一下吧。
/**
* 测试ThreadLocal对象什么时候被回收
* @throws InterruptedException
*/
static void testGC() throws InterruptedException {
Utils.println("-----------------testGC-------------------");
Thread thread1 = new Thread(() -> {
ThreadLocal<String> threadLocal1 = new ThreadLocal<>();
ThreadLocal<String> threadLocal2 = new ThreadLocal<>();
threadLocal1.set("threadLocal1-value");
threadLocal2.set("threadLocal2-value");
try {
Object threadLocalMap = getThreadLocalMap(Thread.currentThread());
Utils.println("print threadLocalMap before gc");
printThreadLocalMap(threadLocalMap);
//set threadLocal1 unreachable
threadLocal1 = null;
forceGC();
Utils.println("print threadLocalMap after gc");
printThreadLocalMap(threadLocalMap);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}, "thread1");
thread1.start();
thread1.join();
Utils.println("------------------------------------------");
}
我们在一个线程里为两个ThreadLocal对象赋值,最后把其中一个对象的强引用移除,gc后打印当前线程的threadLocalMap。
输出结果如下:
-----------------testGC-------------------
print threadLocalMap before gc
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = java.lang.ThreadLocal@7bf9cebf, value = threadLocal2-value
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> null
--------table[9] -> null
--------table[10] -> entry key = java.lang.ThreadLocal@56342d38, value = threadLocal1-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
print threadLocalMap after gc
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = java.lang.ThreadLocal@7bf9cebf, value = threadLocal2-value
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> null
--------table[9] -> null
--------table[10] -> entry key = null, value = threadLocal1-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
------------------------------------------
从输出结果可以看到,当我们把threadLocal1的强引用移除并gc之后,table[10]的key变成了null,说明threadLocal1这个对象被回收了;threadLocal2的强引用还在,所以table[1]的key不是null,没有被回收。
但是你发现没有,table[10]的key虽然是null了,但value还活着! table[10]这个entry对象,也活着!
是的,因为只有key是WeakReference....
无用的entry什么时候被回收?
通过查看ThreadLocal的源码,发现在ThreadLocal对象的get/set/remove方法执行时,都有机会清除掉map中已经无用的entry。
最容易验证清除无用entry的场景分别是:
- remove:这个不用说了,这哥们本来就是做这个的
- get:当一个新的threadLocal对象(没有set过value)发生get调用时,也会作为新的entry加入map,在加入的过程中,有机会清除掉无用的entry,逻辑和下面的set相同。
- set: 当一个新的threadLocal对象(没有set过value)发生set调用时,会在map中加入新的entry,此时有机会清除掉无用的entry,清除的逻辑是:
- 清除掉table数组中的那些无用entry中的一部分,记住是一部分,这个一部分可能全部,也可能是0,具体算法请看ThreadLocalMap.cleanSomeSlots,这里不解释了。
- 如果上一步的"一部分"是0(即清除了0个),并且map的size(是真实size,不是table.length)大于等于threshold(table.length的2/3),会执行一次rehash,在rehash的过程中,清理掉所有无用的entry,并减小size,清理后的size如果还大于等于threshold - threshold/4,则把table扩容为原来的两倍大小。
还有其他场景,但不好验证,这里就不提了。
ThreadLocal源码就不贴了,贴了也讲不明白,相关逻辑在setInitialValue、cleanSomeSlots、expungeStaleEntries、rehash、resize等方法里。
在我们写代码验证entry回收逻辑之前,还需要简单的提一下ThreadLocalMap的hash算法。
entry数组的下标如何确定?
每个ThreadLocal对象,都有一个threadLocalHashCode变量,在加入ThreadLocalMap的时候,根据这个threadLocalHashCode的值,对entry数组的长度取余(hash & (len - 1)),余数作为下标。
那么threadLocalHashCode是怎么计算的呢?看源码:
public class ThreadLocal<T>{
private final int threadLocalHashCode = nextHashCode();
private static AtomicInteger nextHashCode = new AtomicInteger();
private static final int HASH_INCREMENT = 0x61c88647;
private static int nextHashCode() {
return nextHashCode.getAndAdd(HASH_INCREMENT);
}
...
}
ThreadLocal类维护了一个全局静态字段nextHashCode,每new一个ThreadLocal对象,nextHashCode都会递增0x61c88647,作为下一个ThreadLocal对象的threadLocalHashCode。
这个0x61c88647,是个神奇的数字,只要以它为递增值,那么和2的N次方取余时,在有限的次数内不会发生重复。
比如和16取余,那么在16次递增内,不会发生重复。还是写代码验证一下吧。
int hashCode = 0;
int HASH_INCREMENT = 0x61c88647;
int length = 16;
for(int i = 0; i < length ; i ++){
int h = hashCode & (length - 1);
hashCode += HASH_INCREMENT;
System.out.println("h = " + h + ", i = " + i);
}
输出结果为:
h = 0, i = 0
h = 7, i = 1
h = 14, i = 2
h = 5, i = 3
h = 12, i = 4
h = 3, i = 5
h = 10, i = 6
h = 1, i = 7
h = 8, i = 8
h = 15, i = 9
h = 6, i = 10
h = 13, i = 11
h = 4, i = 12
h = 11, i = 13
h = 2, i = 14
h = 9, i = 15
你看,h的值在16次递增内,没有发生重复。 但是要记住,2的N次方作为长度才会有这个效果,这也解释了为什么ThreadLocalMap的entry数组初始长度是16,每次都是2倍的扩容。
验证新threadLocal的get和set时回收部分无效的entry
为了验证出结果,我们需要先给ThreadLocal的nextHashCode重置一个初始值,这样在测试的时候,每个threadLocal的数组下标才会按照我们设计的思路走。
static void resetNextHashCode() throws NoSuchFieldException, IllegalAccessException {
Field nextHashCodeField = ThreadLocal.class.getDeclaredField("nextHashCode");
nextHashCodeField.setAccessible(true);
nextHashCodeField.set(null, new AtomicInteger(1253254570));
}
然后在测试代码里,我们先调用resetNextHashCode方法,然后加两个ThreadLocal对象并set值,gc前把强引用去除,gc后再new两个新的theadLocal对象,分别调用他们的get和set方法。
在每个关键点打印出threadLocalMap做比较。
static void testExpungeSomeEntriesWhenGetOrSet() throws InterruptedException {
Utils.println("----------testExpungeStaleEntries----------");
Thread thread1 = new Thread(() -> {
try {
resetNextHashCode();
//注意,这里必须有两个ThreadLocal,才能验证出threadLocal1被清理
ThreadLocal<String> threadLocal1 = new ThreadLocal<>();
ThreadLocal<String> threadLocal2 = new ThreadLocal<>();
threadLocal1.set("threadLocal1-value");
threadLocal2.set("threadLocal2-value");
Object threadLocalMap = getThreadLocalMap(Thread.currentThread());
//set threadLocal1 unreachable
threadLocal1 = null;
threadLocal2 = null;
forceGC();
Utils.println("print threadLocalMap after gc");
printThreadLocalMap(threadLocalMap);
ThreadLocal<String> newThreadLocal1 = new ThreadLocal<>();
newThreadLocal1.get();
Utils.println("print threadLocalMap after call a new newThreadLocal1.get");
printThreadLocalMap(threadLocalMap);
ThreadLocal<String> newThreadLocal2 = new ThreadLocal<>();
newThreadLocal2.set("newThreadLocal2-value");
Utils.println("print threadLocalMap after call a new newThreadLocal2.set");
printThreadLocalMap(threadLocalMap);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}, "thread1");
thread1.start();
thread1.join();
Utils.println("------------------------------------------");
}
程序输出结果为:
----------testExpungeStaleEntries----------
print threadLocalMap after gc
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = null, value = threadLocal2-value
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> null
--------table[9] -> null
--------table[10] -> entry key = null, value = threadLocal1-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
print threadLocalMap after call a new newThreadLocal1.get
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = null, value = threadLocal2-value
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> entry key = java.lang.ThreadLocal@2b63dc81, value = null
--------table[9] -> null
--------table[10] -> null
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> null
print threadLocalMap after call a new newThreadLocal2.set
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> null
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> null
--------table[7] -> null
--------table[8] -> entry key = java.lang.ThreadLocal@2b63dc81, value = null
--------table[9] -> null
--------table[10] -> null
--------table[11] -> null
--------table[12] -> null
--------table[13] -> null
--------table[14] -> null
--------table[15] -> entry key = java.lang.ThreadLocal@2e93c547, value = newThreadLocal2-value
------------------------------------------
从结果上来看,
- gc后table[1]和table[10]的key变成了null
- new newThreadLocal1.get后,新增了table[8],table[10]被清理了,但table[1]还在(这就是cleanSomeSlots中some的意思)
- new newThreadLocal2.set后,新增了table[15],table[1]被清理了。
验证map的size大于等于table.length的2/3时回收所有无效的entry
static void testExpungeAllEntries() throws InterruptedException {
Utils.println("----------testExpungeStaleEntries----------");
Thread thread1 = new Thread(() -> {
try {
resetNextHashCode();
int threshold = 16 * 2 / 3;
ThreadLocal[] threadLocals = new ThreadLocal[threshold - 1];
for(int i = 0; i < threshold - 1; i ++){
threadLocals[i] = new ThreadLocal<String>();
threadLocals[i].set("threadLocal" + i + "-value");
}
Object threadLocalMap = getThreadLocalMap(Thread.currentThread());
threadLocals[1] = null;
threadLocals[8] = null;
//threadLocals[6] = null;
//threadLocals[4] = null;
//threadLocals[2] = null;
forceGC();
Utils.println("print threadLocalMap after gc");
printThreadLocalMap(threadLocalMap);
ThreadLocal<String> newThreadLocal1 = new ThreadLocal<>();
newThreadLocal1.set("newThreadLocal1-value");
Utils.println("print threadLocalMap after call a new newThreadLocal1.get");
printThreadLocalMap(threadLocalMap);
} catch (NoSuchFieldException | IllegalAccessException e) {
e.printStackTrace();
}
}, "thread1");
thread1.start();
thread1.join();
Utils.println("------------------------------------------");
}
我们先创建了9个threadLocal对象并设置了值,然后去掉了其中2个的强引用(注意这2个可不是随意挑选的)。
gc后再添加一个新的threadLocal,最后打印出最新的map。输出为:
----------testExpungeStaleEntries----------
print threadLocalMap after gc
thread1
----threadLocals (ThreadLocalMap), table.length = 16
--------table[0] -> null
--------table[1] -> entry key = null, value = threadLocal1-value
--------table[2] -> entry key = null, value = threadLocal8-value
--------table[3] -> null
--------table[4] -> entry key = java.lang.ThreadLocal@60523912, value = threadLocal6-value
--------table[5] -> null
--------table[6] -> entry key = java.lang.ThreadLocal@48fccd7a, value = threadLocal4-value
--------table[7] -> null
--------table[8] -> entry key = java.lang.ThreadLocal@188bbe72, value = threadLocal2-value
--------table[9] -> null
--------table[10] -> entry key = java.lang.ThreadLocal@19e0ebe8, value = threadLocal0-value
--------table[11] -> entry key = java.lang.ThreadLocal@688bcb6f, value = threadLocal7-value
--------table[12] -> null
--------table[13] -> entry key = java.lang.ThreadLocal@46324c19, value = threadLocal5-value
--------table[14] -> null
--------table[15] -> entry key = java.lang.ThreadLocal@38f1283, value = threadLocal3-value
print threadLocalMap after call a new newThreadLocal1.get
thread1
----threadLocals (ThreadLocalMap), table.length = 32
--------table[0] -> null
--------table[1] -> null
--------table[2] -> null
--------table[3] -> null
--------table[4] -> null
--------table[5] -> null
--------table[6] -> entry key = java.lang.ThreadLocal@48fccd7a, value = threadLocal4-value
--------table[7] -> null
--------table[8] -> null
--------table[9] -> entry key = java.lang.ThreadLocal@1dae16b1, value = newThreadLocal1-value
--------table[10] -> entry key = java.lang.ThreadLocal@19e0ebe8, value = threadLocal0-value
--------table[11] -> null
--------table[12] -> null
--------table[13] -> entry key = java.lang.ThreadLocal@46324c19, value = threadLocal5-value
--------table[14] -> null
--------table[15] -> null
--------table[16] -> null
--------table[17] -> null
--------table[18] -> null
--------table[19] -> null
--------table[20] -> entry key = java.lang.ThreadLocal@60523912, value = threadLocal6-value
--------table[21] -> null
--------table[22] -> null
--------table[23] -> null
--------table[24] -> entry key = java.lang.ThreadLocal@188bbe72, value = threadLocal2-value
--------table[25] -> null
--------table[26] -> null
--------table[27] -> entry key = java.lang.ThreadLocal@688bcb6f, value = threadLocal7-value
--------table[28] -> null
--------table[29] -> null
--------table[30] -> null
--------table[31] -> entry key = java.lang.ThreadLocal@38f1283, value = threadLocal3-value
------------------------------------------
从结果上看:
- gc后table[1]和table[2](即threadLocal1和threadLocal8)的key变成了null
- 加入新的threadLocal后,table的长度从16变成了32(因为此时的size是8,正好等于10 - 10/4,所以扩容),并且threadLocal1和threadLocal8这两个entry不见了。
如果在gc前,我们把threadLocals[1、8、6、4、2]都去掉强引用,加入新threadLocal后会发现1、8、6、4、2被清除了,但没有扩容,因为此时size是5,小于10-10/4。这个逻辑就不贴测试结果了,你可以取消注释上面代码中相关的逻辑试试。
大部分场景下,ThreadLocal对象的生命周期是和app一致的,弱引用形同虚设
回到现实中。
我们用ThreadLocal的目的,无非是在跨方法调用时更方便的线程安全地存储和使用变量。这就意味着ThreadLocal的生命周期很长,甚至和app是一起存活的,强引用一直在。
既然强引用一直存在,那么弱引用就形同虚设了。
所以在确定不再需要ThreadLocal中的值的情况下,还是老老实实的调用remove方法吧!
代码地址
https://github.com/kongxiangxin/pine/tree/master/threadlocal
ThreadLocal原理分析与代码验证的更多相关文章
- java基础解析系列(七)---ThreadLocal原理分析
java基础解析系列(七)---ThreadLocal原理分析 目录 java基础解析系列(一)---String.StringBuffer.StringBuilder java基础解析系列(二)-- ...
- ThreadLocal原理分析
本文结构 ThreadLocal简介 (简要说明ThreadLocal的作用) ThreadLocal实现原理(说明ThreadLocal的常用方法和原理) ThreadLocalMap的实现 (说明 ...
- Logistic回归分类算法原理分析与代码实现
前言 本文将介绍机器学习分类算法中的Logistic回归分类算法并给出伪代码,Python代码实现. (说明:从本文开始,将接触到最优化算法相关的学习.旨在将这些最优化的算法用于训练出一个非线性的函数 ...
- ThreadLocal原理分析与使用场景
什么是ThreadLocal变量 ThreadLoal 变量,线程局部变量,同一个 ThreadLocal 所包含的对象,在不同的 Thread 中有不同的副本.这里有几点需要注意: 因为每个 Thr ...
- 第七篇:Logistic回归分类算法原理分析与代码实现
前言 本文将介绍机器学习分类算法中的Logistic回归分类算法并给出伪代码,Python代码实现. (说明:从本文开始,将接触到最优化算法相关的学习.旨在将这些最优化的算法用于训练出一个非线性的函数 ...
- IAT Hook 原理分析与代码编写
Ring 3层的 IAT HOOK 和 EAT HOOK 其原理是通过替换IAT表中函数的原始地址从而实现Hook的,与普通的 InlineHook 不太一样 IAT Hook 需要充分理解PE文件的 ...
- Apriori 关联分析算法原理分析与代码实现
前言 想必大家都听过数据挖掘领域那个经典的故事 - "啤酒与尿布" 的故事. 那么,具体是怎么从海量销售信息中挖掘出啤酒和尿布之间的关系呢? 这就是关联分析所要完成的任务了. 本文 ...
- 第一篇:K-近邻分类算法原理分析与代码实现
前言 本文介绍机器学习分类算法中的K-近邻算法并给出伪代码与Python代码实现. 算法原理 首先获取训练集中与目标对象距离最近的k个对象,然后再获取这k个对象的分类标签,求出其中出现频数最大的标签. ...
- 第十四篇:Apriori 关联分析算法原理分析与代码实现
前言 想必大家都听过数据挖掘领域那个经典的故事 - "啤酒与尿布" 的故事. 那么,具体是怎么从海量销售信息中挖掘出啤酒和尿布之间的关系呢? 这就是关联分析所要完成的任务了. 本文 ...
随机推荐
- c++11::std::is_same/decay
#include <type_traits> std::is_same 判断类型是否一致 通过std::is_same即可判断两个类型是否一样,特别在模板里面,在不清楚模板的参数时,此功能 ...
- vue实现跑马灯效果
vue实现跑马灯效果为阿中哥哥应援 1.效果图 2.实现代码 <!DOCTYPE html> <html lang="en"> <head> & ...
- ES和zookeeper选取帮主之江湖秘闻
ES帮会 某日,ES帮会中决定选取老大统领帮会走向辉煌.大家七嘴八舌,讨论方案,场面一顿混乱.傻牛站起来大喊一声:谁比俺力气大,谁就当老大.(ES集群在启动时,选取集群master,按照nodeId进 ...
- Java基础(二十六)Java IO(3)字节流(Byte Stream)
字节流是以字节为单位来处理数据的,由于字节流不会对数据进行任何转换,因此用来处理二进制的数据. 一.InputStream类与OutputStream类 1.InputStream类是所有字节输入流的 ...
- Java基础(十二)lambda表达式
1.引入lambda表达式的重要性 lambda表达式是一个可传递的代码块,可以在以后执行一次或多次. 在前面的回调部分,有一个例子是,ActionListener类实现了TimePrinter接口并 ...
- ARM、X86和AI处理器的区别
ARM.X86和AI处理器的区别 目前主要的处理器架构有: X86: Intel, AMD, 海光, 兆芯 ARM: 华为,飞腾,华芯通,Cavium,Ampere,富士通,亚马逊 POWER:IBM ...
- python小例子(三)
1.提高Python运行速度的方法 (1)使用生成器,节约大量内存: (2)循环代码优化,避免过多重复代码的执行: (3)核心模块使用cpython,pypy等: (4)多进程,多线程,协程: (5) ...
- 使用 Nginx 搭建静态资源 web 服务器
在搭建网站的时候,往往会加载很多的图片,如果都从 Tomcat 服务器来获取静态资源,这样会增加服务器的负载,使得服务器运行 速度非常慢,这时可以使用 Nginx 服务器来加载这些静态资源,这样就可以 ...
- SpringBoot之响应式编程
一 Spring WebFlux Framework说明 Spring WebFlux 是 Spring Framework 5.0 中引入的新 reactive web framework.与 Sp ...
- Jdk14都要出了,还不能使用 Optional优雅的处理空指针?
1. 前言 如果你没有处理过空指针,那么你不是一位真正的 Java 程序员. 空指针确实会产生很多问题,我们经常遇到空的引用,然后又想从这个空的引用上去获取其他的值,接着理所当然的碰到了 NullPo ...