面试：并发

1. 线程状态

1.1 六种状态及转换

分别是

* 新建
  * 当一个线程对象被创建，但还未调用 start 方法时处于新建状态
  * 此时未与操作系统底层线程关联
* 可运行
  * 调用了 start 方法，就会由**新建**进入**可运行**
  * 此时与底层线程关联，由操作系统调度执行
* 终结
  * 线程内代码已经执行完毕，由可运行进入终结
  * 此时会取消与底层线程关联
* 阻塞
  * 当获取锁失败后，由**可运行**进入 Monitor 的阻塞队列**阻塞**，此时不占用 cpu 时间
  * 当持锁线程释放锁时，会按照一定规则唤醒阻塞队列中的**阻塞**线程，唤醒后的线程进入**可运行**状态
* 等待
  * 当获取锁成功后，但由于条件不满足，调用了 wait() 方法，此时从**可运行**状态释放锁进入 Monitor 等待集合**等待**，同样不占用 cpu 时间
  * 当其它持锁线程调用 notify() 或 notifyAll() 方法，会按照一定规则唤醒等待集合中的**等待**线程，恢复为**可运行**状态
* 有时限等待
  * 当获取锁成功后，但由于条件不满足，调用了 wait(long) 方法，此时从**可运行**状态释放锁进入 Monitor 等待集合进行**有时限等待**，同样不占用 cpu 时间
  * 当其它持锁线程调用 notify() 或 notifyAll() 方法，会按照一定规则唤醒等待集合中的**有时限等待**线程，恢复为**可运行**状态，并重新去竞争锁
  * 如果等待超时，也会从**有时限等待**状态恢复为**可运行**状态，并重新去竞争锁
  * 还有一种情况是调用 sleep(long) 方法也会从**可运行**状态进入**有时限等待**状态，但与 Monitor 无关，不需要主动唤醒，超时时间到自然恢复为**可运行**状态

> * 可以用 interrupt() 方法打断**等待**、**有时限等待**的线程，让它们恢复为**可运行**状态
> * park，unpark 等方法也可以让线程等待和唤醒

1.2 五种状态

五种状态的说法来自于操作系统层面的划分

* 运行态：分到 cpu 时间，能真正执行线程内代码的
* 就绪态：有资格分到 cpu 时间，但还未轮到它的
* 阻塞态：没资格分到 cpu 时间的
  * 涵盖了 java 状态中提到的**阻塞**、**等待**、**有时限等待**
  * 多出了阻塞 I/O，指线程在调用阻塞 I/O 时，实际活由 I/O 设备完成，此时线程无事可做，只能干等
* 新建与终结态：与 java 中同名状态类似，不再赘述 

2. 线程池

2.1 七个参数

1. corePoolSize 核心线程数目 - 池中会保留的最多线程数
2. maximumPoolSize 最大线程数目 - 核心线程+救急线程的最大数目
3. keepAliveTime 生存时间 - 救急线程的生存时间，生存时间内没有新任务，此线程资源会释放
4. unit 时间单位 - 救急线程的生存时间单位，如秒、毫秒等
5. workQueue - 当没有空闲核心线程时，新来任务会加入到此队列排队，队列满会创建救急线程执行任务
6. threadFactory 线程工厂 - 可以定制线程对象的创建，例如设置线程名字、是否是守护线程等
7. handler 拒绝策略 - 当所有线程都在繁忙，workQueue 也放满时，会触发拒绝策略
   1. 抛异常 java.util.concurrent.ThreadPoolExecutor.AbortPolicy
   2. 由调用者执行任务 java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy
   3. 丢弃任务 java.util.concurrent.ThreadPoolExecutor.DiscardPolicy
   4. 丢弃最早排队任务 java.util.concurrent.ThreadPoolExecutor.DiscardOldestPolicy

3. wait vs sleep

3.1 共同点

* wait() 、wait(long) 、sleep(long) 的效果都是让当前线程暂时放弃 CPU 的使用权，进入阻塞状态

3.2 不同点

3.2.1 方法归属不同
  * sleep(long) 是 Thread 的静态方法
  * 而 wait()，wait(long) 都是 Object 的成员方法，每个对象都有

