ThreadLocal为什么存在内存泄漏，源码分析
文章目录
1. ThreadLocal的使用场景
?
通常，我们使用ThreadLocal有两个目的：
- ①：用来隔离不同线程的变量，避免线程间互相干扰。
- 比如处理登陆信息，每次用户请求都带有用户信息。通常我们都是一个线程处理一个用户请求，所以我们可以把用户信息放到Threadlocal里，让每个线程处理自己的用户信息，线程之间互不干扰。
- Spring用它来管理数据库连接，每个线程获取的都是自己的数据库连接对象。
- ②：使用ThreadLocal来传递数据。
- 比如，一个典型的用户请求需要经过拦截器–>controller–>service–>dao。如果想在这条请求链上传递数据，可以使用参数的方式一直传递下去，但这样做不太优雅。这时就可以使用ThreadLocal来存数据，由于一次请求只会对应一个线程，数据是与线程绑定的 。后续可以再通过ThreadLocal取出数据。
下面是jdk文档对ThreadLocal的描述。
ThreadLocal类提供了线程局部变量，这些变量不同于通常的变量，每个线程访问(通过get/set方法)的都是线程各自独有的变量副本。
ThreadLocal实例通常都是类中私有的静态的(private static)成员变量。这些类希望将状态与线程关联(例如，用户id或事物id)。
例如，下面的类将会为每个线程产生一个独有的标识符(id)。线程id在首次调用ThreadId.get()方法时分配，并且在随后的调用中保持不变。
?
2. 弱引用与内存泄露
首先明确一点的是：Thread类中存在对ThreadLocal的引用
public class Thread implements Runnable {
//每一个线程内部都有一个ThreadLocal.ThreadLocalMap的变量，用来存放当前线程的变量
ThreadLocal.ThreadLocalMap threadLocals = null;
}
???????ThreadLocalMap中Entry节点的定义如下。类上的注释信息已经解释的很清楚了，Entry类继承于WeakReference类，key是ThreadLocal类型。当key为null时，也就是entry.get() == null，意味着key将不再被引用，因此就可以将Entry从table数组中清除了。这样的Entry在后续的代码中被认为是过期失效的Entry。
/**
* Entry类继承于WeakReference，使用其主引用域(中括号中的类类型)作为key(通常总是一个ThreadLocal对象)。
* 注意：key为null(也就是entry.get() == null)意味着key将不再被引用，因此可以将Entry从table数组中清除。
* 这样的Entry在后续的代码中被认为是过期失效的Entry。
*/
static class Entry extends WeakReference<ThreadLocal> {
/**
* The value associated with this ThreadLocal.
*/
Object value;
Entry(ThreadLocal k, Object v) {
super(k);
value = v;
}
}
???????
当调用ThreadLocal.set(value)时，引用关系如下图所示：
???????
需要说明的是，这里的弱引用指的既不是Entry也不是value，而是key，也就是key对ThreadLocal实例存在弱引用。
那么问题来了，为什么要将ThreadLocalMap的key设计为弱引用类型呢？
我们先看看下面的代码:
public class ThreadLocalDemo {
public static void main(String[] args) throws InterruptedException {
print();
……
}
private static void print() {
ThreadLocalWrapper wrapper = new ThreadLocalWrapper();
wrapper.set("hello");
System.out.println(wrapper.get());
}//作用域结束，wrapper实例不再被使用会被gc,其所持有的local也会被gc。
}
class ThreadLocalWrapper {
//1.使用ThreadLocal时通常都会在某个类中。
private ThreadLocal<String> local = new ThreadLocal<>();
public String get() {
return local.get();
}
public void set(String str) {
local.set(str);
}
}
???????正常情况下，上面代码print方法结束后，wrapper作用域结束会被gc，其持有的ThreadLocal实例也就是变量local也理应会被gc（因为有弱引用）。
???????假设key不是弱引用，而是强引用，由于强引用的存在，变量local是不会被gc的。只有等待线程结束，Thread–>ThreadLocalMap–>Entry这条强引用链消失，entry不可达被gc，最终Threadlocal对象也会不可达才会被gc。如果是这样的话，岂不是ThreadLocal对象的回收要看线程的执行时间了，如果线程生命周期较长，比如线程池中的线程，ThreadLocal对象就发生内存泄露了。
???????ThreadLocal的设计者显然要考虑这个问题。线程的执行时间是由开发者的业务决定的，对于threadlocal引用出了作用域范围或者threadlocal=null后ThreadLocal对象的回收这个问题，肯定要在设计层面就解决掉，而不能依赖业务线程的终止，所以设计者就将key设计为弱引用类型。弱引用能保证Threadlocal对象一定活不过下次gc，一定会被回收掉。所以说，将ThreadLocalMap的key设计为弱引用，能在一定程度上防止内存泄露，这里的泄露指的是ThreadLocal对象的泄露。
???????
remove()解决value内存泄露
???????那上面为什么说是一定程度上防止内存泄露，而不是说最终保证不会发生内存泄露？
???????别忘了还有value对象。由于ThreadLocalMap和线程的生命周期是一致的，当线程资源长期不释放，即使ThreadLocal本身由于弱引用机制已经被回收掉了，但还存在Thread-->ThreadLocalMap-->Entry-->value这样的强引用链，value在留存在线程的ThreadLocalMap的Entry中。即存在key为null而value却有值的无效Entry，导致内存泄漏。(由于value只能通过ThreadLocal的set/get/remove方法来访问，当ThreadLocal对象因为弱引用的原因被回收后，value自然也就无法再被访问到，成了无用资源了。)
???????所以，ThreadLocal采取了一定的措施来尽量避免内存泄露的发生。每次调用ThreadLocal的get/set/remove方法时，都会触发执行expungeStaleEntry方法，对失效(key为null)的Entry的做清理工作：擦除Entry(置为null)，同时检测整个Entry数组将key为null的Entry一并擦除，然后重新调整索引。但是，只有在调用这三个方法才会触发清理，而实际上很可能我们在使用完ThreadLocal之后就不再做任何操作了，这样就不会触发ThreadLocal的清理工作。所以，当我们使用完ThreadLocal后，尽量手动调用一下remove方法，尽早地将value清理掉。
public class TenantHolder {
private static final ThreadLocal<Session> CONTEXT = new ThreadLocal<>();
public static void setContext(Session session) {
CONTEXT.set(session);
}
public static Session getContext() {
return CONTEXT.get();
}
//使用完后，手动调用一下这个清除的方法
public static void clear() {
CONTEXT.remove();
}
}
???????
3. 源码分析
???????
①：ThreadLocalMap
ThreadLocal内部使用ThreadLocalMap来持有元素，它是ThreadLocal的核心，我们可以把ThreadLocalMap看做是一个定制化的HashMap。它的数据结构如下图所示。
我们知道HashMap是由数组加链表组成的，但ThreadLocalMap只使用到了数组，并且数组是首尾相连的环形结构，后面会解释原因。
由源码可知，ThreadLocalMap的初始容量为16，负载因子为2/3。
/**
* 初始容量。必须是2的次方。
*/
private static final int INITIAL_CAPACITY = 16;
/**
* table数组，必要时会扩容。数组长度必须是2的次方。
*/
private Entry[] table;
/**
* 数组中元素个数
*/
private int size = 0;
/**
* The next size value at which to resize.
* 下次扩容时使用的容量值。
*/
private int threshold; // Default to 0
/**
* Set the resize threshold to maintain at worst a 2/3 load factor.
* 设置扩容的阈值，以维持负载因子至少为2/3.
*/
private void setThreshold(int len) {
threshold = len * 2 / 3;
}/**
* 构造器。ThreadLocalMap使用的【懒初始化】，当有多个Entry要存放时，只会先创建一个Entry。
*/
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
//初始化table数组
table = new Entry[INITIAL_CAPACITY];
//根据key的hash值定位其在数组中位置
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
//在数组中创建首个节点
table[i] = new Entry(firstKey, firstValue);
//设置初始化元素个数
size = 1;
//设置初始阈值
setThreshold(INITIAL_CAPACITY);
}
ThreadLocalMap使用的懒初始化，当有多个Entry节点要存储时，也只能先通过构造器来先初始化一个Entry节点。而ThreadLocalMap初始化的时机是在ThreadLocal中首次调用set或get方法时。
???????
②：set操作
???????ThreadLocal内部使用ThreadLocalMap来持有元素，它是ThreadLocal的核心，ThreadLocalMap可以看做是一个定制化的HashMap。查看Thread类的源码，可以发现Thread类有一个threaLocals属性，类型为ThreadLocalMap类型，所以可以理解为每个线程都会绑定一个ThreadLocalMap。
public class Thread implements Runnable {
ThreadLocal.ThreadLocalMap threadLocals = null; //本地变量
}
存放数据时，我们会调用ThreadLocal.set(value)方法
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;
}
set方法会先获取当前线程，然后通过getMap获取当前线程绑定的ThreadLocalMap。
- 如果getMap结果非空，则进行保存
- 如果getMap结果为空，说明是第一次调用set方法，需要先实例化ThreadLocalMap。
如果getMap方法返回为空，说明是第一次调用set方法，需要先实例化ThreadLocalMap，前面已经讲过，不再赘述。
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
如果getMap方法返回不为空，将<ThreadLocal实例，value>作为键值对保存到ThreadLocalMap中。 保存的具体步骤是怎么样的呢，我们继续跟踪。set(value)-->set(key, value)
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;
//通过hash定位
int i = key.threadLocalHashCode & (len-1);
//从当前节点开始，往后线性探测
for (Entry e = tab[i];//当前节点
e != null;
e = tab[i = nextIndex(i, len)]) {//下一个探测节点
//探测节点的key
ThreadLocal<?> k = e.get();
//要存入的key与探测节点的key相等，直接覆盖
if (k == key) {
e.value = value;
return;
}
//探测节点key为空，说明被回收了【弱引用原因】
//说明可以使用该位置，用新k-v将其替换。
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
//执行到这里，说明探测到了空位置，可以插入
tab[i] = new Entry(key, value);//创建节点插入
int sz = ++size;
//插入后需要检测一下容量
//先尝试启发式清理，如果无法回收且容量又达到阈值，则需要扩容
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
(1）hash定位
???????首先，使用hash算法来定位到数组的下标，使用的hash算法与上面讲解初始化时一样，不再赘述。
通过hash算法得到的位置，并不一定就是最终value将要存放的位置。ThreadLocalMap同HashMap一样也存在hash冲突问题。
(2）使用线性探测，解决hash冲突
???????我们知道HashMap是使用链地址法来解决hash冲突的，而ThreadLocalMap则是使用的另一种解决hash冲突的方法：开放地址法。所谓的开放定址法就是一旦发生了冲突，就去寻找下一个空的散列地址，只要散列表足够大，空的散列地址总能找到，并将记录存入。
开放地址法可以用公式表示为 ( hash(key) + di ) % m，这里di是个变量，表示每次移动的步数。开放地址法在进行探测时，di有下列几种取法：
- 线性探测再散列：di=1,2,3,……m-1 。这种探测最简单。
- 二次探测再散列：di=21，-21，22，-22，……k2 (k<2/m)
- 随机探测再散列：di取伪随机数列
TheadLocalMap使用的是线性探测法，每次探测都是通过nextIndex()往后挪动一步。如果当前已经是最后一个节点，则探测第一个节点。这就说明了ThreadLocalMap中的数组是环形结构。但这里暂时还不能看出它是一个双向的，需要结合后面的prevIndex方法才能确定，后面再讲。
/**
* Increment i modulo len.
*/
private static int nextIndex(int i, int len) {
//下一个节点的位置。如果当前是最后一个节点，则下一个节点是第一个节点。
return ((i + 1 < len) ? i + 1 : 0);
}
在探测的过程，对探测的节点进行判断
- ①如果探测节点的key与要存入的key相等，则直接覆盖。停止探测。
- ②如果探测节点的key为空，说明由于弱引用的原因被回收了。说明该位置可以重新利用，直接替换掉即可。停止探测。
(3）启发式清理
???????如果上面的两种方式无法找到插入点，就只能找空节点来插入了。一旦遇到了空节点，就停止探测，准备在此处插入。插入前先做一次启发式清理操作。 原因就是，ThreadLocalMap同HashMap一样也是有负载因子的，当到达一定容量后就会进行rehash。rehash毕竟是一个耗性能的操作，应该尽量避免。所以，如果先通过启发式清理，能找到已经失效(key=null)的空间可以重复利用，这样就能避免rehash。
private boolean cleanSomeSlots(int i, int n) {
boolean removed = false;
Entry[] tab = table;
int len = tab.length;
do {
i = nextIndex(i, len);
Entry e = tab[i];
if (e != null && e.get() == null) {
n = len;
removed = true;
i = expungeStaleEntry(i);
}
} while ( (n >>>= 1) != 0);
return removed;
}
private int expungeStaleEntry(int staleSlot) {
Entry[] tab = table;
int len = tab.length;
// expunge entry at staleSlot
//清理失效的节点
tab[staleSlot].value = null; //value设为null
tab[staleSlot] = null; //整个Entry设为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) {//k为null表示引用的对象已经被gc回收了
e.value = null;
tab[i] = null;
size--;
} else {
//hash不相等，说明这个元素之前发生过hash冲突(本应放在这却没放在这)，
//现在因为有元素被移除了，很有可能原来冲突的位置空出来了，重试一次
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;
}
(4）rehash
如果启发式清理没能清理出过期空间(key==null)，而容量又达到了阈值，就只能rehash了。
private void rehash() {
//全量清理
expungeStaleEntries();
// Use lower threshold for doubling to avoid hysteresis
if (size >= threshold - threshold / 4)
//扩容
resize();
}
/**
* 做一次全量清理失效节点的操作
*/
private void expungeStaleEntries() {
Entry[] tab = table;
int len = tab.length;
for (int j = 0; j < len; j++) {
Entry e = tab[j];
if (e != null && e.get() == null)
expungeStaleEntry(j);
}
}
/**
* Double the capacity of the table.
*/
private void resize() {
Entry[] oldTab = table;
int oldLen = oldTab.length;
int newLen = oldLen * 2;//扩容后的容量为原来的2倍。因为要为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;
}
???????
③：get操作
取数据时，我们会调用ThreadLocal.get()方法
public T get() {
// 获取当前线程
Thread t = Thread.currentThread();
// 获取当前线程绑定的ThreadLocalMap
ThreadLocalMap map = getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
// map为空，则自动为其设置一个初始值并返回。
return setInitialValue();
}
ThreadLocalMap getMap(Thread t) {
return t.threadLocals;
}
同样会先获取执行该方法的当前线程，然后再获取该线程绑定的ThreadLocalMap，将当前ThreadLocal实例作为key来获取Map中保存的value值。get()-->getEntry()如下：
/**
* Get the entry associated with key.
* This method itself handles only the fast path: a direct hit of existing key.
* It otherwise relays to getEntryAfterMiss.
* This is designed to maximize performance for direct hits,in part by making this method readily inlinable.
*
* 根据key获取Entry节点。
*/
private Entry getEntry(ThreadLocal key) {
//根据key的hash值定位在数组中位置i
int i = key.threadLocalHashCode & (table.length - 1);
Entry e = table[i];
//找到目标
if (e != null && e.get() == key)
return e;
else
//找不到，则可能是因为碰撞而存到别处了。
return getEntryAfterMiss(key, i, e);
}
/**
* getEntry未直接命中的时候调用此方法
*/
private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {
Entry[] tab = table;
int len = tab.length;
// 向后不断进行线性探测
while (e != null) {
ThreadLocal k = e.get();
//找到目标
if (k == key)
return e;
//key为null，清除失效的Entry
if (k == null)
expungeStaleEntry(i);
else
i = nextIndex(i, len);
//探测下一个
e = tab[i];
}
return null;
}
???????
④：remove操作
public void remove() {
ThreadLocalMap m = getMap(Thread.currentThread());
if (m != null)
m.remove(this);
}
/**
* Remove the entry for key.
*/
private void remove(ThreadLocal<?> key) {
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)]) {
if (e.get() == key) {
//直接将弱引用设为null，断开对对象的引用。
e.clear();
//清理无效节点
expungeStaleEntry(i);
return;
}
}
}
???????
4. 继承性 InheritableThreadLocal
???????在一些场景中，子线程需要可以获取父线程的本地变量，比如子线程要获取父线程中保存的用户的信息，或者使用一个统一的traceId来进行链路追踪。但是ThreadLocal不支持继承性，即子线程无法从父线程中获取父线程的本地变量。原因很简单，因为操作ThreadLocal时每次都是获取的当前线程。因此，JDK提供了InheritableThreadLocal来解决继承性问题。
???????InheritableThreadLocal 继承了ThreadLocal，并且重写了createMap等三个方法。当首次调用set方法时，创建的是当前线程的inheritableThreadLocals变量，而不再是threadLocals。同样在调用get方法时，获取当前线程的内部map时，获取的是inheritableThreadLocals而不再是threadLocals。总的来说，在InheritableThreadLocal中，变量inheritableThreadLocals替代了threadLocals。
???????当父线程创建子线程时，构造函数会将父线程中的inheritableThreadLocals变量里的本地变量赋值到子线程的inheritableThreadLocals里面。
// new Thread()-->init()
init(){
……
//如果父线程inheritableThreadLocals变量不为null
if (inheritThreadLocals && parent.inheritableThreadLocals != null)
//设置子线程中的inheritableThreadLocals变量
this.inheritableThreadLocals =ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
……
}
static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
return new ThreadLocalMap(parentMap);
}
使用案例：
public class TenantRecordContext {
public static final InheritableThreadLocal<String> USER_INFO_CONTEXT = new InheritableThreadLocal<>();
public static void setUserInfo(String sid) {
USER_INFO_CONTEXT.set(sid);
}
public static String getUserInfo() {
return USER_INFO_CONTEXT.get();
}
public static void clearUserInfo() {
USER_INFO_CONTEXT.remove();
}
}
???????
5. 各类ThreadLocal问题总结
???????
1. ThreadLocal的作用？
主要解决线程变量隔离问题。在实际使用中，我们有两种典型用法
用来隔离线程变量。比如在数据库连接池中，可以将数据库连接Connection对象放在ThreadLocal中，每个线程获取各自的数据库连接，线程间不会互相干扰。
用来在同一个线程的调用链中传递数据。
2. ThreadLocal的工作原理？(如何实现线程变量隔离的？)hash冲突解决方法？
工作原理略。每个线程都持有了一个线程本地变量，每个线程只操作自己的线程本地变量，线程间避免了相互干扰。
ThreadLocal使用开发地址法中的线性探测来解决hash冲突。
3. ThreadLocalMap为什么要定义在ThreadLocal中，而不是Thread中？
??????? Thread类有个ThreadlocalMap类型的成员变量，但ThreadlocalMap的定义却在Threadlocal中。将ThreadLocalMap定义在Thread中似乎看起来更符合逻辑，但是实际上并不需要在Thread中操作ThreadLocalMap，定义在Thread类中只会增加一些不必要的开销。 定义在ThreadLocal类中的原因是ThreadLocal类负责ThreadLocalMap的创建，仅当线程中设置第一个ThreadLocal时，才为当前线程创建ThreadLocalMap，之后所有其他ThreadLocal变量将使用一个ThreadLocalMap。
???????总的来说就是，ThreadLocalMap不是必需品，定义在Thread中增加了成本，定义在ThreadLocal中按需创建。
4. 既然是线程局部变量，那为什么不用线程(Thread)对象作为key，获取变量时通过线程作为key来获取，这样不是更清晰？
这样设计就存在数据覆盖的问题。如果用线程对象作为key，假设已经存入了用户信息，存入<线程，用户信息>。这时需要新增加用户地理位置信息，需要存入<线程，用户地理信息>。由于key都是同一个线程，不就覆盖了嘛。
5. 那使用ThreadLocal新增信息应该怎么做呢？
为当前线程再绑定一个Threadlocal对象不就好了。比如已经存入了用户信息，要新增加用户的地理信息，如下：
Threadlocal<Geo> geo = new Threadlocal<> ();
geo.set(地理信息);
这样线程的
ThreadlocalMap里面就会有二个元素，一个是用户信息，一个是地理位置。（一个线程绑定一个ThreadLocalMap，一个ThreadLocalMap存多个ThreadLocal实例。）
6. 如果有多个变量都要塞到ThreadlocalMap中，那岂不是要申明多个Threadlocal 对象？有没有好的解决办法。
- 可以再封装一下，把这些变量打包成一个Map不就好了，整个Map作为value存入，这样就只需要一个Threadlocal 对象。
7. 为什么ThreadLocalMap中key被设计成弱引用类型？
key
设计为弱引用是为了尽最大努力避免内存泄漏，解决的是ThreadLocal对象的内存泄露问题。
?
ThreadLocal的设计者考虑到了某些线程的生命周期较长，比如线程池中的线程。由于存在Thread -> ThreadLocalMap -> Entry这样一条强引用链，如果key不设计成弱引用类型，是强引用的话，key就一直不会被GC回收，一直不会是null，Entry就不会被清理。
?
(ThreadLocalMap根据key是否为null来判断是否清理Entry。因为key为null时，引用的ThreadLocal实例不可达会被回收。value又只能通过ThreadLocal的方法来访问，此时相当于value也没用处了。所以，可以根据key是否为null来判断是否清理Entry。)
8. ThreadLocal内存泄露的原因？要如何避免？
弱引用解决的是ThreadLocal对象的内存泄露问题，但value还存在内存泄露的风险。
?
内存泄露的原因：
?
- 由于ThreadLocalMap和线程的生命周期是一致的，当线程资源长期不释放，
即使ThreadLocal本身由于弱引用机制已经被回收掉了，但value还是驻留在线程的ThreadLocalMap的Entry中。即存在key为null，但value却有值的无效Entry，导致内存泄漏。?
ThreadLocal自身采取的措施：
?
- 但实际上，ThreadLocal内部已经为我们做了一定的防止内存泄漏的工作。ThreadLocalMap提供了一个expungeStaleEntry方法，该方法在
每次调用ThreadLocal的get、set、remove方法时都会执行清理工作，即ThreadLocal内部已经帮我们做了对key为null的Entry的清理工作：擦除Entry(置为null)，同时检测整个Entry数组将key为null的Entry一并擦除，然后重新调整索引。?
但是必须需要调用这三个方法才会触发清理，很可能我们使用完之后就不再做任何操作了(set/get/remove)，这样就不会触发内部的清理工作。
开发人员需要注意： 所以，通常建议每次使用完ThreadLocal后，立即调用remove方法。
9. 为什么使用ThreadLocal时通常定义为static?
ThreadLocal 对象建议使用 static 修饰。这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享
此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只 要是这个线程内定义的)都可以操控这个变量。
10. ThreadLocal继承性问题？如何解决？
ThreadLocal不支持子线程继承，可以使用JDK中的InheritableThreadLocal来解决继承性问题。对于线程池等场景，可以使用淘宝技术部哲良实现的TransmittableThreadLocal
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：chenni525@qq.com进行投诉反馈，一经查实，立即删除！
- Python教程
- 深入理解 MySQL 中的 HAVING 关键字和聚合函数
- Qt之QChar编码（1）
- MyBatis入门基础篇
- 用Python脚本实现FFmpeg批量转换
- 微服务技术要点
- CHAPTER 15: 《DESIGN GOOGLE DRIVE》第15章:《设计谷歌驱动器》
- 数据采集与预处理02 ：网络爬虫实战
- AI Native工程化：百度App AI互动技术实践
- 竞赛保研 LSTM的预测算法 - 股票预测 天气预测 房价预测
- Linux——环境变量与本地变量
- 如何使用TrafficWatch根据PCAP文件监控和分析网络流量
- 一文读懂实验室信息学
- 【机器学习：异常值检测】新颖性和异常值检测
- vue 集成行政区域选择插件region和数据回显