本次给大家介绍重要的工具ThreadLocal。讲解内容如下，同时介绍什么场景下发生内存泄漏，如何复现内存泄漏，如何正确使用它来避免内存泄漏。
带着问题，我们一起来看看，如果你有什么见解，可以评论分享哈。
-
ThreadLocal是什么？有哪些用途？
-
ThreadLocal如何使用。
-
ThreadLocal原理。
-
ThreadLocal使用有哪些坑及注意事项。
1. ThreadLocal是什么？ 有哪些用途？
首先介绍Thread类中属性threadLocals: 我是这样理解的，他放在Thread，那是不是和线程有关联，什么关联，猜想共享，私有？
ThreadLocal.ThreadLocalMap threadLocals = null;看到源码，了解到是每个线程的实例 threadLocals
但是我们看没有操作threadLocals的方法，这个是个threadLocal就上场了，可以理解threadLocal是线程Thread中属性threadLocals的管理者。
也就是，我们操作threadLocal的get,set,remove的操作结果都是针对当前线程Thread实例的threadLocals存，取，删除操作。类次于一个开发者的任务，产品经理左右不了，产品经理只能通过技术leader来给开发者分配任务。
其实，我们看看threadLocal的源码，底层就是threadLocalMap组成，这不匹配上了 。
要了解到这个threadLocal的分配空间。
那ThreadLocal有哪些应用场景呢？
其实我们无意间已经时时刻刻在使用ThreadLocal提供的便利，如果说多数据源的切换你比较陌生，那么spring提供的声明式事务就再熟悉不过了，我们在研发过程中无时无刻不在使用，而spring声明式事务的重要实现基础就是ThreadLocal，只不过大家没有去深入研究spring声明式事务的实现机制。
原来ThreadLocal这么强大，但应用开发者使用较少，同时有些研发人员对于ThreadLocal内存泄漏，等潜在问题，不敢试用，恐怕这是对于ThreadLocal最大的误解，后面我们将会仔细分析，只要按照正确使用方式，就没什么问题。如果ThreadLocal存在问题，岂不是spring声明式事务是我们程序最大的潜在危险吗？
兄弟们，编程，先学习思想，但是发现，我了解一个ThreadLocal，里面涉及很多的知识点，这里就冒出了spring声明式事务的原理及实现机制，记在心思，可以自己学习，后面我也分我学习的。
2.ThreadLocal如何使用
为了更直观的体会ThreadLocal的使用我们假设如下场景
-
我们给每个线程生成一个ID。
-
一旦设置，线程生命周期内不可变化。
-
容器活动期间不可以生成重复的ID
我们创建一个ThreadLocal管理类：
package demo.aqs;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
public class ThreadLocalId {
private static final AtomicInteger nextId = new AtomicInteger(0);
private static final ThreadLocal<Integer> threadId = new ThreadLocal<Integer>() {
protected Integer initialValue()
{
return nextId.getAndIncrement();
}
};
public static int get() {
return threadId.get();
}
public static void remove() {
threadId.remove();
}
private static void increamentSameThreadId() {
try{
for(int i = 0;i < 5; i++) {
System.out.println(Thread.currentThread()+"_"+i+",threadId:"+ThreadLocalId.get());
}
} finally {
ThreadLocalId.remove();
}
}
public static void main(String[] args) {
increamentSameThreadId();
//在搞2个线程
new Thread(new Runnable() {
@Override
public void run() {
increamentSameThreadId();
}
}).start();
new Thread(()->{
increamentSameThreadId();
}).start();
}
}
3.ThreadLocal原理
①ThreadLocal类结构及方法解析：
上图可知：ThreadLocal三个方法get, set , remove以及内部类ThreadLocalMap
从这张图我们可以直观的看到Thread中属性threadLocals，作为一个特殊的Map，它的key值就是我们ThreadLocal实例，而value值这是我们设置的值。
③ThreadLocal的操作过程：
其中getMap(t) 返回的就是当前线程的threadlocals,如下图，然后根据当前ThreadLocal实例对象作为key获取ThreadLocalMap中的value,如果首次进来调用setInitialValue();
set的过程也类似:
4.ThreadLocal使用有哪些坑及注意事项
我经常在网上看到骇人听闻的标题，ThreadLocal导致内存泄漏，这通常让一些刚开始对ThreadLocal理解不透彻的开发者，不敢贸然使用。越不用，越陌生。这样就让我们错失了更好的实现方案，所以敢于引入新技术，敢于踩坑，才能不断进步。
我们来看下为什么说ThreadLocal会引起内存泄漏，什么场景下会导致内存泄漏？
先回顾下什么叫内存泄漏，对应的什么叫内存溢出
-
Memory overflow:内存溢出，没有足够的内存提供申请者使用。
-
Memory leak:内存泄漏，程序申请内存后，无法释放已申请的内存空间，内存泄漏的堆积终将导致内存溢出。
显然是TreadLocal在不规范使用的情况下导致了内存没有释放。
看到ThreadLocalMap的Entry继承了WeakReference（弱引用）
知识点来了：
既然WeakReference在下一次gc即将被回收，那么我们的程序为什么没有出问题呢？
①所以我们测试下弱引用的回收机制：
package demo; import java.lang.ref.WeakReference; /** * 弱引用测试 */ public class ThreadLocalLeakTest { public static void main(String[] args) { String str = new String("weakReference1"); //弱应用回收 WeakReference<String> weakReference = new WeakReference<String>(str); System.gc(); if(weakReference.get() == null) { System.out.println("weak1已被回收"); } else { System.out.println(weakReference.get()); } //存在强引用 WeakReference<String> weakReference2 = new WeakReference<String>(new String("weakReference1")); System.gc(); if(weakReference2.get() == null) { System.out.println("weak2已被回收"); } else { System.out.println(weakReference2.get()); } } }
weakReference1
weak2已被回收
上面演示了弱引用的回收情况，下面我们看下ThreadLocal的弱引用回收情况。
②ThreadLocal的弱引用回收情况
如上图所示，我们在作为key的ThreadLocal对象没有外部强引用，下一次gc必将产生key值为null的数据，若线程没有及时结束必然出现，一条强引用链Threadref–>Thread–>ThreadLocalMap–>Entry，所以这将导致内存泄漏。
下面我们模拟复现ThreadLocal导致内存泄漏：
package com.example.demo.threadLoclLeak;
import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.List;
import org.springframework.util.ReflectionUtils;
public class TestThreadLoclLeak {
public static void main(String[] args) throws InterruptedException {
// 为了复现key被回收的场景，我们使用临时变量
ThreadLocalMemory memeory = new ThreadLocalMemory();
// 调用
incrementSameThreadId(memeory);
System.out.println("GC前：key:" + memeory.threadId);
System.out.println("GC前：value-size:" + refelectThreadLocals(Thread.currentThread()));
// 设置为null，调用gc并不一定触发垃圾回收，但是可以通过java提供的一些工具进行手工触发gc回收。
memeory.threadId = null;
System.gc();
System.out.println("GC后：key:" + memeory.threadId);
System.out.println("GC后：value-size:" + refelectThreadLocals(Thread.currentThread()));
// 进一步回收，保证ThreadLocal实例被回收
memeory = null;
System.gc();
// 模拟线程一直运行
while (true) {
}
}
/**
* 使用threadlocal
*
* @param memeory
*/
private static void incrementSameThreadId(final ThreadLocalMemory memeory) {
try {
for (int i = 0; i < 5; i++) {
System.out.println(Thread.currentThread() + "_" + i + ",threadId:" + memeory.get().size());
}
} finally {
// 使用后请清除，这里为了复现内存泄漏，故意不回收
// ThreadLocalMemory.remove();
}
}
/**
* 利用反射获取ThreadLocal对应的值
*
* @param t
* @return
*/
public static Object refelectThreadLocals(Thread t) {
try {
// Thread
Field field = ReflectionUtils.findField(Thread.class, "threadLocals");
field.setAccessible(true);
Object localmap = ReflectionUtils.getField(field, t);
// ThreadLocalMap.Entry[]
Field entryField = ReflectionUtils.findField(localmap.getClass(), "table");
entryField.setAccessible(true);
Object[] entry = (Object[]) ReflectionUtils.getField(entryField, localmap);
List<Object> list = new ArrayList<>();
for (Object o : entry) {
if (o != null)
list.add(o);
}
List<Object> result = new ArrayList<>();
for (Object o : list) {
// Entry.value
Field entryValue = ReflectionUtils.findField(o.getClass(), "value");
entryValue.setAccessible(true);
Object keyvalue = ReflectionUtils.getField(entryValue, o);
if (keyvalue instanceof ArrayList) {
result.add(keyvalue);
}
}
return ((ArrayList<?>) result.get(0)).size();
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
class ThreadLocalMemory {
// Thread local variable containing each thread's ID
public ThreadLocal<List<Object>> threadId = new ThreadLocal<List<Object>>() {
@Override
protected List<Object> initialValue() {
List<Object> list = new ArrayList<Object>();
for (int i = 0; i < 10000; i++) {
list.add(String.valueOf(i));
}
return list;
}
};
// Returns the current thread's unique ID, assigning it if necessary
public List<Object> get() {
return threadId.get();
}
// remove currentid
public void remove() {
threadId.remove();
}
}此时我们如何知道内存中存在memory leak呢？
我们可以借助jdk提供的一些命令dump当前堆内存，命令如下：
jmap -dump:live,format=b,file=heap.bin <pid>
然后我们借助MAT可视化分析工具，来查看对内存，分析对象实例的存活状态：
首先打开我们工具提示我们的内存泄漏分析：
这里我们可以确定的是ThreadLocalMap实例的Entry.value是没有被回收的。
最后我们要确定Entry.key是否还在？打开Dominator Tree，搜索我们的ThreadLocalMemory，发现并没有存活的实例。
以上我们复现了ThreadLocal不正当使用，引起的内存泄漏。
所以我们总结了使用ThreadLocal时会发生内存泄漏的前提条件
-
ThreadLocal引用被设置为null，且后面没有set，get,remove操作。
-
线程一直运行，不停止。（线程池）
-
触发了垃圾回收。（Minor GC或Full GC）
我们看到ThreadLocal出现内存泄漏条件还是很苛刻的，所以我们只要破坏其中一个条件就可以避免内存泄漏，单但为了更好的避免这种情况的发生我们使用ThreadLocal时遵守以下两个小原则:
①ThreadLocal申明为private static final。
-
Private与final 尽可能不让他人修改变更引用，
-
Static 表示为类属性，只有在程序结束才会被回收。
②ThreadLocal使用后务必调用remove方法。
-
最简单有效的方法是使用后将其移除。
以上。
2418
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
