深入JDK源码之ThreadLocal类.docVIP

深入JDK源码之ThreadLocal类 学习JDK中的类，首先看下JDK API对此类的描述，描述如下： 该类提供了线程局部 (thread-local) 变量。这些变量不同于它们的普通对应物，因为访问某个变量（通过其 get 或 set 方法）的每个线程都有自己的局部变量，它独立于变量的初始化副本。ThreadLocal其实就是一个工具类，用来操作线程局部变量，ThreadLocal 实例通常是类中的 private static 字段。它们希望将状态与某一个线程（例如，用户 ID 或事务 ID）相关联。 例如，以下类生成对每个线程唯一的局部标识符。线程 ID 是在第一次调用UniqueThreadIdGenerator.getCurrentThreadId()时分配的，在后续调用中不会更改。 其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，而是threadlocalvariable(线程局部变量)。也许把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)其实的功用非常简单，就是为每一个使用该变量的线程都提供一个变量值的副本，是Java中一种较为特殊的线程绑定机制，是每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。 import java.util.concurrent.atomic.AtomicInteger; public class UniqueThreadIdGenerator { private static final AtomicInteger uniqueId = new AtomicInteger(0); private static final ThreadLocal Integer uniqueNum = new ThreadLocal Integer () { @Override protected Integer initialValue() { return uniqueId.getAndIncrement(); } }; public static int getCurrentThreadId() { return uniqueId.get(); } } 从线程的角度看，每个线程都保持对其线程局部变量副本的隐式引用，只要线程是活动的并且 ThreadLocal 实例是可访问的；在线程消失之后，其线程局部实例的所有副本都会被垃圾回收（除非存在对这些副本的其他引用）。 API表达了下面几种观点： ThreadLocal不是线程，是线程的一个变量，你可以先简单理解为线程类的属性变量。 ThreadLocal 在类中通常定义为静态类变量。 每个线程有自己的一个ThreadLocal，它是变量的一个‘拷贝’，修改它不影响其他线程。 既然定义为类变量，为何为每个线程维护一个副本（姑且成为‘拷贝’容易理解），让每个线程独立访问？多线程编程的经验告诉我们，对于线程共享资源（你可以理解为属性），资源是否被所有线程共享，也就是说这个资源被一个线程修改是否影响另一个线程的运行，如果影响我们需要使用synchronized同步，让线程顺序访问。 ThreadLocal适用于资源共享但不需要维护状态的情况，也就是一个线程对资源的修改，不影响另一个线程的运行；这种设计是空间换时间，synchronized顺序执行是时间换取空间。 ThreadLocal介绍 从字面上来理解ThreadLocal，感觉就是相当于线程本地的。我们都知道，每个线程在jvm的虚拟机里都分配有自己独立的空间，线程之间对于本地的空间是相互隔离的。那么ThreadLocal就应该是该线程空间里本地可以访问的数据了。ThreadLocal变量高效地为每个使用它的线程提供单独的线程局部变量值的副本。每个线程只能看到与自己相联系的值，而不知道别的线程可能正在使用或修改它们自己的副本。 很多人看到这里会容易产生一种错误的印象，感觉是不是这个ThreadLocal对象建立了一个类似于全局的map，然后每个线程作为map的key来存取对应线程本地的value。你看，每个线程不一样，所以他们映射到map中的key应该也不一样。实际上，如果我们后面详细分析ThreadLocal的代码时，会发现不是这样的。它具体是怎么实现的呢？ 在此输入图片描述 ThreadLocal源码 ThreadLocal类本身定义了有get(), set()和initialValue()三个