Java并发常见面试题（三）

并发编程三大特性

原子性

一次操作或者多次操作，要么所有的操作都得到执行并且不受任何因素的干扰而中断，要么都不会执行。

在 Java 中，可以借助synchronized 、各种 Lock 以及各种原子类实现原子性。

synchronized 和各种 Lock 可以保证任一时刻只有一个线程访问该代码块，因此可以保障原子性。
各种原子类是利用 CAS (compare and swap) 操作（可能也会用到 volatile或者final关键字）来保证原子操作。
1
2
3
4

可见性

一个线程对共享变量进行修改，其他线程可以立即看到修改后的最新值。

在 Java 中，可以借助synchronized 、volatile 以及各种 Lock 实现可见性。

如果我们将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。
1
2
3

有序性

为了提高执行效率，程序在编译或者运行的时候会对代码进行指令重排序。指令重排序可以保证串行语义一致即在单线程中保证最终一致性，但是没有义务保证多线程间的语义也一致 ，所以在多线程下，指令重排序可能会导致一些问题。

在 Java 中，volatile 关键字可以禁止指令进行重排序优化。

volatile 关键字

volatile 关键字作用

1. 保证变量可见性（可见性）
2. 禁止指令重排序（有序性）

如何保证变量可见性？

在 Java 中，volatile 关键字可以保证变量的可见性，如果我们将变量声明为 volatile ，这就指示 JVM，这个变量是共享且不稳定的，每次使用它都到主存中进行读取，而不是从线程的本地缓存中读取。。

volatile 关键字其实并非是 Java 语言特有的，在 C 语言里也有，它最原始的意义就是禁用 CPU 缓存。如果我们将一个变量使用 volatile 修饰，这就指示 编译器，这个变量是共享且不稳定的，每次使用它都到主存中进行读取。

volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。

在Java中，每个线程都有自己的本地内存，线程之间的共享变量可能会被存储在本地内存中，而不是主存中。这就导致了线程之间的数据不一致问题。但是，如果我们将变量声明为volatile，就可以确保每个线程都从主存中读取最新的值，避免了线程之间的数据不一致问题。

如何禁止指令重排序？

在 Java 中，volatile 关键字除了可以保证变量的可见性，还有一个重要的作用就是防止 JVM 的指令重排序。 如果我们将变量声明为 volatile ，在对这个变量进行读写操作的时候，会通过插入特定的 内存屏障 的方式来禁止指令重排序。

为什么需要内存屏障：编译器和处理器指令重排只能保证在单线程执行下逻辑正确，在多个线程同时读写多个变量的情况下，如果不对指令重排作出一定
限制，代码的执行结果会根据指令重排后的顺序产生不同的结果。指令重排后的顺序每次执行时都可能不一样，显然我们希望我们的代码执行结果与代码
顺序是逻辑一致的（可能不太准确），所以我们需要内存屏障。
1
2
3

内存屏障

内存屏障是一种硬件或者软件机制，用于控制CPU对内存操作的顺序和可见性，它可以确保指令执行的顺序和内存访问的可见性，从而避免了多线程程序中的数据竞争问题。内存屏障通常包括以下几种类型：

1. Load Barrier：用于确保一个线程读取的数据来自于主内存而不是本地内存。

2. Store Barrier：用于确保一个线程写入的数据同步到主内存而不是本地内存。

3. Full Barrier：包含Load Barrier和Store Barrier，用于确保一个线程读取和写入的数据都同步到主内存而不是本地内存。

4. Store-Load Barrier：用于确保一个线程写入的数据先于后续的读取操作，避免了指令重排问题。

禁止指令重排原理是基于内存屏障机制的。在Java中，为了提高程序的性能，编译器和处理器可能会对指令进行重排，从而优化程序的执行顺序。但是，在多线程环境下，指令重排可能会导致程序出现意想不到的问题，因此需要禁止指令重排。Java中提供了volatile关键字和synchronized关键字来禁止指令重排。

当一个变量被声明为volatile时，在读取和写入变量时，会使用内存屏障机制来确保变量的值的可见性和顺序性。具体来说，读取变量时，会插入Load Barrier，确保读取的数据来自于主内存而不是本地内存；写入变量时，会插入Store Barrier，确保写入的数据同步到主内存而不是本地内存。这样可以避免指令重排，保证变量的值的正确性和可见性。

当一个代码块被synchronized关键字修饰时，会使用内存屏障机制来确保代码块的原子性、可见性和顺序性。具体来说，在进入synchronized代码块前，会插入一个Lock Barrier，确保代码块的执行顺序和可见性；在退出synchronized代码块时，会插入一个Unlock Barrier，确保代码块的原子性和可见性。这样可以避免指令重排，保证代码块的正确性和可见性。

具体来说，当编译器进行指令重排时，会考虑到指令之间的依赖关系，如果不存在依赖关系，则可能会重排指令的执行顺序，以提高程序的执行效率。然而，对于volatile变量的读写操作，编译器必须保证这些操作的顺序性，不能将其与其他指令重排，否则会导致程序出现意外的结果。因此，编译器会在对volatile变量进行读写操作时，插入Load Barrier和Store Barrier，以确保这些操作的顺序性和可见性。这样就可以禁止指令重排，保证volatile变量的值的正确性和可见性。
处理器也会进行指令重排，同样需要考虑到指令之间的依赖关系。当处理器执行一条Load指令时，如果没有Load Barrier的限制，它可能会从本地内存中读取数据，而不是从主内存中读取数据。同样，当处理器执行一条Store指令时，如果没有Store Barrier的限制，它可能会将数据写入本地内存，而不是主内存。这些操作可能会导致程序出现意外的结果。因此，处理器也会在执行Load和Store指令时，根据内存屏障的类型，确保数据的顺序性和可见性，避免指令重排的问题。

