mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
523 lines
27 KiB
Markdown
523 lines
27 KiB
Markdown
---
|
||
title: Java 并发常见面试题总结（中）
|
||
category: Java
|
||
tag:
|
||
- Java并发
|
||
head:
|
||
- - meta
|
||
- name: keywords
|
||
content: 多线程,死锁,synchronized,ReentrantLock,volatile,ThreadLocal,线程池,CAS,AQS
|
||
- - meta
|
||
- name: description
|
||
content: Java并发常见知识点和面试题总结（含详细解答），希望对你有帮助！
|
||
---
|
||
|
||
## JMM(Java Memory Model)
|
||
|
||
JMM（Java 内存模型）相关的问题比较多，也比较重要，于是我单独抽了一篇文章来总结 JMM 相关的知识点和问题： [JMM（Java 内存模型）详解](./jmm.md) 。
|
||
|
||
## volatile 关键字
|
||
|
||
### 如何保证变量的可见性？
|
||
|
||
在 Java 中，`volatile` 关键字可以保证变量的可见性，如果我们将变量声明为 **`volatile`** ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。
|
||
|
||
|
||
|
||
|
||
|
||
`volatile` 关键字其实并非是 Java 语言特有的，在 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。如果我们将一个变量使用 `volatile` 修饰，这就指示 编译器，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。
|
||
|
||
`volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。
|
||
|
||
### 如何禁止指令重排序？
|
||
|
||
**在 Java 中，`volatile` 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。** 如果我们将变量声明为 **`volatile`** ，在对这个变量进行读写操作的时候，会通过插入特定的 **内存屏障** 的方式来禁止指令重排序。
|
||
|
||
在 Java 中，`Unsafe` 类提供了三个开箱即用的内存屏障相关的方法，屏蔽了操作系统底层的差异：
|
||
|
||
```java
|
||
public native void loadFence();
|
||
public native void storeFence();
|
||
public native void fullFence();
|
||
```
|
||
|
||
理论上来说，你通过这个三个方法也可以实现和`volatile`禁止重排序一样的效果，只是会麻烦一些。
|
||
|
||
下面我以一个常见的面试题为例讲解一下 `volatile` 关键字禁止指令重排序的效果。
|
||
|
||
面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！”
|
||
|
||
**双重校验锁实现对象单例（线程安全）** ：
|
||
|
||
```java
|
||
public class Singleton {
|
||
|
||
private volatile static Singleton uniqueInstance;
|
||
|
||
private Singleton() {
|
||
}
|
||
|
||
public static Singleton getUniqueInstance() {
|
||
//先判断对象是否已经实例过，没有实例化过才进入加锁代码
|
||
if (uniqueInstance == null) {
|
||
//类对象加锁
|
||
synchronized (Singleton.class) {
|
||
if (uniqueInstance == null) {
|
||
uniqueInstance = new Singleton();
|
||
}
|
||
}
|
||
}
|
||
return uniqueInstance;
|
||
}
|
||
}
|
||
```
|
||
|
||
`uniqueInstance` 采用 `volatile` 关键字修饰也是很有必要的， `uniqueInstance = new Singleton();` 这段代码其实是分为三步执行：
|
||
|
||
1. 为 `uniqueInstance` 分配内存空间
|
||
2. 初始化 `uniqueInstance`
|
||
3. 将 `uniqueInstance` 指向分配的内存地址
|
||
|
||
但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 `getUniqueInstance`() 后发现 `uniqueInstance` 不为空，因此返回 `uniqueInstance`，但此时 `uniqueInstance` 还未被初始化。
|
||
|
||
### volatile 可以保证原子性么？
|
||
|
||
**`volatile` 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。**
|
||
|
||
我们通过下面的代码即可证明：
|
||
|
||
```java
|
||
/**
|
||
* 微信搜 JavaGuide 回复"面试突击"即可免费领取个人原创的 Java 面试手册
|
||
*
|
||
* @author Guide哥
|
||
* @date 2022/08/03 13:40
|
||
**/
|
||
public class VolatoleAtomicityDemo {
|
||
public volatile static int inc = 0;
|
||
|
||
public void increase() {
|
||
inc++;
|
||
}
|
||
|
||
public static void main(String[] args) throws InterruptedException {
|
||
ExecutorService threadPool = Executors.newFixedThreadPool(5);
|
||
VolatoleAtomicityDemo volatoleAtomicityDemo = new VolatoleAtomicityDemo();
|
||
for (int i = 0; i < 5; i++) {
|
||
threadPool.execute(() -> {
|
||
for (int j = 0; j < 500; j++) {
|
||
volatoleAtomicityDemo.increase();
|
||
}
|
||
});
|
||
}
|
||
// 等待1.5秒，保证上面程序执行完成
|
||
Thread.sleep(1500);
|
||
System.out.println(inc);
|
||
threadPool.shutdown();
|
||
}
|
||
}
|
||
```
|
||
|
||
正常情况下，运行上面的代码理应输出 `2500`。但你真正运行了上面的代码之后，你会发现每次输出结果都小于 `2500`。
|
||
|
||
为什么会出现这种情况呢？不是说好了，`volatile` 可以保证变量的可见性嘛！
|
||
|
||
也就是说，如果 `volatile` 能保证 `inc++` 操作的原子性的话。每个线程中对 `inc` 变量自增完之后，其他线程可以立即看到修改后的值。5 个线程分别进行了 500 次操作，那么最终 inc 的值应该是 5\*500=2500。
|
||
|
||
很多人会误认为自增操作 `inc++` 是原子性的，实际上，`inc++` 其实是一个复合操作，包括三步：
|
||
|
||
1. 读取 inc 的值。
|
||
2. 对 inc 加 1。
|
||
3. 将 inc 的值写回内存。
|
||
|
||
`volatile` 是无法保证这三个操作是具有原子性的，有可能导致下面这种情况出现：
|
||
|
||
1. 线程 1 对 `inc` 进行读取操作之后，还未对其进行修改。线程 2 又读取了 `inc`的值并对其进行修改（+1），再将`inc` 的值写回内存。
|
||
2. 线程 2 操作完毕后，线程 1 对 `inc`的值进行修改（+1），再将`inc` 的值写回内存。
|
||
|
||
这也就导致两个线程分别对 `inc` 进行了一次自增操作后，`inc` 实际上只增加了 1。
|
||
|
||
其实，如果想要保证上面的代码运行正确也非常简单，利用 `synchronized` 、`Lock`或者`AtomicInteger`都可以。
|
||
|
||
使用 `synchronized` 改进：
|
||
|
||
```java
|
||
public synchronized void increase() {
|
||
inc++;
|
||
}
|
||
```
|
||
|
||
使用 `AtomicInteger` 改进：
|
||
|
||
```java
|
||
public AtomicInteger inc = new AtomicInteger();
|
||
|
||
public void increase() {
|
||
inc.getAndIncrement();
|
||
}
|
||
```
|
||
|
||
使用 `ReentrantLock` 改进：
|
||
|
||
```java
|
||
Lock lock = new ReentrantLock();
|
||
public void increase() {
|
||
lock.lock();
|
||
try {
|
||
inc++;
|
||
} finally {
|
||
lock.unlock();
|
||
}
|
||
}
|
||
```
|
||
|
||
## synchronized 关键字
|
||
|
||
### 说一说自己对于 synchronized 关键字的了解
|
||
|
||
`synchronized` 翻译成中文是同步的的意思，主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。
|
||
|
||
在 Java 早期版本中，`synchronized` 属于 **重量级锁**，效率低下。 因为监视器锁（monitor）是依赖于底层的操作系统的 `Mutex Lock` 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。
|
||
|
||
不过，在 Java 6 之后，Java 官方对从 JVM 层面对 `synchronized` 较大优化，所以现在的 `synchronized` 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。所以，你会发现目前的话，不论是各种开源框架还是 JDK 源码都大量使用了 `synchronized` 关键字。
|
||
|
||
### 如何使用 synchronized 关键字？
|
||
|
||
synchronized 关键字最主要的三种使用方式：
|
||
|
||
1. 修饰实例方法
|
||
2. 修饰静态方法
|
||
3. 修饰代码块
|
||
|
||
**1、修饰实例方法** （锁当前对象实例）
|
||
|
||
给当前对象实例加锁，进入同步代码前要获得 **当前对象实例的锁** 。
|
||
|
||
```java
|
||
synchronized void method() {
|
||
//业务代码
|
||
}
|
||
```
|
||
|
||
**2、修饰静态方法** （锁当前类）
|
||
|
||
给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 **当前 class 的锁**。
|
||
|
||
这是因为静态成员不属于任何一个实例对象，归整个类所有，不依赖于类的特定实例，被类的所有实例共享。
|
||
|
||
```java
|
||
synchronized static void method() {
|
||
//业务代码
|
||
}
|
||
```
|
||
|
||
静态 `synchronized` 方法和非静态 `synchronized` 方法之间的调用互斥么？不互斥！如果一个线程 A 调用一个实例对象的非静态 `synchronized` 方法，而线程 B 需要调用这个实例对象所属类的静态 `synchronized` 方法，是允许的，不会发生互斥现象，因为访问静态 `synchronized` 方法占用的锁是当前类的锁，而访问非静态 `synchronized` 方法占用的锁是当前实例对象锁。
|
||
|
||
**3、修饰代码块** （锁指定对象/类）
|
||
|
||
对括号里指定的对象/类加锁：
|
||
|
||
- `synchronized(object)` 表示进入同步代码库前要获得 **给定对象的锁**。
|
||
- `synchronized(类.class)` 表示进入同步代码前要获得 **给定 Class 的锁**
|
||
|
||
```java
|
||
synchronized(this) {
|
||
//业务代码
|
||
}
|
||
```
|
||
|
||
**总结：**
|
||
|
||
- `synchronized` 关键字加到 `static` 静态方法和 `synchronized(class)` 代码块上都是是给 Class 类上锁；
|
||
- `synchronized` 关键字加到实例方法上是给对象实例上锁；
|
||
- 尽量不要使用 `synchronized(String a)` 因为 JVM 中，字符串常量池具有缓存功能。
|
||
|
||
### 构造方法可以使用 synchronized 关键字修饰么？
|
||
|
||
先说结论：**构造方法不能使用 synchronized 关键字修饰。**
|
||
|
||
构造方法本身就属于线程安全的，不存在同步的构造方法一说。
|
||
|
||
### 讲一下 synchronized 关键字的底层原理
|
||
|
||
synchronized 关键字底层原理属于 JVM 层面。
|
||
|
||
#### synchronized 同步语句块的情况
|
||
|
||
```java
|
||
public class SynchronizedDemo {
|
||
public void method() {
|
||
synchronized (this) {
|
||
System.out.println("synchronized 代码块");
|
||
}
|
||
}
|
||
}
|
||
|
||
```
|
||
|
||
通过 JDK 自带的 `javap` 命令查看 `SynchronizedDemo` 类的相关字节码信息：首先切换到类的对应目录执行 `javac SynchronizedDemo.java` 命令生成编译后的 .class 文件，然后执行`javap -c -s -v -l SynchronizedDemo.class`。
|
||
|
||
|
||
|
||
从上面我们可以看出：**`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。**
|
||
|
||
当执行 `monitorenter` 指令时，线程试图获取锁也就是获取 **对象监视器 `monitor`** 的持有权。
|
||
|
||
> 在 Java 虚拟机(HotSpot)中，Monitor 是基于 C++实现的，由[ObjectMonitor](https://github.com/openjdk-mirror/jdk7u-hotspot/blob/50bdefc3afe944ca74c3093e7448d6b889cd20d1/src/share/vm/runtime/objectMonitor.cpp)实现的。每个对象中都内置了一个 `ObjectMonitor`对象。
|
||
>
|
||
> 另外，`wait/notify`等方法也依赖于`monitor`对象，这就是为什么只有在同步的块或者方法中才能调用`wait/notify`等方法，否则会抛出`java.lang.IllegalMonitorStateException`的异常的原因。
|
||
|
||
在执行`monitorenter`时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。
|
||
|
||
|
||
|
||
对象锁的的拥有者线程才可以执行 `monitorexit` 指令来释放锁。在执行 `monitorexit` 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。
|
||
|
||
|
||
|
||
如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。
|
||
|
||
#### synchronized 修饰方法的的情况
|
||
|
||
```java
|
||
public class SynchronizedDemo2 {
|
||
public synchronized void method() {
|
||
System.out.println("synchronized 方法");
|
||
}
|
||
}
|
||
|
||
```
|
||
|
||
|
||
|
||
`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。JVM 通过该 `ACC_SYNCHRONIZED` 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。
|
||
|
||
如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。
|
||
|
||
#### 总结
|
||
|
||
`synchronized` 同步语句块的实现使用的是 `monitorenter` 和 `monitorexit` 指令，其中 `monitorenter` 指令指向同步代码块的开始位置，`monitorexit` 指令则指明同步代码块的结束位置。
|
||
|
||
`synchronized` 修饰的方法并没有 `monitorenter` 指令和 `monitorexit` 指令，取得代之的确实是 `ACC_SYNCHRONIZED` 标识，该标识指明了该方法是一个同步方法。
|
||
|
||
**不过两者的本质都是对对象监视器 monitor 的获取。**
|
||
|
||
相关推荐：[Java 锁与线程的那些事 - 有赞技术团队](https://tech.youzan.com/javasuo-yu-xian-cheng-de-na-xie-shi/) 。
|
||
|
||
🧗🏻 进阶一下：学有余力的小伙伴可以抽时间详细研究一下对象监视器 `monitor`。
|
||
|
||
### JDK1.6 之后的 synchronized 关键字底层做了哪些优化？
|
||
|
||
JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。
|
||
|
||
锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。
|
||
|
||
关于这几种优化的详细信息可以查看下面这篇文章：[Java6 及以上版本对 synchronized 的优化](https://www.cnblogs.com/wuqinglong/p/9945618.html)
|
||
|
||
### synchronized 和 volatile 的区别？
|
||
|
||
`synchronized` 关键字和 `volatile` 关键字是两个互补的存在，而不是对立的存在！
|
||
|
||
- `volatile` 关键字是线程同步的轻量级实现，所以 `volatile`性能肯定比`synchronized`关键字要好 。但是 `volatile` 关键字只能用于变量而 `synchronized` 关键字可以修饰方法以及代码块 。
|
||
- `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。
|
||
- `volatile`关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。
|
||
|
||
### synchronized 和 ReentrantLock 的区别
|
||
|
||
#### 两者都是可重入锁
|
||
|
||
**“可重入锁”** 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 1，所以要等到锁的计数器下降为 0 时才能释放锁。
|
||
|
||
#### synchronized 依赖于 JVM 而 ReentrantLock 依赖于 API
|
||
|
||
`synchronized` 是依赖于 JVM 实现的，前面我们也讲到了 虚拟机团队在 JDK1.6 为 `synchronized` 关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。`ReentrantLock` 是 JDK 层面实现的（也就是 API 层面，需要 lock() 和 unlock() 方法配合 try/finally 语句块来完成），所以我们可以通过查看它的源代码，来看它是如何实现的。
|
||
|
||
#### ReentrantLock 比 synchronized 增加了一些高级功能
|
||
|
||
相比`synchronized`，`ReentrantLock`增加了一些高级功能。主要来说主要有三点：
|
||
|
||
- **等待可中断** : `ReentrantLock`提供了一种能够中断等待锁的线程的机制，通过 `lock.lockInterruptibly()` 来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
|
||
- **可实现公平锁** : `ReentrantLock`可以指定是公平锁还是非公平锁。而`synchronized`只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。`ReentrantLock`默认情况是非公平的，可以通过 `ReentrantLock`类的`ReentrantLock(boolean fair)`构造方法来制定是否是公平的。
|
||
- **可实现选择性通知（锁可以绑定多个条件）**: `synchronized`关键字与`wait()`和`notify()`/`notifyAll()`方法相结合可以实现等待/通知机制。`ReentrantLock`类当然也可以实现，但是需要借助于`Condition`接口与`newCondition()`方法。
|
||
|
||
> `Condition`是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能也就是在一个`Lock`对象中可以创建多个`Condition`实例（即对象监视器），**线程对象可以注册在指定的`Condition`中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用`notify()/notifyAll()`方法进行通知时，被通知的线程是由 JVM 选择的，用`ReentrantLock`类结合`Condition`实例可以实现“选择性通知”** ，这个功能非常重要，而且是 Condition 接口默认提供的。而`synchronized`关键字就相当于整个 Lock 对象中只有一个`Condition`实例，所有的线程都注册在它一个身上。如果执行`notifyAll()`方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而`Condition`实例的`signalAll()`方法 只会唤醒注册在该`Condition`实例中的所有等待线程。
|
||
|
||
**如果你想使用上述功能，那么选择 ReentrantLock 是一个不错的选择。性能已不是选择标准**
|
||
|
||
## ThreadLocal
|
||
|
||
### ThreadLocal 有什么用？
|
||
|
||
通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。**如果想实现每一个线程都有自己的专属本地变量该如何解决呢？**
|
||
|
||
JDK 中自带的`ThreadLocal`类正是为了解决这样的问题。 **`ThreadLocal`类主要解决的就是让每个线程绑定自己的值，可以将`ThreadLocal`类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。**
|
||
|
||
如果你创建了一个`ThreadLocal`变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是`ThreadLocal`变量名的由来。他们可以使用 `get（）` 和 `set（）` 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。
|
||
|
||
再举个简单的例子：两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么 ThreadLocal 就是用来避免这两个线程竞争的。
|
||
|
||
### 如何使用 ThreadLocal？
|
||
|
||
相信看了上面的解释，大家已经搞懂 `ThreadLocal` 类是个什么东西了。下面简单演示一下如何在项目中实际使用 `ThreadLocal` 。
|
||
|
||
```java
|
||
import java.text.SimpleDateFormat;
|
||
import java.util.Random;
|
||
|
||
public class ThreadLocalExample implements Runnable{
|
||
|
||
// SimpleDateFormat 不是线程安全的，所以每个线程都要有自己独立的副本
|
||
private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));
|
||
|
||
public static void main(String[] args) throws InterruptedException {
|
||
ThreadLocalExample obj = new ThreadLocalExample();
|
||
for(int i=0 ; i<10; i++){
|
||
Thread t = new Thread(obj, ""+i);
|
||
Thread.sleep(new Random().nextInt(1000));
|
||
t.start();
|
||
}
|
||
}
|
||
|
||
@Override
|
||
public void run() {
|
||
System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());
|
||
try {
|
||
Thread.sleep(new Random().nextInt(1000));
|
||
} catch (InterruptedException e) {
|
||
e.printStackTrace();
|
||
}
|
||
//formatter pattern is changed here by thread, but it won't reflect to other threads
|
||
formatter.set(new SimpleDateFormat());
|
||
|
||
System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());
|
||
}
|
||
|
||
}
|
||
|
||
```
|
||
|
||
输出结果 :
|
||
|
||
```
|
||
Thread Name= 0 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 0 formatter = yy-M-d ah:mm
|
||
Thread Name= 1 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 2 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 1 formatter = yy-M-d ah:mm
|
||
Thread Name= 3 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 2 formatter = yy-M-d ah:mm
|
||
Thread Name= 4 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 3 formatter = yy-M-d ah:mm
|
||
Thread Name= 4 formatter = yy-M-d ah:mm
|
||
Thread Name= 5 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 5 formatter = yy-M-d ah:mm
|
||
Thread Name= 6 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 6 formatter = yy-M-d ah:mm
|
||
Thread Name= 7 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 7 formatter = yy-M-d ah:mm
|
||
Thread Name= 8 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 9 default Formatter = yyyyMMdd HHmm
|
||
Thread Name= 8 formatter = yy-M-d ah:mm
|
||
Thread Name= 9 formatter = yy-M-d ah:mm
|
||
```
|
||
|
||
从输出中可以看出，虽然 `Thread-0` 已经改变了 `formatter` 的值，但 `Thread-1` 默认格式化值与初始化值相同，其他线程也一样。
|
||
|
||
上面有一段代码用到了创建 `ThreadLocal` 变量的那段代码用到了 Java8 的知识，它等于下面这段代码，如果你写了下面这段代码的话，IDEA 会提示你转换为 Java8 的格式(IDEA 真的不错！)。因为 ThreadLocal 类在 Java 8 中扩展，使用一个新的方法`withInitial()`，将 Supplier 功能接口作为参数。
|
||
|
||
```java
|
||
private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
|
||
@Override
|
||
protected SimpleDateFormat initialValue(){
|
||
return new SimpleDateFormat("yyyyMMdd HHmm");
|
||
}
|
||
};
|
||
```
|
||
|
||
### ThreadLocal 原理了解吗？
|
||
|
||
从 `Thread`类源代码入手。
|
||
|
||
```java
|
||
public class Thread implements Runnable {
|
||
//......
|
||
//与此线程有关的ThreadLocal值。由ThreadLocal类维护
|
||
ThreadLocal.ThreadLocalMap threadLocals = null;
|
||
|
||
//与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
|
||
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
|
||
//......
|
||
}
|
||
```
|
||
|
||
从上面`Thread`类 源代码可以看出`Thread` 类中有一个 `threadLocals` 和 一个 `inheritableThreadLocals` 变量，它们都是 `ThreadLocalMap` 类型的变量,我们可以把 `ThreadLocalMap` 理解为`ThreadLocal` 类实现的定制化的 `HashMap`。默认情况下这两个变量都是 null，只有当前线程调用 `ThreadLocal` 类的 `set`或`get`方法时才创建它们，实际上调用这两个方法的时候，我们调用的是`ThreadLocalMap`类对应的 `get()`、`set()`方法。
|
||
|
||
`ThreadLocal`类的`set()`方法
|
||
|
||
```java
|
||
public void set(T value) {
|
||
Thread t = Thread.currentThread();
|
||
ThreadLocalMap map = getMap(t);
|
||
if (map != null)
|
||
map.set(this, value);
|
||
else
|
||
createMap(t, value);
|
||
}
|
||
ThreadLocalMap getMap(Thread t) {
|
||
return t.threadLocals;
|
||
}
|
||
```
|
||
|
||
通过上面这些内容，我们足以通过猜测得出结论：**最终的变量是放在了当前线程的 `ThreadLocalMap` 中，并不是存在 `ThreadLocal` 上，`ThreadLocal` 可以理解为只是`ThreadLocalMap`的封装，传递了变量值。** `ThrealLocal` 类中可以通过`Thread.currentThread()`获取到当前线程对象后，直接通过`getMap(Thread t)`可以访问到该线程的`ThreadLocalMap`对象。
|
||
|
||
**每个`Thread`中都具备一个`ThreadLocalMap`，而`ThreadLocalMap`可以存储以`ThreadLocal`为 key ，Object 对象为 value 的键值对。**
|
||
|
||
```java
|
||
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
|
||
//......
|
||
}
|
||
```
|
||
|
||
比如我们在同一个线程中声明了两个 `ThreadLocal` 对象的话， `Thread`内部都是使用仅有的那个`ThreadLocalMap` 存放数据的，`ThreadLocalMap`的 key 就是 `ThreadLocal`对象，value 就是 `ThreadLocal` 对象调用`set`方法设置的值。
|
||
|
||
`ThreadLocal` 数据结构如下图所示：
|
||
|
||
|
||
|
||
`ThreadLocalMap`是`ThreadLocal`的静态内部类。
|
||
|
||
|
||
|
||
### ThreadLocal 内存泄露问题是怎么导致的？
|
||
|
||
`ThreadLocalMap` 中使用的 key 为 `ThreadLocal` 的弱引用，而 value 是强引用。所以，如果 `ThreadLocal` 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。
|
||
|
||
这样一来，`ThreadLocalMap` 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。`ThreadLocalMap` 实现中已经考虑了这种情况，在调用 `set()`、`get()`、`remove()` 方法的时候，会清理掉 key 为 null 的记录。使用完 `ThreadLocal`方法后 最好手动调用`remove()`方法
|
||
|
||
```java
|
||
static class Entry extends WeakReference<ThreadLocal<?>> {
|
||
/** The value associated with this ThreadLocal. */
|
||
Object value;
|
||
|
||
Entry(ThreadLocal<?> k, Object v) {
|
||
super(k);
|
||
value = v;
|
||
}
|
||
}
|
||
```
|
||
|
||
**弱引用介绍：**
|
||
|
||
> 如果一个对象只具有弱引用，那就类似于**可有可无的生活用品**。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它 所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程， 因此不一定会很快发现那些只具有弱引用的对象。
|
||
>
|
||
> 弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。
|
||
|
||
## 参考
|
||
|
||
- 《深入理解 Java 虚拟机》
|
||
- 《实战 Java 高并发程序设计》
|
||
- Guide to the Volatile Keyword in Java - Baeldung：https://www.baeldung.com/java-volatile
|
||
- 理解 Java 中的 ThreadLocal - 技术小黑屋：https://droidyue.com/blog/2016/03/13/learning-threadlocal-in-java/
|
||
- ThreadLocal (Java Platform SE 8 ) - Oracle Help Center：https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html
|