3.2.2 醒来时机不同
  * 执行 sleep(long) 和 wait(long) 的线程都会在等待相应毫秒后醒来
  * wait(long) 和 wait() 还可以被 notify 唤醒（还有一个是notifyAll，将这个对象上所有的等待线程，全部唤醒），wait() 如果不唤醒就一直等下去
  * 它们都可以被打断唤醒（线程对象调用 interrupt() 方法）

3.2.3 锁特性不同（重点）
  * wait 方法的调用必须先获取 wait 对象的锁，而 sleep 则无此限制

public class Test2 {
    static final Object LOCK = new Object();
    public static void main(String[] args) throws InterruptedException {
        illegalWait();
    }

    private static void illegalWait() throws InterruptedException {
        LOCK.wait();
    }
}

控制台输出：
Exception in thread "main" java.lang.IllegalMonitorStateException
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:502)
	at com.qq.qq.mal.rest.Test2.illegalWait(Test2.java:34)
	at com.qq.qq.mal.rest.Test2.main(Test2.java:30)

没有获得锁之前，调用 wait() 方法，会报一个非法的监视器状态异常，修改代码：

public class Test2 {
    static final Object LOCK = new Object();
    public static void main(String[] args) throws InterruptedException {
        illegalWait();
    }

    private static void illegalWait() throws InterruptedException {
        synchronized (LOCK) {
            LOCK.wait();
        }
    }
}

这次就没有错误了 

  * wait 方法执行后会释放对象锁，允许其它线程获得该对象锁（我放弃 cpu，但你们还可以用）
  * 而 sleep 如果在 synchronized 代码块中执行，并不会释放对象锁（我放弃 cpu，你们也用不了）

4. lock vs synchronized

4.1 不同点

语法层面
1）synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现（因为 synchronized 在语法层面实现了锁的功能，所以也被成为java中的内置锁）

2） Lock 是接口，源码由 jdk 提供，用 java 语言实现

3）使用 synchronized 时，退出同步代码块锁会自动释放，而使用 Lock 时，需要手动调用 unlock 方法释放锁（为了防止忘记释放锁，一般推荐写一个try、catch、finally语句块，在 finally 中释放锁）
功能层面
1）二者均属于悲观锁、都具备基本的互斥（多个线程争一把锁，只有一个线程可以成功，其他线程失败，进入阻塞状态）、同步（t1 线程运行到某处时，需要 t2 线程的结果，那么 t1 就需要拿到 t2 线程的结果后，才能继续运行； synchronized 可以使用wait()、notify() 实现线程间的同步，lock 可以使用 await ()  与 singnal () 实现线程间的同步）、锁重入功能（持锁对象可以重复加锁）

2）Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态、即支持非公平锁，也支持公平锁、可打断、可超时、多条件变量

3）synchronized 只支持非公平锁（抢锁失败的线程，再次获得锁时，先来先得，就叫公平锁，允许插队，就叫非公平锁，但是一般而言，非公平锁效率更高，推荐使用非公平锁）、不支持打断、不支持超时

4）Lock 有适合不同场景的实现，如 ReentrantLock， ReentrantReadWriteLock
性能层面

  * 在没有竞争时，synchronized 做了很多优化，如偏向锁、轻量级锁，性能OK

  * 在竞争激烈时，Lock 的实现通常会提供更好的性能

公平锁

* 公平锁的公平体现
  * 已经处在阻塞队列**中的线程（不考虑超时）始终都是公平的，先进先出
  * 公平锁是指**未处于阻塞队列**中的线程来争抢锁，如果队列不为空，则老实到队尾等待
  * 非公平锁是指**未处于阻塞队列**中的线程来争抢锁，与队列头唤醒的线程去竞争，谁抢到算谁的
* 公平锁会降低吞吐量，一般不用

条件变量

* ReentrantLock 中的条件变量功能类似于普通 synchronized 的 wait，notify，用在当线程获得锁后，发现条件不满足时，临时等待的链表结构

* 与 synchronized 的等待集合不同之处在于，ReentrantLock 中的条件变量可以有多个，可以实现更精细的等待、唤醒控制

有参的 tryLock() 方法，会根据设置的参数来时实现公平锁或非公平锁

 无参的 tryLock() 方法，总是使用非公平锁

5. volatile

问：volatile 能否保证线程安全？