具体来说，当编译器进行指令重排时，会考虑到指令之间的依赖关系，如果不存在依赖关系，则可能会重排指令的执行顺序，以提高程序的执行效率。然而，对于volatile变量的读写操作，编译器必须保证这些操作的顺序性，不能将其与其他指令重排，否则会导致程序出现意外的结果。因此，编译器会在对volatile变量进行读写操作时，插入Load Barrier和Store Barrier，以确保这些操作的顺序性和可见性。这样就可以禁止指令重排，保证volatile变量的值的正确性和可见性。
处理器也会进行指令重排，同样需要考虑到指令之间的依赖关系。当处理器执行一条Load指令时，如果没有Load Barrier的限制，它可能会从本地内存中读取数据，而不是从主内存中读取数据。同样，当处理器执行一条Store指令时，如果没有Store Barrier的限制，它可能会将数据写入本地内存，而不是主内存。这些操作可能会导致程序出现意外的结果。因此，处理器也会在执行Load和Store指令时，根据内存屏障的类型，确保数据的顺序性和可见性，避免指令重排的问题。

实际案例——双重检测锁实现单例模式

单例模式是指在内存中只会创建且仅创建一次对象的设计模式。在程序中多次使用同一个对象且作用相同时，为了防止频繁地创建对象使得内存飙升，单例模式可以让程序仅在内存中创建一个对象，让所有需要调用的地方都共享这一单例对象。

总结：单例模式顾名思义就是单例类只能有一个实例，且该类需自行创建这个实例，并对其他的类提供调用这一实例的方法。

public class SingletonByDoubleCheckLock {

    /**
     * 私有实例,初始化的时候不加载（延迟加载/懒加载）,使用volatile关键字,禁止指令重排序
     */
    private volatile static SingletonByDoubleCheckLock singleton;

    /**
     * 私有构造
     */
    private SingletonByDoubleCheckLock(){}

