12.ThreadLocal的那点小秘密

简介: 大家好,我是王有志,今天我们来学习ThreadLocal的内容。本文将从源码的角度剖析ThreadLocal,并解答4道高频面试题,同时纠正一个“谣言”。

大家好,我是王有志,欢迎和我聊技术,聊漂泊在外的生活。快来加入我们的Java提桶跑路群:共同富裕的Java人

好久不见,不知道大家新年过得怎么样?有没有痛痛快快得放松?是不是还能收到很多压岁钱?好了,话不多说,我们开始今天的主题:ThreadLocal

我收集了4个面试中出现频率较高的关于ThreadLocal的问题:

  • 什么是ThreadLocal?什么场景下使用ThreadLocal?

  • ThreadLocal的底层是如何实现的?

  • ThreadLocal在什么情况下会出现内存泄漏?

  • 使用ThreadLocal要注意哪些内容?

我们先从一个“谣言”开始,通过分析ThreadLocal的源码,尝试纠正“谣言”带来的误解,并解答上面的问题。

流传已久的“谣言”

很多文章都在说“ThreadLocal通过拷贝共享变量的方式解决并发安全问题”,例如:

图1:谣言.png

这种说法并不准确,很容易让人误解为ThreadLocal会拷贝共享变量。来看个例子:

private static final DateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd");

public static void main(String[] args) throws InterruptedException {
  for (int i = 0; i < 1000; i++) {
    new Thread(() -> {
      try {
        System.out.println(DATE_FORMAT.parse("2023-01-29"));
      } catch (ParseException e) {
        e.printStackTrace();
      }
    }).start();
  }
}

我们知道,多线程并发访问同一个DateFormat实例对象会产生严重的并发安全问题,那么加入ThreadLocal是不是能解决并发安全问题呢?修改下代码:

/**  
 * 第一种写法  
 */
private static final ThreadLocal<DateFormat> DATE_FORMAT_THREAD_LOCAL = new ThreadLocal<>() {
  @Override
  protected DateFormat initialValue() {
    return DATE_FORMAT;
  }
};

public static void main(String[] args) throws InterruptedException {
  for (int i = 0; i < 1000; i++) {
    new Thread(() -> {
      try {
        System.out.println(DATE_FORMAT_THREAD_LOCAL.get().parse("2023-01-29"));
      } catch (ParseException e) {
        e.printStackTrace();
      }
    }).start();
  }
}

估计会有很多小伙伴会说:“你这么写不对!《阿里巴巴Java开发手册》中不是这么用的!”。把书中的用法搬过来:

/**  
 * 第二种写法  
 */
private static final ThreadLocal<DateFormat> DATE_FORMAT_THREAD_LOCAL = new ThreadLocal<>() {
  @Override
  protected DateFormat initialValue() {
    return new SimpleDateFormat("yyyy-MM-dd");
  }
};

Tips:代码小改了一下~~

我们来看两种写法的差别:

  • 第一种写法,ThreadLocal#initialValue时使用共享变量DATE_FORMAT
  • 第二种写法,ThreadLocal#initialValue创建SimpleDateFormat对象

按照“谣言”的描述,第一种写法会拷贝DATE_FORMAT的副本提供给不同的线程使用,但从结果上来看ThreadLocal并没有这么做。

有的小伙伴可能会怀疑是因为DATE_FORMAT_THREAD_LOCAL线程共享导致的,但别忘了第二种写法也是线程共享的。

到这里我们应该能够猜到,第二种写法中每个线程会访问不同的SimpleDateFormat实例对象,接下来我们通过源码一探究竟。

ThreadLocal的实现

除了使用ThreadLocal#initialValue外,还可以通过ThreadLocal#set添加变量后再使用:

ThreadLocal<SimpleDateFormat> threadLocal = new ThreadLocal<>();
threadLocal.set(new SimpleDateFormat("yyyy-MM-dd"));
System.out.println(threadLocal.get().parse("2023-01-29"));

Tips:这么写仅仅是为了展示用法~~

使用ThreadLocal非常简单,3步就可以完成:

  • 创建对象
  • 添加变量
  • 取出变量

无参构造器没什么好说的(空实现),我们从ThreadLocal#set开始。

ThreadLocal#set的实现

ThreadLocal#set的源码:

public void set(T value) {
  Thread t = Thread.currentThread();
  // 获取当前线程的ThreadLocalMap
  ThreadLocalMap map = getMap(t);
  if (map != null) {
    // 添加变量
    map.set(this, value);
  } else {
    // 初始化ThreadLocalMap
    createMap(t, value);
  }
}

ThreadLocal#set的源码非常简单,但却透露出了不少重要的信息:

  • 变量存储在ThreadLocalMap中,且与当前线程有关;

  • ThreadLocalMap应该类似于Map的实现。

接着来看源码:

public class ThreadLocal<T> {
  ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
  }

  void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
  }
}

public class Thread implements Runnable {
  ThreadLocal.ThreadLocalMap threadLocals = null;
}