答：不可以，volatile 可以保证共享变量的可见性与有序性，但不能保证原子性。

线程安全要考虑三个方面：可见性、有序性、原子性

可见性：

一个线程对共享变量进行修改，另一线程能看到最新的结果；

起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致的对共享变量所做的修改另外的线程看不到；
解决：用 volatile 修饰共享变量，能够防止编译器等优化发生，让一个线程对共享变量的修改对另一个线程可见；

代码演示：

public class Test2 {
    static boolean stop = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            stop = true;
            get().debug("modify stop to true...");
        }).start();

        foo();
    }

    static void foo() {
        int i = 0;
        while (!stop) {
            i++;
        }
        get().debug("stopped... c:{}", i);
    }
}

控制台输出：

主线程执行 while 循环，另一线程睡眠0.1秒后，对共享变量进行修改，但是主线程没有读到修改后的最新值，while 循环一直运行

网上对于这个问题的解释，有些是从java内存模型的角度来解释，例如：

这种解释并不正确，为什么呢？

对代码修改一下，再加一个线程去获取共享变量，根据java内存模型的解释，共享变量的值应该是原值，即 stop = false

public class Test2 {
    static boolean stop = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            stop = true;
            get().debug("modify stop to true...");
        }).start();

        new Thread(() -> {
            try {
                Thread.sleep(200);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            get().debug("{}", stop);
        }).start();

        foo();
    }

    static void foo() {
        int i = 0;
        while (!stop) {
            i++;
        }
        get().debug("stopped... c:{}", i);
    }
}

 控制台输出：

查看控制台输出，线程0将 stop 修改为了true并同步到了内存，线程1获取到的 stop 的值为 true，但也可以看到，while 循环一直在执行

因此，从java内存模型角度的解释，是站不住脚的

那么，原因到底是什么呢？

stop 共享变量初始值为 false，存储在物理内存当中，线程1执行 while 循环代码，线程2将共享变量的值改为true

CPU在执行 while 循环时，需要不断的、极频繁的去内存中获取 stop 的值，那么代码中的0.1秒的时间，在我的机器上，可以执行一千多万次的读取，如此频繁的内存读取 stop 变量的值，并且值还不变，JVM中的JIT（任何一段java代码，会翻译成java的字节码指令，字节码还需要解释器的组件，翻译成机器码，机器码再交给CPU执行，JIT会对一些热点的字节码，例如频繁调用的方法，反复执行的循环等，进行优化），就会认为这段代码可以优化，怎么优化呢？

JIT会尝试减少CPU与内存之间的读取操作，进而做了一个大胆的优化，因为每次读取到的变量值都是 false ，那么，原来的字节码被JIT替换成了编译后的机器码，缓存起来，再次执行这段代码时，直接将缓存的机器码，交给CPU去运行，少了中间解释的过程，自然效率更高，于是运行效果就变成了 while (!false)，当然，也有方法，可以将原来的代码再替换回来

JIT发现原始代码效率太低，将原始代码替换掉了，结果导致线程2将 stop 变成了 true，但是线程1依然按照 stop = false 在运行，对于其他的线程来讲，由于没有被JIT优化过，是可以读到stop = true的

如何证明这种说法呢？

代码演示：

-Xint 是一个java虚拟机参数，意思是只用解释执行的java字节码，不用JIT编译器，只用解释器，不用JIT优化，将 -Xint 添加到虚拟机参数

public class Test2 {
    static boolean stop = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            stop = true;
            get().debug("modify stop to true...");
        }).start();

        foo();
    }

    static void foo() {
        int i = 0;
        while (!stop) {
            i++;
        }
        get().debug("stopped... c:{}", i);
    }
}

控制台输出：

查看日志，发现 while (!stop) 读到了 stop 变量的最新的值，打印了日志，停止了循环，循环了两千多万次

这就是可见性问题的原因

按照这个逻辑，减少 while 循环的次数，只要次数不多，就不会被JIT认为成热点代码，就不会被优化，就不会出现可见性的问题，那么做个实验，假如将睡眠时间修改为0

public class Test2 {
    static boolean stop = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            stop = true;
            get().debug("modify stop to true...");
        }).start();

        foo();
    }

    static void foo() {
        int i = 0;
        while (!stop) {
            i++;
        }
        get().debug("stopped... c:{}", i);
    }
}