    /**
     * 唯一公开获取实例的方法
     *
     * @return
     */
    public static SingletonByDoubleCheckLock getInstance() {
        if (singleton == null) {  // 线程A和线程B同时看到singleton = null，如果不为null，则直接返回singleton
            synchronized(SingletonByDoubleCheckLock.class) { // 线程A或线程B获得该锁进行初始化
                if (singleton == null) { // 其中一个线程进入该分支，另外一个线程则不会进入该分支
                    singleton = new SingletonByDoubleCheckLock();
                }
            }
        }
        return singleton;
    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

关于单例模式以及为什么这样实现的详解解读，请移步观看我的另一篇博客——Java常见设计模式总结——单例模式

volatile 可以保证原子性么？

volatile 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。

代码测试

public class VolatileAtomicityTest {
    public volatile static int num = 0;

    public void increase() {
        num++;
    }

    public static void main(String[] args) throws InterruptedException {
        ExecutorService threadPool = Executors.newFixedThreadPool(5);
        VolatileAtomicityTest volatileAtomicityTest = new VolatileAtomicityTest();
        for (int i = 0; i < 5; i++) {
            threadPool.execute(() -> {
                for (int j = 0; j < 500; j++) {
                    volatileAtomicityTest.increase();
                }
            });
        }

        // 等待1.5秒，保证上面程序执行完成
        Thread.sleep(1500);

        System.out.println(num);

        threadPool.shutdown();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

如果volatile关键字可以保证变量操作的原子性，那么上述代码的运行结果应该是2500，但实际运行结果总是小于2500。

num++ 其实是一个复合操作，包括三步：

1. 读取 num 的值。
2. 对 num 加 1。
3. 将 num 的值写回内存。

volatile 是无法保证这三个操作是具有原子性的，有可能导致下面这种情况出现：

1. 线程 1 对 num = 1 进行读取操作之后，还未对其进行修改。线程 2 又读取了 num = 1 的值并对其进行修改（+1），然后将 num = 2 的值写回内存。
2. 线程 2 操作完毕后，线程 1 对 num = 1 （在线程2没有操作之前读取到的） 的值进行修改（+1），然后将 num = 2 的值写回内存。
3. 这也就导致两个线程分别对 num 进行了一次自增操作后，num 实际上只增加了 1，即最终 num = 2。

代码改进

方案一：使用 syncronized 关键字改进

public synchronized void increase() {
    num++;
}

1
2
3
4

方案二：使用 AtomicInteger 改进

public static AtomicInteger num = new AtomicInteger();

public void increase() {
    num.getAndIncrement();
}

1
2
3
4
5
6

方案三：使用 ReentrantLock 改进

Lock lock = new ReentrantLock();
public void increase() {
    lock.lock();
    try {
        num++;
    } finally {
        lock.unlock();
    }
}
1
2
3
4
5
6
7
8
9

synchronized 关键字

说一说你对 synchronized 关键字的理解？

synchronized 翻译成中文是同步的的意思，主要解决的是多个线程之间访问资源的同步性，可以保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。

在 Java 早期版本中，synchronized 属于 重量级锁，效率低下。 因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，Java 的线程是映射到操作系统的原生线程之上的。如果要挂起或者唤醒一个线程，都需要操作系统帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高。

不过，在 Java 6 之后，Java 官方从 JVM 层面对 synchronized 进行了较大的优化，所以现在的 synchronized 锁效率也优化得很不错了。JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。所以，你会发现目前的话，不论是各种开源框架还是 JDK 源码都大量使用了 synchronized 关键字。

如何使用 synchronized 关键字

应用场景总结

1. 作用于非静态方法，锁住的是对象实例（this），每一个对象实例有一个锁。

public synchronized void method() {}
1

2. 作用于静态方法，锁住的是类的 Class 对象，Class 对象全局只有一份，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程。

public static synchronized void method() {}
1

3. 作用于 Lock.class，锁住的是 Lock 的 Class 对象，也是全局只有一个。

synchronized (Lock.class) {}
1

4. 作用于 this，锁住的是对象实例，每一个对象实例有一个锁。

synchronized (this) {}
1

5. 作用于静态成员变量，锁住的是该静态成员变量对象，由于是静态变量，因此全局只有一个。

public static Object monitor = new Object(); 
synchronized (monitor) {}
1
2

总结：

1. 必须有“对象”来充当“锁”的角色。
2. 对于同一个类来说，通常只有两种对象来充当锁：实例对象、Class 对象（一个类全局只有一份）。
   • Class 对象：静态相关的都是属于 Class 对象，还有一种直接指定 Lock.class。
   • 实例对象：非静态相关的都是属于实例对象

Class对象

在Java中，每个类在JVM中都有一个唯一的Class对象与之对应，用于描述该类的类型信息，例如类的名称、访问修饰符、父类信息、实现的接口信息等。Class对象是一个非常重要的对象，它是Java反射机制的基础，也是Java虚拟机在类加载过程中的关键数据结构之一。

Class对象的创建是在类加载的过程中完成的，当类被第一次使用时，JVM会从磁盘中将该类的字节码加载到内存中，并创建一个对应的Class对象，存储该类的类型信息。每个Class对象都对应着一个具体的类，包含了该类的所有信息，例如：类的成员变量、成员方法、构造方法、静态代码块、注解等等。

Class对象是一个非常重要的对象，它的作用远不止于反射机制的支持，还可以用于实现类加载器的缓存，动态代理、字节码增强等高级特性，因此，深入理解Class对象是Java开发中必须掌握的知识点。

最主要的三种应用场景

1. 修饰实例方法

2. 修饰静态方法

3. 修饰代码块

1、修饰实例方法 （锁当前对象实例）

给当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁 。

synchronized void method() {
    //业务代码
}
1
2
3
4

2、修饰静态方法 （锁当前类）

给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。

这是因为静态成员不属于任何一个实例对象，归整个类所有，不依赖于类的特定实例，被类的所有实例共享。

synchronized static void method() {
    //业务代码
}
1
2
3

静态 synchronized 方法和非静态 synchronized 方法之间的调用互斥么？不互斥！如果一个线程 A 调用一个实例对象的非静态 synchronized 
方法，而线程 B 需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用
的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。
1
2
3

3、修饰代码块 （锁指定对象/类）

对括号里指定的对象/类加锁：

• synchronized(object) 表示进入同步代码库前要获得 给定对象的锁。
• synchronized(类.class) 表示进入同步代码前要获得 给定 Class 的锁

synchronized() {
    //业务代码
}
1
2
3

总结：

• synchronized 关键字加到 static 静态方法和 synchronized(类.class) 代码块上都是是给 Class 类上锁；
• synchronized 关键字加到实例方法上是给对象实例上锁；
• 尽量不要使用 synchronized(String a) 因为 JVM 中，字符串常量池具有缓存功能。

构造方法可以使用 synchronized 关键字修饰么？

构造方法不能使用 synchronized 关键字修饰。

构造方法本身就属于线程安全的，不存在同步的构造方法一说。

讲一下 synchronized 关键字的底层原理

synchronized 关键字底层原理属于 JVM 层面。

synchronized 同步语句块的情况

public class TestA {
    public void method() {
        synchronized (this) {
            System.out.println("synchronized 代码块");
        }
    }
}

1
2
3
4
5
6
7
8

翻译成字节码：

public method()V
    TRYCATCHBLOCK L0 L1 L2 null
    TRYCATCHBLOCK L2 L3 L2 null
   L4
    LINENUMBER 5 L4
    ALOAD 0
    DUP
    ASTORE 1
    MONITORENTER 
   L0
    LINENUMBER 6 L0
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    LDC "synchronized \u4ee3\u7801\u5757"
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/String;)V
   L5
    LINENUMBER 7 L5
    ALOAD 1
    MONITOREXIT
   L1
    GOTO L6
   L2
   FRAME FULL [com/lzl/algorithm/test12/TestA java/lang/Object] [java/lang/Throwable]
    ASTORE 2
    ALOAD 1
    MONITOREXIT
   L3
    ALOAD 2
    ATHROW
   L6
    LINENUMBER 8 L6
   FRAME CHOP 1
    RETURN
   L7
    LOCALVARIABLE this Lcom/lzl/algorithm/test12/TestA; L4 L7 0
    MAXSTACK = 2
    MAXLOCALS = 3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

从上面我们可以看出：synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

当执行 monitorenter 指令时，线程试图获取锁也就是获取 对象监视器 monitor 的持有权。

在 Java 虚拟机(HotSpot)中，Monitor 是基于 C++实现的，由ObjectMonitor实现的。每个对象中都内置了一个 ObjectMonitor对象。

另外，wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，
否则会抛出java.lang.IllegalMonitorStateException的异常的原因
1
2
3
4

在执行monitorenter时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。

对象锁的的拥有者线程才可以执行 monitorexit 指令来释放锁。在执行 monitorexit 指令后，将锁计数器设为 0，表明锁被释放，其他线程可以尝试获取锁。

如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被拥有锁的线程释放为止。

synchronized 修饰方法的的情况

public class TestA {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}
1
2
3
4
5

翻译成字节码：
通过 JDK 自带的 javap 命令查看 TestA 类的相关字节码信息：首先切换到类的对应目录执行 javac TestA.java 命令生成编译后的 .class 文件，然后执行javap -c -s -v -l TestA.class。

public synchronized void method();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #3                  // String synchronized 鏂规硶
         5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 5: 0
        line 6: 8

1
2
3
4
5
6
7
8
9
10
11
12
13

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。JVM 通过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。

如果是实例方法，JVM 会尝试获取实例对象的锁。如果是静态方法，JVM 会尝试获取当前 class 的锁。

总结

synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代码块的开始位置，monitorexit 指令则指明同步代码块的结束位置。

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。

不过两者的本质都是对对象监视器 monitor 的获取。

JDK1.6 之后的 synchronized 关键字底层做了哪些优化？

JDK1.6 对锁的实现引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。

锁主要存在四种状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

1. 优化了锁的获取和释放机制
   在JDK1.6之前，synchronized关键字的实现采用的是重量级锁（也称为互斥量），每次获取锁都需要进入内核态，这种方式效率较低。JDK1.6之后，Java引入了偏向锁、轻量级锁和重量级锁三种锁的状态，根据锁对象竞争的情况自动升级或降级锁的状态，从而提高锁的获取和释放效率。

2. 优化了对象监视器的实现
   在JDK1.6之前，每个Java对象都会有一个监视器（monitor）与之关联，用于实现synchronized关键字的同步功能。在JDK1.6之后，Java对对象监视器的实现进行了优化，使用了一种基于管程的模型，用于实现线程的同步和互斥。这种模型将对象的监视器和对象本身分离开来，减少了锁的竞争，从而提高了程序的并发性能。

总的来说，JDK1.6之后，Java对synchronized关键字的实现进行了一系列的优化，提高了程序的并发性能和效率。但是，在多线程编程中，使用synchronized关键字还是需要谨慎，需要遵循一定的规范和约束，才能保证线程安全和程序的正确性。

优化了对象监视器的实现

在JDK1.6之前，每个Java对象都会有一个监视器（monitor）与之关联，用于实现synchronized关键字的同步功能。在JDK1.6之后，Java对对象监视器的实现进行了优化，使用了一种基于管程的模型，用于实现线程的同步和互斥。

具体来说，Java使用了一种叫做“对象内部锁”（Intrinsic Lock）的机制来实现synchronized关键字的同步功能。每个Java对象都有一个内部锁，也称为监视器锁（Monitor Lock），用于控制对该对象的并发访问。当一个线程获取了该对象的内部锁，其他线程就无法访问该对象，直到该线程释放了该对象的内部锁。

Java的对象内部锁是基于管程（Monitor）实现的。每个Java对象都与一个Monitor关联，Monitor包含了该对象的内部锁和等待队列。在Java虚拟机中，每个Monitor都有一个Owner字段，用于记录当前持有该Monitor的线程。当一个线程获取了该对象的内部锁时，该线程就成为了该Monitor的Owner，其他线程就无法获得该对象的内部锁。如果有其他线程试图获取该对象的内部锁，就会被放入该Monitor的等待队列中，等待Owner线程释放内部锁后再次竞争。

这几种优化的详细信息可以查看这篇文章——Java6 及以上版本对 synchronized 的优化。

synchronized 和 volatile 的区别

synchronized 关键字和 volatile 关键字是两个互补的存在，而不是对立的存在。

• volatile 关键字是线程同步的轻量级实现，所以 volatile性能肯定比synchronized关键字要好 。但是 volatile 关键字只能用于变量而 synchronized 关键字可以修饰方法以及代码块 。
• volatile 关键字能保证数据的可见性，但不能保证数据的原子性。synchronized 关键字两者都能保证。
• volatile关键字主要用于解决变量在多个线程之间的可见性，而 synchronized 关键字解决的是多个线程之间访问资源的同步性。

synchronized 常见面试题总结

为什么有Synchronized？

在多线程编程中，有时候需要保证多个线程对某个共享资源（如变量、方法或对象）的访问是互斥的，即同一时刻只能有一个线程访问该资源，其他线程需要等待。这种情况下，就需要使用同步机制来实现线程的同步和互斥。

Synchronized是Java提供的一种同步机制，它能够保证在同一时刻只有一个线程能够进入synchronized代码块或方法，从而避免了多个线程同时访问共享资源的问题，保证了线程安全和程序的正确性。

synchronized 这三种加锁方式（作用对象：静态方法、非静态方法、代码块）作用范围的区别？

在Java中，synchronized关键字可以用于三种不同的锁定方式，分别是锁定静态方法、锁定非静态方法和锁定代码块。它们各自的作用范围如下：

1. 锁定静态方法
   使用synchronized修饰的静态方法，锁定的是整个类的对象，作用范围是该类的所有实例对象。也就是说，当多个线程同时调用该类的不同实例对象的同一个静态方法时，它们会被阻塞，直到该方法执行完毕。而当多个线程同时调用该类的同一个实例对象的静态方法时，它们也会被阻塞，直到该方法执行完毕。

2. 锁定非静态方法
   使用synchronized修饰的非静态方法，锁定的是该对象本身，作用范围是该对象的所有同步方法和同步代码块。也就是说，当多个线程同时调用该对象的同步方法时，它们会被阻塞，直到该方法执行完毕。而当多个线程同时调用该对象的非同步方法时，它们不会被阻塞，可以同时执行。

3. 锁定代码块
   使用synchronized修饰的代码块，锁定的是该对象本身或指定的对象，作用范围是该代码块内部的所有代码。也就是说，当多个线程同时调用该对象的同步代码块时，它们会被阻塞，直到该代码块执行完毕。而当多个线程同时调用该对象的非同步代码块时，它们不会被阻塞，可以同时执行。

综上所述，synchronized关键字可以用于三种不同的锁定方式，它们的作用范围不同，分别是整个类的对象、该对象本身和该代码块内部的所有代码。应该根据具体情况选择适合的锁定方式。

Synchronized修饰的方法在抛出异常时,会释放锁吗?

当使用Synchronized修饰的方法在执行过程中出现异常时，JVM会自动释放该线程所持有的锁，以确保不会出现死锁的情况。这是因为Synchronized是基于锁的机制，在同步方法或同步代码块中的锁对象在锁定期间是被当前线程所持有的，当出现异常时，如果不释放锁对象，其他线程就永远无法获取到该锁，从而导致死锁。

当出现异常时，JVM会自动将该线程所持有的锁释放，以确保其他线程可以获取到该锁，继续执行相应的代码块，从而避免了死锁的情况。这种机制称为锁的释放。需要注意的是，锁的释放是自动发生的，程序员不需要手动编写相关代码来释放锁。

总之，当使用Synchronized修饰的方法在执行过程中出现异常时，JVM会自动释放该线程所持有的锁，以确保不会出现死锁的情况。

synchronized 是公平锁还是非公平锁？

非公平，新来的线程有可能立即获得监视器，而在等待区中等候已久的线程可能再次等待，不过这种抢占的方式可以预防饥饿。

使用synchronized关键字实现非公平锁机制时，新来的线程有机会在等待较短的时间内获得锁，而等待时间较长的线程可能需要再次等待。虽然这可能会导致某些线程等待时间较长，但是由于新来的线程可以在较短的时间内获得锁，从而避免了某些线程长时间无法获取锁的情况。这种情况下，所有线程都有机会获取锁，而不会出现某些线程长时间无法获取锁的情况，从而预防了饥饿的发生。

饥饿是指某些线程由于一些原因，如优先级太低、锁分配不公平等，长时间无法获取到锁或资源，从而无法执行或执行效率低下。使用非公平锁机制可以避免某些线程长时间无法获取锁的情况，从而预防了饥饿的发生。

需要注意的是，非公平锁机制并不能完全避免饥饿的发生，某些线程仍然可能由于等待时间过长而无法获取锁或资源，从而发生饥饿。为了避免饥饿的发生，可以采用一些措施，如优先级调度、公平锁机制等。

synchronized底层源码如何实现

1. synchronized 修饰代码块，是通过 monitorenter 和 monitorexit 指令实现的
在代码块上使用synchronized关键字实现锁定时，Java编译器会在编译时将synchronized关键字转化成monitorenter和monitorexit指令，实现对代码块的加锁和解锁操作。其中，monitorenter指令会获取对象的锁，并将锁计数器加1，而monitorexit指令会释放对象的锁，并将锁计数器减1。

2. synchronized 修饰方法，是在方法访问标志（flags）中添加 ACC_SYNCHRONIZED 标志，表示该方法是同步方法
在静态方法和实例方法上使用synchronized关键字实现锁定时，Java虚拟机会在方法的访问标志（flags）中添加ACC_SYNCHRONIZED标志，表示该方法是同步方法。当线程调用该方法时，Java虚拟机会自动获取该方法所属对象的锁，并在方法执行结束时释放该锁，实现对该方法的加锁和解锁操作。
需要注意的是，无论是在代码块上还是在方法上使用synchronized关键字实现锁定，都会涉及到锁的获取和释放操作，这是保证同步代码块或同步方法的线程安全的关键。

synchronized本质上是通过什么保证线程安全的?

1. 原子性
   互斥锁：通过 monitorenter 和 monitorexit 、ACC_SYNCHRONIZED 实现，保证同一时刻只有一个线程进入同步代码块或同步方法。

2. 可见性
   当线程进入同步代码块时，它会首先获取该对象的锁，然后清空工作内存中该对象的值，并从主内存中重新读取该对象的值到工作内存中。当线程执行完同步代码块并释放锁时，会将工作内存中该对象的值刷新到主内存中，从而使得其他线程可以看到该对象最新的值。

3. 有序性
   Acquire 屏障和 Release 屏障的作用，同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。

在 Java 中，synchronized 通过内存屏障（Memory Barrier）来保证多线程之间的可见性、有序性和原子性。具体来说，synchronized 会在同步块的进入和退出时分别插入 Acquire 屏障和 Release 屏障，从而保证了同步代码块内部指令的有序性和内存的可见性。

Acquire 屏障和 Release 屏障是内存屏障的两种类型。Acquire 屏障用于确保一个线程读取共享变量时，它所依赖的所有数据都已经从主内存中读取到了线程的工作内存中。Release 屏障用于确保一个线程写入共享变量时，它所修改的数据都已经写入了主内存中。

具体来说，当一个线程进入 synchronized 同步块时，它会执行 Acquire 屏障，从而确保它所依赖的数据都已经从主内存中读取到了线程的工作内存中。在同步块中，线程可以对共享变量进行读写操作，但是这些操作只在线程的工作内存中有效，而不会立即写入主内存。当线程执行完同步块并释放锁时，它会执行 Release 屏障，从而将线程工作内存中修改过的共享变量的值刷新到主内存中。其他线程在读取共享变量时，必须先执行 Acquire 屏障，从而确保它们读取的是最新的值。同样，当其他线程修改共享变量时，必须先执行 Release 屏障，从而确保它们修改的值能够被其他线程看到。

由于 Acquire 屏障和 Release 屏障的作用，synchronized 可以保证同步代码块内部的指令是按照顺序执行的。具体来说，当一个线程进入 synchronized 同步块时，它会执行 Acquire 屏障，从而确保它所依赖的数据都已经从主内存中读取到了线程的工作内存中，然后执行同步块中的指令。同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。当线程执行完同步块并释放锁时，它会执行 Release 屏障，从而将线程工作内存中修改过的共享变量的值刷新到主内存中。其他线程在读取共享变量时，必须先执行 Acquire 屏障，从而确保它们读取的是最新的值。同样，当其他线程修改共享变量时，必须先执行 Release 屏障，从而确保它们修改的值能够被其他线程看到。

而代码块内部和代码块外部的指令是不能重排的。具体来说，在同步块之前或之后的指令与同步块内部的指令之间不存在数据依赖关系，因此编译器和处理器可以对它们进行重排，以提高程序的性能。但是，由于 Acquire 屏障和 Release 屏障的作用，同步块内部的指令必须按照程序的原有顺序执行，不能进行重排。 这样可以避免出现线程安全问题，保证多线程之间的可见性、有序性和原子性。

为什么 monitorexit 指令出现了两次？（可以参考上文的源码）

monitorexit指令在同步代码块中正常退出时会出现一次，释放对象的锁定；在发生异常退出时也会出现一次，即在异常处理器中释放对象的锁定。因此，monitorexit指令会出现两次。

synchronized 可重入原理底层实现？

在Java中，每个对象都有一个监视器锁（monitor），也称为内部锁或对象锁。当一个线程尝试获取一个对象锁时，它会进入该对象的监视器锁的等待队列中。如果该对象的监视器锁已经被其他线程持有，则该线程将被阻塞，直到其他线程释放了该对象的监视器锁。
当一个线程调用一个 synchronized 方法时，它会自动获取该方法所属对象的监视器锁。如果同一个线程再次调用该对象的另一个 synchronized 方法，它会再次获取该对象的监视器锁，而不会被阻塞。这就是 synchronized 可重入原理。

在底层实现上，每个Java对象都有一个关联的监视器对象（monitor object），也称为对象的管程（monitor），它用于实现对象的同步和互斥。当一个线程进入 synchronized 代码块时，它会获取该对象的监视器对象的所有权，并将该对象的监视器对象标记为“锁定”状态。如果同一个线程再次进入该对象的 synchronized 代码块，它会再次获取该对象的监视器对象的所有权，并将该对象的监视器对象的“锁定”状态计数器加1。当同一个线程退出 synchronized 代码块时，它会将该对象的监视器对象的“锁定”状态计数器减1。只有当“锁定”状态计数器为0时，该对象的监视器对象才会被释放，其他线程才能获取该对象的监视器对象的所有权。

在Java虚拟机中，每个对象都有一个与之关联的监视器对象，该对象包含了以下信息：

1. 持有该对象监视器锁的线程；

2. 等待该对象监视器锁的线程队列；

3. 一个计数器，用于记录某个线程重入该对象监视器锁的次数。

当一个线程获取了一个对象的监视器锁时，它会将该对象的监视器锁的计数器加1，并将自己添加到该对象的等待队列中。如果该对象的监视器锁已经被其他线程持有，则当前线程将被阻塞，并等待其他线程释放该对象的监视器锁。当持有该对象监视器锁的线程退出 synchronized 代码块时，它会将该对象的监视器锁的计数器减1，并检查是否还有其他线程在等待该对象的监视器锁。如果有，则从等待队列中唤醒一个线程来获取该对象的监视器锁。如果没有，则该对象的监视器锁将被释放，并且其他线程可以获取该对象的监视器锁。

在并发时，程序的执行可能会出现乱序，直观感觉前面的代码，会在后面执行，为什么？

这是因为计算机在执行程序时候，为了提高代码、指令的执行效率，编译器和处理器会对指令进行重新排序，指令重排序可以保证串行（单线程）语义一致，但是没有义务保证多线程间的语义也一致 ，所以在多线程下，指令重排序可能会导致一些问题。

JDK 6 以前 synchronized 为什么这么重？

在JDK 6及之前的版本中，synchronized是通过操作系统级别的互斥锁（重量级锁）来实现的，这种方式需要进行用户态和内核态之间的切换，非常消耗系统资源，因此会导致很重的性能损失。

JDK 6 之后 synchronized 做了哪些优化?

JDK 6 以后，synchronized 做了如下优化：

1.引入轻量级锁和偏向锁

轻量级锁：在锁竞争不激烈的情况下，采用轻量级锁，避免了用户态和内核态之间的切换，提高了锁的获取和释放的效率，从而提高了程序的执行效率和性能。

偏向锁：在单线程环境下，采用偏向锁，避免了多线程竞争的开销，提高了程序的执行效率和性能。

2.自适应的自旋锁

在锁竞争激烈的情况下，采用自适应的自旋锁，避免了频繁的线程切换和上下文切换，提高了程序的执行效率和性能。

3.锁粗化

将多个连续的加锁和解锁操作合并成一个大的锁操作，避免了频繁的加锁和解锁操作，提高了程序的执行效率和性能。

4.锁消除

在 JIT 编译时，对于一些不可能存在共享资源竞争的锁，可以将其消除掉，避免了无谓的锁操作，提高了程序的执行效率和性能。

5.自旋锁中的锁消除

在自旋锁的实现中，如果进行自旋的时间很短，那么就没有必要使用锁，可以直接使用原子操作来保证数据的一致性，避免了无谓的锁操作。

总的来说，JDK 6 以后的版本对 synchronized 做了很多优化，从锁的实现方式、锁的粒度、锁的优化策略等方面进行了改进，从而提高了程序的执行效率和性能。

synchronized 锁升级过程详细介绍

synchronized 锁升级过程可以分为以下几个阶段：

1. 偏向锁阶段（Biased Locking）：默认情况下，对象的 Mark Word 中的锁标志位是未锁定状态。当第一个线程访问对象时，JVM 会将对象的 Mark Word 中的锁标志位设置为偏向锁，并将线程 ID 记录在对象的 Mark Word 中。之后，当同一个线程再次访问该对象时，无需进行锁的操作，可以直接访问。这个过程称为偏向锁。偏向锁只针对单线程场景，如果有其他线程访问该对象，则需要执行锁升级过程。

2. 轻量级锁阶段（Lightweight Locking）：是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

3. 重量级锁阶段：若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。重量级锁是指，JVM 会将对象的 Mark Word 中的锁标志位设置为“指向互斥量的指针”，此时，线程在访问对象时需要进行阻塞等待。当其他线程释放锁时，JVM 会唤醒等待的线程，然后再次尝试获取锁。

需要注意的是，锁升级过程是不可逆的，即锁从偏向锁升级到轻量级锁后，就不能再回到偏向锁的状态。同样的，锁从轻量级锁升级到重量级锁后，也不能再回到轻量级锁的状态。因此，在使用 synchronized 时需要根据实际情况进行选择，避免不必要的锁升级操作，提高程序的执行效率和性能。

如何提高 synchronized 并发性能？

以下是提高 synchronized 并发性能的几种方法：

1. 减小同步代码块的范围：只在必要的代码段内使用 synchronized 块，这样可以减少锁的竞争和等待时间。

2. 使用更轻量级的锁：Java 5 中引入了更轻量级的锁，例如 ReentrantLock 和 ConcurrentHashMap，可以比使用 synchronized 关键字更好地控制并发访问。

3. 减小锁的持有时间：尽可能缩短 synchronized 块内部的执行时间，以减少其他线程等待锁的时间。

4. 使用乐观锁：对于读多写少的情况，可以使用乐观锁（Optimistic Locking），例如AtomicInteger 和 AtomicLong 等类。

5. 避免死锁：在设计多线程程序时，应避免出现死锁问题，因为死锁会降低系统的性能。

6. 优化程序结构：优化程序的结构以减少共享资源的竞争，例如将共享数据分割成多个不同的数据结构或对象，每个对象都有自己的锁，这样就可以减少锁的竞争。

使用 synchronized 关键字需要注意什么？

使用Synchronized关键字需要注意以下几点：

1. Synchronized关键字只能修饰方法或代码块，不能修饰变量或类。

2. 当多个线程访问同一个被synchronized修饰的代码块时，其中只有一个线程能够执行该代码块，其他线程必须等待。因此，使用synchronized会造成线程阻塞，降低了程序的并发性能。

3. 在使用synchronized时，要确保锁对象的唯一性。如果多个线程尝试获取不同的锁对象，那么它们将无法同步互斥地访问共享资源。

4. 由于synchronized关键字是Java语言提供的一种内置锁机制，因此使用它的性能相对较差。在高并发情况下，可以考虑使用基于CAS操作的锁机制（如ReentrantLock）来代替synchronized。

5. 锁对象不能为空，锁对象的信息是保留在对象头中的，如果对象为空，则锁的信息也就不存在了。

6. 作用域不宜过大，如果把过多的代码放在其中，程序的运行会变为串行，速度会下降。 把那些影响线程安全的代码串行执行；不需要线程安全代码并行执行，达到效率最高。

7. 避免死锁，在设计多线程程序时，应避免出现死锁问题，因为死锁会降低系统的性能。

synchronized 有什么缺陷?

synchronized 是 Java 中用于实现线程同步的机制，但它也有一些缺陷：

1. 性能问题：synchronized 的实现是基于独占锁（互斥锁）的，当多个线程需要竞争同一资源时，会导致性能瓶颈。由于独占锁的机制，只有获得锁的线程才能执行，其他线程则需要等待，这样线程间切换的开销会很大。

2. 可重入性问题：synchronized 是可重入锁，即同一个线程重复调用 synchronized 修饰的方法或代码块时，能够自动获取锁。这种机制很好，但是如果控制不好，可能会导致死锁。

3. 无法中断问题：当一个线程进入 synchronized 块时，其他线程只能等待，无法中断其操作，这可能会导致线程阻塞。

4. 单一性问题：synchronized 每次只能锁住一个对象，这限制了其在并发场景下的灵活性。

5. 可见性问题：synchronized 只能保证在同步块内的操作是原子的，但是无法保证在同步块外的操作是否可见。如果一个线程修改了共享变量的值，其他线程并不一定能马上看到这个变化（同步代码块执行结束后才后悔将工作内存中的值刷新到主内存中）。(结合 volatile 使用)

综合来看，Synchronized 还是一种比较可靠的线程同步机制，但是在高并发场景下可能会存在比较明显的性能问题。为了解决这些问题，Java 提供了其他的并发控制工具，如 Lock、Semaphore、ReadWriteLock 等。

Synchronized 和 Lock 的区别

Synchronized 和 Lock 都是 Java 中用于实现线程同步的机制，它们的核心目的是相同的，但它们在实现上有一些区别。

实现方式：Synchronized 是 Java 内置的关键字，而 Lock 是 Java.util.concurrent （J.U.C）包提供的类。Synchronized 是隐式锁，JVM 会自动实现其加锁和解锁操作；而 Lock 必须通过 lock() 方法手动加锁，并且必须通过 unlock() 方法手动解锁。

可中断性：Synchronized 是不可中断锁，即一个线程进入 Synchronized 块后，其他线程无法强制终止这个线程的操作。而 Lock 是可中断锁，即可以通过 lockInterruptibly() 方法让等待的线程响应中断信号。

阻塞方式：Synchronized 是非公平锁，线程在等待锁时，采用的是“偏向锁”、“轻量级锁”、“重量级锁”三种不同的机制，其中“偏向锁”和“轻量级锁”都是采用自旋的方式进行阻塞等待；而 Lock 可以使用公平锁或非公平锁，公平锁是按照线程请求的顺序进行加锁，非公平锁则是直接尝试加锁，哪个线程先获取到锁就让哪个线程执行。

粒度：Synchronized 的粒度比 Lock 要粗，Synchronized 的加锁和解锁同步的范围是整个方法或者语句块，而 Lock 可以实现更细粒度的锁控制。

性能：在 JDK5.0 之前，Synchronized 的性能比 Lock 差。但随着 JDK5.0 的推出，Synchronized 的实现已经更新，性能得到了很大的提高，与 Lock 的性能相差不大，甚至在特定情况下 Synchronized 的性能还比 Lock 更优秀。

总体来说，Synchronized 自带锁、锁粒度较大，实现比较简单，但灵活性较差；而 Lock 是可中断、可多条件、可选择公平/非公平锁等，并且它具有较高的灵活性，但是需要手动加锁、解锁，需要考虑的因素也相对较多。根据实际的情况和需求，选择适合的同步机制才能更好地进行并发编程。

synchronized 和 ReentrantLock（Lock 的一个实现类） 的区别

两者都是可重入锁

“可重入锁” 指的是自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果是不可重入锁的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增 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实例中的所有等待线程。
1
2
3
4
5
6
7
8
9
10

ThreadLocal

ThreadLocal 有什么用？

通常情况下，我们创建的变量是可以被任何一个线程访问并修改的。如果想实现每一个线程都有自己的专属本地变量该如何解决呢？

JDK 中自带的ThreadLocal类正是为了解决这样的问题。 ThreadLocal类主要解决的就是让每个线程绑定自己的值，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可以使用 get() 和 set() 方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。

再举个简单的例子：两个人去宝屋收集宝物，这两个共用一个袋子的话肯定会产生争执，但是给他们两个人每个人分配一个袋子的话就不会出现这样的问题。如果把这两个人比作线程的话，那么 ThreadLocal 就是用来避免这两个线程竞争的

你知道“自旋锁”是做什么的吗？它的使用场景是什么？

自旋锁是尝试获取锁的线程不会立即阻塞，采用循环的方式去获取锁，好处是减少了上下文切换，缺点是消耗cpu，适用于锁竞争不激烈，且占用锁时间非常短的情况。

自旋锁:竞争锁的失败的线程，并不会真实的在操作系统层面挂起等待，而是JVM会让线程做几个空循环(基于预测在不久的将来就能获得)，在经过若干次循环后，如果可以获得锁，那么进入临界区，如果还不能获得锁，才会真实的将线程在操作系统层面进行挂起。

适用场景:自旋锁可以减少线程的阻塞，这对于锁竞争不激烈，且占用锁时间非常短的代码块来说，有较大的性能提升，因为自旋的消耗会小于线程阻塞挂起操作的消耗。

如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功，线程自旋的消耗大于线程阻塞挂起操作的消耗，造成cpu的浪费。

ThreadLocal 原理了解吗？

从 Thread类源代码入手。

public class Thread implements Runnable {
    //......
    //与此线程有关的ThreadLocal值。由ThreadLocal类维护
    ThreadLocal.ThreadLocalMap threadLocals = null;

    //与此线程有关的InheritableThreadLocal值。由InheritableThreadLocal类维护
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
    //......
}
1
2
3
4
5
6
7
8
9

从上面Thread类 源代码可以看出Thread 类中有一个 threadLocals 和 一个 inheritableThreadLocals 变量，它们都是 ThreadLocalMap 类型的变量,我们可以把 ThreadLocalMap 理解为ThreadLocal 类实现的定制化的 HashMap。

默认情况下这两个变量都是 null，只有当前线程调用 ThreadLocal 类的 set或get方法时才创建它们，实际上调用这两个方法的时候，我们调用的是ThreadLocalMap类对应的 get()、set()方法。

ThreadLocal类的set()方法

public void set(T value) {
    //获取当前请求的线程
    Thread t = Thread.currentThread();
    //取出 Thread 类内部的 threadLocals 变量(哈希表结构)
    ThreadLocalMap map = getMap(t);
    if (map != null)
        // 将需要存储的值放入到这个哈希表中
        map.set(this, value);
    else
        createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

通过上面这些内容，我们足以通过猜测得出结论：最终的变量是放在了当前线程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal 可以理解为只是ThreadLocalMap的封装，传递了变量值。 ThrealLocal 类中可以通过Thread.currentThread()获取到当前线程对象后，直接通过getMap(Thread t)可以访问到该线程的ThreadLocalMap对象。

每个Thread中都具备一个ThreadLocalMap，而ThreadLocalMap可以存储以ThreadLocal为 key ，Object 对象为 value 的键值对。

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
    //......
}
1
2
3

比如我们在同一个线程中声明了两个 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()方法

如果想了解弱引用相关知识，可以参考我的这篇文章——JVM面试题详解系列——垃圾回收详解。