使用场景
场景1:每个线程需要一个独享的对象(通常是工具类 ,典型需要使用的类有SimpleDateFormat和Random
场景2:每个线程内 需要保存全局变量(例如在拦截器中获取用户信息),可以让不同方法直接使用,避免参数传递 的麻烦
Spring Security获取到Authentication用户信息时也采用到ThreadLocal实现
在SecurityContextHolder
类中有私有的静态变量SecurityContextHolderStrategy strategy
,其实现类为ThreadLocalSecurityContextHolderStrategy
,其中实现类中则创建了一个ThreadLocal的对象来存储对应线程的SecurityContext即用户信息
源码展示
final class ThreadLocalSecurityContextHolderStrategy implements SecurityContextHolderStrategy {
private static final ThreadLocal<SecurityContext> contextHolder = new ThreadLocal<>();
@Override
public void clearContext() {
contextHolder.remove();
}
@Override
public SecurityContext getContext() {
//获取到ThreadLocal中对应的用户信息
SecurityContext ctx = contextHolder.get();
if (ctx == null) {
ctx = createEmptyContext();
contextHolder.set(ctx);
}
return ctx;
}
@Override
public void setContext(SecurityContext context) {
Assert.notNull(context, "Only non-null SecurityContext instances are permitted");
contextHolder.set(context);
}
@Override
public SecurityContext createEmptyContext() {
return new SecurityContextImpl();
}
}
总结
让某个需要用到的对象在线程间隔离(每个线程都有自己的独立的对象)
在任何方法中都可以轻松获取到该对象
好处
达到线程安全
不需要加锁 ,提高执行效率
更有效的利用内存 ,节省开销 :相比每个任务都新建一个实例,显然使用ThreadLocal可以节省内存和开销
免去传参 的繁琐:无论是场景一的工具类,还是场景二的用户名,都可以在任何地方直接通过ThreadLocal拿到,再也不需要每次都传同样的参数。ThreadLocal使得代码耦合度更低更优雅imooc
详解
主要方法介绍
T initialValue() : 初始化
该方法会返回当前线程对应的“初始值”这是一个延迟加载 的方法,只有在调用get 的时候,才会触发
当线程第一次使用get 方法访问变量时,将调用此方法,除非线程先前调用了set方法,在这种情况下,不会为线程调用本initialValue方法
通常,每个线程最多调用一次 此方法,但如果已经调用了remove0后,再调用get0,则可以再次调用此方法
如果不重写本方法,这个方法会返回null。一般使用匿名内部类的方法来重写initialValue() 方法,以便在后续使用中可以初始化副本对象
void set (T t): 为这个线程设置一个新值
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = this.getMap(t);
if (map != null) {
map.set(this, value);
} else {
this.createMap(t, value);
}
}
T get ():得到这个线程对应的value。如果是首次调用get0,则会调用initialize来得到这个值
get方法是先取出当前线程的ThreadLocalMap ,然后调用map.getEntry 方法,把本ThreadLocal的引用作为参数传入 ,取出map中属于本ThreadLocal的value
public T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = this.getMap(t);
if (map != null) {
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
T result = e.value;
return result;
}
}
return this.setInitialValue();
}
void remove (): 删除对应这个线程的值
public void remove() {
ThreadLocalMap m = this.getMap(Thread.currentThread());
if (m != null) {
m.remove(this);
}
}
ThreadLocalMap 类
ThreadLocalMap 类,也就是Thread.threadLocals
ThreadLocalMap 类是每个线程Thread类里面的变量,里面最重要的是一个键值对数组Entryll table,可以认为是一map,键值对
键:这个ThreadLoca
值:实际需要的成员变量 ,比如user或者simpleDateFormat对象
冲突: HashMap
Java8 HashMap 结构
ThreadLocalMap这里采用的是线性探测法,也就是如果发生冲突,就继续找下一个空位置 ,而不是用链表拉链
注意点
内存泄漏
ThreadLocalMap 的每个 Entry 都是一个对key的弱引用,同时每个Entry 都包含了一个对value的强引用
正常情况下,当线程终止,保存在ThreadLocal里的value会被垃圾回收,因为没有任何强引用了
但是,如果线程不终止(比如线程需要保持很久),那么key对应的value就不能被回收,因为有以下的调用链
因为value和Thread之间还存在这个强引用链路,所以导致value无法回收 ,就可能会出现OOM
JDK已经考虑到了这个问题,所以在set, remove,rehash方法中会扫描key为null的Entry,并把对应的value设置为null ,这样value对象就可以被回收
但是如果一个ThreadLocal不被使用,那么实际上set, remove,rehash方法也不会被调用,如果同时线程又不停止,那么调用链就一直存在,那么就导致了value的内存泄漏
共享对象 : 如果在每个线程中ThreadLocal.set0进去的东西本来就是多线程共享的同一个对象,比如如static对象,那么多个线程的ThreadLocal.get0取得的还是这个共享对象本身,还是有并发访问问题
如果可以不使用ThreadLocal就解决问题,那么不要强行使用
例如在任务数很少的时候,在局部变量中可以新建对象就可以解决问题,那么就不需要使用到ThreadLocal
优先使用框架的支持,而不是自己创造
例如在Spring中,如果可以使用RequestContextHolder,那么就不需要自己维护ThreadLocal,因为自己可能会忘记调用remove0方法等,造成内存泄漏
如何避免内存泄漏(阿里规约)
调用remove 方法,就会删除对应的Entity对象,可以避免内存泄漏,所以使用玩ThreadLocal之后,应该调用remove方法
实际应用场景-----在Spring中的实例分析实际应用场景
DateTimeContextHolder 类,看到里面用了ThreadLocal
RequestContextHolder 每次HTTP请求都对应一个线程,线程之间相互隔离,这就是ThreadLocal的典型应用场景