控制台输出：

查看日志，将睡眠时间修改为0，while 循环执行的次数比较少，只有两万多次，没有被JIT认为成热点代码，就没有被行优化，也就成功的退出了循环

添加虚拟机参数，或者是减少循环次数，不是根本性的解决方法

JIT优化可以很大的提高效率，为了读不到共享变量最新值的问题，把JIT优化给禁了，代价太大

最好使用 volatile 修饰变量，JIT发现变量使用 volatile 修饰时，不会对其进行优化

代码演示：

public class Test2 {
    static volatile boolean stop = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            stop = true;
            get().debug("modify stop to true...");
        }).start();

        foo();
    }

    static void foo() {
        int i = 0;
        while (!stop) {
            i++;
        }
        get().debug("stopped... c:{}", i);
    }
}

 控制台输出：

查看日志，看到 while 循环，0.1秒执行了三亿七千万多次，但是并没有被JIT进行优化，while 循环正确的打印了日志，退出了循环，解决了可见性的问题

有序性：

一个线程内代码按编写顺序执行；

起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致指令的实际执行顺序与编写顺序不一致
解决：用 volatile 修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果
注意：
  volatile 变量写加的屏障是阻止上方其它写操作越过屏障排到volatile 变量写之下
  volatile 变量读加的屏障是阻止下方其它读操作越过屏障排到volatile 变量读之上
  volatile 读写加入的屏障只能防止同一线程内的指令重排

有序性，不像可见性或原子性，通过代码就能够观察出来，有序性需要大量的压测试验，才会暴露出来指令重排序这种现象

原子性：

一个线程内多行代码以一个整体运行，期间不能有其他线程的代码插队；

起因：一行代码，反编译后，可能对应的是多行指令，多线程下，不同线程的指令发生了交错导致的共享变量的读写混乱
解决：用悲观锁或乐观锁解决，volatile 并不能解决原子性

代码演示：

public class Test2 {
    static volatile int balance = 10;

    public static void subtract() {
        balance -= 5;
    }

    public static void add() {
        balance += 5;
    }

    public static void main(String[] args) throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(2);
        new Thread(() -> {
            subtract();
            latch.countDown();
        }).start();
        new Thread(() -> {
            add();
            latch.countDown();
        }).start();
        latch.await();
        LoggerUtils.get().debug("{}", balance);
    }
}

控制台输出：
10:46:37.624 [main] DEBUG G - 10

看代码逻辑，一个+5，一个-5，结果应该是10，控制台输出也是10

但是这段代码，在多线程下，是有问题的，运行次数多的时候，例如百万次，就会发现结果有可能是5，或者是15，为什么呢？

代码中的 +5 或 -5 不是原子操作，一行代码，会对应底层多行指令，多线程下，如果多行指令不发生交错，那么执行结果不会有问题，一旦多行指令出现交错运行，就会出现问题

我们对代码进行反编译

看到一行代码，变成了四行指令

        getstatic：读取共享变量的值；

        iconst_5：准备了一个数字5；

        isub：减法运算；

        putstatic：将运算结果，写回共享变量；

减法运算，拆分成了四步

如果加法的多行指令与减法的多行指令，出现了线程间的指令交错

多线程下，CPU的执行，是在线程间来回切换的

 add 
 0: getstatic // 获取到共享变量 balance = 10

                 sub
                 0: getstatic // 获取到共享变量 balance = 10
                 3: iconst_5
                 4: isub      // 10 - 5 运算
                 5: putstatic // balance = 5
                  
 3: iconst_5
 4: iadd       // 10 + 5 运算
 5: putstatic

结果返回15

6. 对比悲观锁与乐观锁

悲观锁的代表是 synchronized 和 Lock 锁
其核心思想是【线程只有占有了锁，才能去操作共享变量，每次只有一个线程占锁成功，获取锁失败的线程，都得停下来等待】
线程从运行到阻塞、再从阻塞到唤醒，涉及线程上下文切换，如果频繁发生，影响性能
实际上，线程在获取 synchronized 和 Lock 锁时，如果锁已被占用，都会做几次重试操作，减少阻塞的机会