很清晰的展示出ThreadLocalMap与Thread的关系:ThreadLocalMap是Thread的成员变量,每个Thread实例对象都拥有自己的ThreadLocalMap

另外,还记得在关于线程你必须知道的8个问题(上)提到Thread实例对象与执行线程的关系吗?

如果从Java的层面来看,可以认为创建Thread类的实例对象就完成了线程的创建,而调用Thread.start0可以认为是操作系统层面的线程创建和启动。

可以近似的看作是:$Thread实例对象\approx执行线程$。也就是说,属于Thread实例对象的ThreadLocalMap也属于每个执行线程

基于以上内容,我们好像得到了一个特殊的变量作用域:属于线程

Tips

  • 实际上属于线程也即是属于Thread实例对象,因为Thread是线程在Java中的抽象;

  • ThreadLocalMap属于线程,但不代表存储到ThreadLocalMap的变量属于线程。

ThreadLocalMap的实现

ThreadLocalMap是ThreadLocal的内部类,代码也不复杂:

public class ThreadLocal<T> {

  private final int threadLocalHashCode = nextHashCode();

  static class ThreadLocalMap {

    static class Entry extends WeakReference<ThreadLocal<?>> {
      Object value;
      Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
      }
    }

    private Entry[] table;
    private int size = 0;
    private int threshold;

    private void setThreshold(int len) {
      threshold = len * 2 / 3;
    }

    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);
    }
  }
}

仅从结构和构造方法中已经能够窥探到ThreadLocalMap的特点:

  • ThreadLocalMap底层存储结构是Entry数组;

  • 通过ThreadLocal的哈希值取模定位数组下标;

  • 构造方法添加变量时,存储的是原始变量

很明显,ThreadLocalMap是哈希表的一种实现,ThreadLocal作为Key,我们可以将ThreadLocalMap看做是“简版”的HashMap。

Tips

  • 本文不讨论哈希表实现中处理哈希冲突,数组扩容等问题的方式;

  • 也不需要关注ThreadLocalMap#setThreadLocalMap#getgetEntry的实现;

  • 与构造方法一样,ThreadLocalMap#set中存储的是原始变量

到目前为止,无论是ThreadLocalMap#set还是ThreadLocalMap的构造方法,都是存储原始变量,没有任何拷贝副本的操作。也就是说,想要通过ThreadLocal实现变量在线程间的隔离,就需要手动为每个线程创建自己的变量

ThreadLocal#get的实现

ThreadLocal#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();
}

前面的部分很容易理解,我们看map == null时调用的ThreadLocal#setInitialValue方法:

private T setInitialValue() {
  T value = initialValue();
  Thread t = Thread.currentThread();
  ThreadLocalMap map = getMap(t);
  if (map != null) {
    map.set(this, value);
  } else {
    createMap(t, value);
  }

  if (this instanceof TerminatingThreadLocal) {
    TerminatingThreadLocal.register((TerminatingThreadLocal<?>) this);
  }
  return value;
}

ThreadLocal#setInitialValue方法几乎和ThreadLocal#set一样,但变量是通过ThreadLocal#initialValue获得的。如果是通过ThreadLocal#initialValue添加变量,在第一次调用ThreadLocal#get时将变量存储到ThreadLocalMap中。

ThreadLocal的原理

好了,到这里我们已经可以构建出对ThreadLocal比较完整的认知了。我们先来看ThreadLocal,ThreadLocalMap和Thread三者之间的关系:

图2:ThreadLocal之间的关系.png

可以看到,ThreadLocal是作为ThreadLocalMap中的Key的,而ThreadLocalMap又是Thread中的成员变量,属于每一个Thread实例对象。忘记ThreadLocalMap是ThreadLocal的内部类这层关系,整体结构就会非常清晰。

创建ThreadLocal对象并存储数据时,会为每个Thread对象创建ThreadLocalMap对象并存储数据,ThreadLocal对象作为Key。在每个Thread对象的生命周期内,都可以通过ThreadLocal对象访问到存储的数据。

到底是“谣言”吗?

那么“ThreadLocal通过拷贝共享变量的方式解决并发安全问题”是“谣言”吗?

我认为是的。ThreadLoal不会拷贝共享变量,它能“解决”并发安全问题的原理很简单,要求开发者为每个线程“发”一个变量,即变量本身就是线程隔离的。接近于以下写法:

public static Date parseDate(String dateStr) throws ParseException {
  return new SimpleDateFormat("yyyy-MM-dd").parse(dateStr);
}

那这还能算是ThreadLocal去解决并发安全问题吗?

Tips:Stack Overflow上也有关于“谣言”的讨论

既然不是解决共享变量并发安全问题的,那么ThreadLocal有什么用?我认为最主要的功能就是跳过方法的参数列表在线程内传递参数。举个例子:Dubbo借鉴Netty的FastThreadLocal,搞了InternalThreadLocal,用来隐式传递参数。

ThreadLocal的内存泄漏