乐观锁的代表是 AtomicInteger，使用 cas 来保证原子性
其核心思想是无需加锁，每次只有一个线程能成功修改共享变量，其它失败的线程不需要停止，不断重试直至成功
由于线程一直运行，不需要阻塞，因此不涉及线程上下文切换
它需要多核 cpu 支持，且线程数不应超过 cpu 核数

需要注意的是，乐观锁可以保证操作的原子性，但是无法保证可见性，所以变量需要使用 volatile 来修饰

7. Hashtable vs ConcurrentHashMap

相同点

Hashtable 与 ConcurrentHashMap 都是线程安全的 Map 集合，同时二者的键、值均不能为空

不同点

Hashtable 并发度低，整个 Hashtable 对应一把锁，同一时刻，只能有一个线程操作它，其他线程处于阻塞状态
ConcurrentHashMap 并发度高，整个 ConcurrentHashMap 对应多把锁，只要线程访问的是不同锁，那么不会冲突

7.1 Hashtable

Hashtable的初始容量为11，每次扩容时上次的容量*2+1，超过3/4时扩容

hashCode 的计算，无需二次 hash

7.2 ConcurrentHashMap 1.7

数据结构：Segment(大数组) + HashEntry(小数组) + 链表，每个 Segment 对应一把锁，如果多个线程访问不同的 Segment，则不会冲突
并发度：Segment 数组大小即并发度，决定了同一时刻最多能有多少个线程并发访问。Segment 数组不能扩容，意味着并发度在 ConcurrentHashMap 创建时就固定了
索引计算
        假设大数组长度是 $2^m$，key 在大数组内的索引是 key 的二次 hash 值的高 m 位
        假设小数组长度是 $2^n$，key 在小数组内的索引是 key 的二次 hash 值的低 n 位
扩容：每个小数组的扩容相对独立，小数组在超过扩容因子时会触发扩容，每次扩容翻倍，小数组新增的元素使用头插法插入
Segment[0] 原型：首次创建其它小数组时，会以此原型为依据，数组长度，扩容因子都会以原型为准，如果原型由于添加元素发生了扩容，那么再次创建其他小数组时，以最新的原型为依据

7.3 ConcurrentHashMap 1.8

数据结构：Node 数组 + 链表或红黑树，数组的每个头节点作为锁，如果多个线程访问的头节点不同，则不会冲突。首次生成头节点时如果发生竞争，利用 cas 而非 syncronized，进一步提升性能
并发度：Node 数组有多大，并发度就有多大，与 1.7 不同，Node 数组可以扩容
扩容条件：Node 数组满 3/4 时就会扩容
扩容单位：以链表为单位从后向前迁移链表，迁移完成的将旧数组头节点替换为 ForwardingNode
扩容时并发 get
        根据是否为 ForwardingNode 来决定是在新数组查找还是在旧数组查找，不会阻塞
        如果链表长度超过 1，则需要对节点进行复制（创建新节点），怕的是节点迁移后 next 指针改变
        如果链表最后几个元素扩容后索引不变，则节点无需复制
扩容时并发 put
        如果·    put 的线程与扩容线程操作的链表是同一个，put 线程会阻塞
        如果 put 的线程操作的链表还未迁移完成，即头节点不是 ForwardingNode，则可以并发执行
        如果 put 的线程操作的链表已经迁移完成，即头结点是 ForwardingNode，则可以协助扩容
1.8 与 1.7 相比是懒惰初始化，在第一次 put 元素时，才会创建底层的数组结构
capacity 代表预估的元素个数，capacity / factory 来计算出初始数组大小，需要贴近 $2^n$ 
loadFactor 扩容因子，只在计算初始数组大小时被使用，之后扩容固定为 3/4
超过树化阈值时的扩容问题，如果容量已经是 64，直接树化，否则在原来容量基础上做 3 轮扩容

1.8 链表在新增元素时使用尾插法

8. ThreadLocal

8.1 作用

1）ThreadLocal 可以实现【资源对象】的线程隔离，让每个线程各用各的【资源对象】，避免争用引发的线程安全问题

public class Test2{

    public static void main(String[] args) {
        test1();
    }

    // 多个线程调用, 得到的是自己的 Student 对象
    private static void test1() {
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                LoggerUtils.get("t").debug("{}", Utils.getStudent());
            }, "t" + (i + 1)).start();
        }
    }

    static class Utils {
        private static final ThreadLocal<Student> tl = new ThreadLocal<>();

        public static Student getStudent() {
            Student student = tl.get(); // 到当前线程获取资源
            if (student == null) {
                student = innerStudent(); // 创建新的对象
                tl.set(student); // 将资源存入当前线程
            }
            return student;
        }

        private static Student innerStudent() {
            return new Student();
        }
    }
}

控制台输出：
11:41:47.489 [t5] DEBUG E - com.qq.qq.mal.receiver.Student@20dd9ef4
11:41:47.489 [t2] DEBUG B - com.qq.qq.mal.receiver.Student@a684b
11:41:47.489 [t1] DEBUG A - com.qq.qq.mal.receiver.Student@61c2c38
11:41:47.489 [t4] DEBUG D - com.qq.qq.mal.receiver.Student@29aef865
11:41:47.489 [t3] DEBUG C - com.qq.qq.mal.receiver.Student@20851e82

每个线程获得的是不同的 Student 对象 

2）ThreadLocal 同时实现了线程内的资源共享

public class Test2{

    public static void main(String[] args) {
        test2();
    }

    // 一个线程内调用, 得到的是同一个 Student对象
    private static void test2() {
        for (int i = 0; i < 2; i++) {
            new Thread(() -> {
                LoggerUtils.get("t").debug("{}", Utils.getStudent());
                LoggerUtils.get("t").debug("{}", Utils.getStudent());
                LoggerUtils.get("t").debug("{}", Utils.getStudent());
            }, "t" + (i + 1)).start();
        }
    }

    static class Utils {
        private static final ThreadLocal<Student> tl = new ThreadLocal<>();

        public static Student getStudent() {
            Student student = tl.get(); // 到当前线程获取资源
            if (student == null) {
                student = innerStudent(); // 创建新的对象
                tl.set(student); // 将资源存入当前线程
            }
            return student;
        }

        private static Student innerStudent() {
            return new Student();
        }
    }
}

控制台输出：
11:45:24.623 [t2] DEBUG B - com.qq.qq.mal.receiver.Student@2cd544fc
11:45:24.623 [t1] DEBUG A - com.qq.qq.mal.receiver.Student@40884e08
11:45:24.628 [t2] DEBUG B - com.qq.qq.mal.receiver.Student@2cd544fc
11:45:24.628 [t2] DEBUG B - com.qq.qq.mal.receiver.Student@2cd544fc
11:45:24.628 [t1] DEBUG A - com.qq.qq.mal.receiver.Student@40884e08
11:45:24.629 [t1] DEBUG A - com.qq.qq.mal.receiver.Student@40884e08

8.2 原理

1）每个线程内有一个 ThreadLocalMap 类型的成员变量，用来存储资源对象

2）调用 set 方法，就是以 ThreadLocal 自己作为 key，资源对象作为 value，放入当前线程的 ThreadLocalMap 集合中

3）调用 get 方法，就是以 ThreadLocal 自己作为 key，到当前线程中查找关联的资源值

4）调用 remove 方法，就是以 ThreadLocal 自己作为 key，移除当前线程关联的资源值

8.3 ThreadLocalMap 特点

1）key 的 hash 值统一分配

2）初始容量 16，扩容因子 2/3，扩容容量翻倍

3）key 索引冲突后用开放寻址法解决冲突

8.4 弱引用 key

ThreadLocalMap 中的 key 被设计为弱引用，原因如下

Thread 可能需要长时间运行（如线程池中的线程），如果 key 不再使用，需要在内存不足（GC）时释放其占用的内存

8.5 内存释放时机

1）被动 GC 释放 key

仅是让 key 的内存释放，关联 value 的内存并不会释放

2）懒惰被动释放 value

get key 时，发现是 null key，则释放其 value 内存

set key 时，会使用启发式扫描，清除临近的 null key 的 value 内存，启发次数与元素个数、是否发现 null key 有关

3）主动 remove 释放 key，value

会同时释放 key，value 的内存，也会清除临近的 null key 的 value 内存

推荐使用它，因为一般使用 ThreadLocal 时都把它作为静态变量（即强引用），因此无法被动依靠 GC 回收