在ThreadLocalMap的源码中可以看到,Entry继承自WeakReference,并且会将ThreadLocal添加到弱引用队列中:

static class Entry extends WeakReference<ThreadLocal<?>> {

  Object value;

  Entry(ThreadLocal<?> k, Object v) {
    super(k);
    value = v;
  }
}

我们知道,弱引用关联的对象只能存活到下一次GC。如果ThreadLocal没有关联任何强引用,只有Entry上的弱引用的话,发生一次GC后ThreadLocal就会被回收,就会存在ThreadLocalMap上关联Entry,但Entry上没有Key的情况:

图3:内存泄漏.png

此时Value依旧关联在ThreadLocalMap上,但无法通过常规手段访问,造成内存泄漏。虽然线程销毁后会释放内存,但在线程执行期间,始终有一块无法访问的内存被占用。

避免内存泄漏

为了避免内存泄漏,Java建议设置静态ThreadLocal变量,保证一直存在与之关联的强引用

ThreadLocal instances are typically private static fields in classes.

另外,ThreadLocal自身也做了一些努力去清除这些没有Key的Entry,如:

  • ThreadLocalMap#getEntry调用ThreadLocalMap#getEntryAfterMiss

  • ThreadLocalMap#set调用ThreadLocalMap#replaceStaleEntry

这些方法中都会尝试清除无用的Entry,只是触发条件较为苛刻,实际作用较小。

除此之外,开发者主动调用ThreadLocal#remove清除无用变量才是正确使用ThreadLocal的方式

ThreadLocal的注意事项

除了需要关注ThreadLocal的内存泄漏外,我们需要关注另外一种场景:线程池中使用ThreadLocal

通常线程池不会销毁线程,因此在线程池中使用ThreadLcoal,且没有正确执行ThreadLocal#remove的话,线程中会一直存在ThreadLocal关联的Value,那么就需要考虑清楚,这次的ThreadLocal对下一是否还适用?

结语

ThreadLocal的内容到这里就结束了,使用方法,实现原理,包括内存泄漏都还是比较简单的。不过有一点比较难搞,因为有太多人去写“ThreadLocal通过拷贝共享变量的方式解决并发安全问题”,导致很多人认为这是ThreadLocal的核心功能,所以无法确认坐在对面的面试官是如何理解ThreadLocal的。

我也思考了“谣言”是如何产生的,大概有两点:

第一,《阿里巴巴Java开发手册》中使用ThreadLocal解决了DateFormat的并发安全问题,表现上看是ThreadLocal的能力,实际上是开发者自身保证了每个线程使用不同的DateFormat实例对象

第二,ThreadLocal的注释中,提到了一句“independently initialized copy of the variable.”,搞得大家以为ThreadLocal会拷贝共享变量给线程使用。

如果真的遇到了这样面试官,那只能”见人说人话“了。


好了,今天就到这里了,Bye~~

目录
相关文章
|
3月前
|
存储 设计模式 安全
深入理解ThreadLocal原理
本文深入探讨了Java中的ThreadLocal及其内部数据结构ThreadLocalMap的工作原理和特性,帮助读者理解如何利用ThreadLocal实现线程局部变量的隔离和线程安全。
深入理解ThreadLocal原理
|
3月前
|
存储 算法 安全
掌握Java虚拟机:解锁高效编程的秘密
在Java的世界里,了解虚拟机(JVM)的内部机制是提升编程效率、解决复杂问题的关键。本文将深入浅出地介绍JVM的工作原理,通过实际案例展示如何优化代码,避免常见的陷阱,并利用JVM特性编写更高效的Java程序。无论你是Java新手还是资深开发者,这篇文章都将为你打开一扇通往高效编程的大门。
|
5月前
|
存储 安全 Java
《ThreadLocal使用与学习总结:》史上最详细由浅入深解析ThreadLocal
《ThreadLocal使用与学习总结:》史上最详细由浅入深解析ThreadLocal
43 0
|
6月前
|
设计模式 缓存 Java
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理3
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理
849 1
|
6月前
|
存储 前端开发 Java
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理1
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理
1495 0
|
6月前
|
存储 Java
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理2
从ThreadLocal谈到TransmittableThreadLocal,从使用到原理
596 0
|
存储 设计模式 Java
ThreadLocal的短板,我 TransmittableThreadLocal 来补上!(上)
ThreadLocal的短板,我 TransmittableThreadLocal 来补上!(上)
ThreadLocal的短板,我 TransmittableThreadLocal 来补上!(上)
|
存储 Dubbo Java
12.ThreadLocal的那点小秘密
通常线程池不会销毁线程,因此在线程池中使用ThreadLcoal,且没有正确执行ThreadLocal#remove的话,线程中会一直存在ThreadLocal关联的Value,那么就需要考虑清楚,这次的ThreadLocal对下一是否还适用?
|
存储 消息中间件 JavaScript
ThreadLocal 你真的用不上吗?
ThreadLocal 你真的用不上吗?