并发编程之synchronized关键字

试剑江湖
435 阅读23分钟

一个对象是否安全取决于它是否被多个线程访问(访问是访问对象的方式)。要使对象线程安全，需要采用同步的机制来协同对对象可变状态的访问。(java这边采用synchronized，其他还有volatile类型的变量，显式锁以及原子变量)

1. synchronized 理解

1.1 synchronized 特性

synchronized的底层是使用操作系统的mutex lock实现的。

  • 内存可见性：同步快的可见性是由“如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值”、“对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store和write操作）”这两条规则获得的。
  • 操作原子性：持有同一个锁的两个同步块只能串行地进入

1.2 锁的内存语义

  • 当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中
  • 当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的临界区代码必须从主内存中读取共享变量

1.3 synchronized 锁的使用

## 对象实例
public synchronized void method() {}
synchronized (this) {}

## 全局类锁
public static synchronized void method() {}
synchronized (Lock.class) {}

## 静态变量 也属于全局唯一
public static Object monitor = new Object(); 
synchronized (monitor) {}

2. synchronized锁的原理

2.1 synchronized 底层实现

synchronized 的底层实现主要区分：方法和代码块

public class DemoSynchronized01 {
    private static final Object lock = new Object();

    public static void main(String[] args) {
        // 锁作用于代码块
        synchronized (lock) {
            System.out.println("hello word");
        }
    }

    // 锁作用于方法
    public synchronized void test() {
        System.out.println("test");
    }
}

将该代码进行编译后，查看其字节码，核心代码如下：

mac@wxw synchronize % javap -c DemoSynchronized.class 
Compiled from "DemoSynchronized.java"
public class com.wxw.juc.synchronize.DemoSynchronized {
  public static int race;

  public com.wxw.juc.synchronize.DemoSynchronized();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.InterruptedException;
    Code:
       0: iconst_0
       1: istore_1
       2: iload_1
       3: iconst_2
       4: if_icmpge     28
       7: new           #2                  // class java/lang/Thread
      10: dup
      11: invokedynamic #3,  0              // InvokeDynamic #0:run:()Ljava/lang/Runnable;
      16: invokespecial #4                  // Method java/lang/Thread."<init>":(Ljava/lang/Runnable;)V
      19: invokevirtual #5                  // Method java/lang/Thread.start:()V
      22: iinc          1, 1
      25: goto          2
      28: getstatic     #6                  // Field countDownLatch:Ljava/util/concurrent/CountDownLatch;
      31: invokevirtual #7                  // Method java/util/concurrent/CountDownLatch.await:()V
      34: getstatic     #8                  // Field java/lang/System.out:Ljava/io/PrintStream;
      37: getstatic     #9                  // Field race:I
      40: invokevirtual #10                 // Method java/io/PrintStream.println:(I)V
      43: return

  static {};
    Code:
       0: iconst_0
       1: putstatic     #9                  // Field race:I
       4: new           #13                 // class java/util/concurrent/CountDownLatch
       7: dup
       8: iconst_2
       9: invokespecial #14                 // Method java/util/concurrent/CountDownLatch."<init>":(I)V
      12: putstatic     #6                  // Field countDownLatch:Ljava/util/concurrent/CountDownLatch;
      15: return
}

通过反编译后代码可以看出：对于同步方法，JVM采用ACC_SYNCHRONIZED标记符来实现同步。 对于同步代码块。JVM采用monitorenter、monitorexit两个指令来实现同步。

synchronized 修饰代码块

同步代码块使用monitorenter和monitorexit两个指令实现。可以把执行monitorenter指令理解为加锁，执行monitorexit理解为释放锁。 每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为0，当一个线程获得锁（执行monitorenter）后，该计数器自增变为 1 ，当同一个线程再次获得该对象的锁的时候，计数器再次自增。当同一个线程释放锁（执行monitorexit指令）的时候，计数器再自减。当计数器为0的时候。锁将被释放，其他线程便可以获得锁。

synchronized 修饰方法

方法级的同步是隐式的。同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。值得注意的是，如果在方法执行过程中，发生了异常，并且方法内部并没有处理该异常，那么在异常被抛到方法外面之前监视器锁会被自动释放。

无论是ACC_SYNCHRONIZED还是monitorenter、monitorexit都是基于Monitor实现的，在Java虚拟机(HotSpot)中，Monitor是基于C++实现的，由ObjectMonitor实现。

ObjectMonitor类中提供了几个方法，如enter、exit、wait、notify、notifyAll等。sychronized加锁的时候，会调用objectMonitor的enter方法，解锁的时候会调用exit方法。事实上，只有在JDK1.6之前，synchronized的实现才会直接调用ObjectMonitor的enter和exit，这种锁被称之为重量级锁。为什么说这种方式操作锁很重呢？

Java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就要从用户态转换到核心态，因此状态转换需要花费很多的处理器时间，对于代码简单的同步块（如被synchronized修饰的get 或set方法）状态转换消耗的时间有可能比用户代码执行的时间还要长，所以说synchronized是java语言中一个重量级的操纵。

所以，在JDK1.6中出现对锁进行了很多的优化，进而出现轻量级锁，偏向锁，锁消除，适应性自旋锁，锁粗化(自旋锁在1.4就有 只不过默认的是关闭的，jdk1.6是默认开启的)，这些操作都是为了在线程之间更高效的共享数据，解决竞争问题。

2.2 锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

JIT 编译时，对运行上下文进行扫描，去除不可能存在竞争的锁

也许读者会有疑问，变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是程序员自己所该是很清楚的，怎么会在明知道不存在数据争用的情况下要求同步呢？答案是有许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过了 大部分读者的想象。我们来看看下面代码中的例子，这段非常简单的代码仅仅是输出 3 个字符串相加的结果，无论是源码字面上还是程序语义上都没有同步。 image.png

我们也知道，由于 String 是一个不可变的类，对字符串的连接操作总是通过生成新的String 对象来进行的，因此 Javac 编译器会对 String 连接做自动优化。在 JDK 1.5 之前，会转化为 StringBuffer 对象的连续 append（）操作，在JDK 1.5及以后的版本中，会转化为 StringBuilder 对象的连续 append（）操作，上述代码可能会变成下面的样子。 image.png 现在大家还认为这段代码没有涉及同步吗？每个StringBuffer.append（） 方法中都有一个同步块，锁就是 sb 对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在 concatString（） 方法内部。也就是说，sb 的所有引用永远不会 “逃逸” 到 concatString（）方法之外，其他线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

2.3 锁粗化

极端情况下，通过扩大加锁的范围，避免反复加锁和解锁

原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小，只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。

大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。 image.png

上述代码中连续的append()方法就属于这类情况。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展 （粗化）到整个操作序列的外部，以上述代码为例，就是扩展到append()操作外部，也就是把while循环加锁，这样只需要加锁一次就可以了。

2.4 监视器对象（ObjectMonitor）

synchronized 底层对应的 JVM 模型为 objectMonitor，使用了3个双向链表来存放被阻塞的线程：_cxq（Contention queue）、_EntryList（EntryList）、_WaitSet（WaitSet）

当线程获取锁失败进入阻塞后，首先会被加入到 _cxq 链表，_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表。

当持有锁的线程释放锁后，_EntryList 链表头结点的线程会被唤醒，该线程称为 successor（假定继承者），然后该线程会尝试抢占锁。

当我们调用 wait() 时，线程会被放入 _WaitSet，直到调用了 notify()/notifyAll() 后，线程才被重新放入 _cxq 或 _EntryList，默认放入 _cxq 链表头部。

objectMonitor 的整体流程如下图： image.png

3. 锁升级过程

3.1 偏向锁

偏向锁减少了统一线程获取锁的代价

大多数情况下，锁不存在多线程竞争，总是由同一线程多次获得

核心思想 如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word的结构也变为偏向锁结构，当该线程再次请求锁时，无需再做任何同步操作，即获取锁的过程只需要检查 Mark Word 的锁标记位为偏向锁01，以及当前线程Id等于Mark Word 的ThreadID即可，这样就省去了大量有关锁申请的操作。

不适用于锁竞争比较激烈的多线程场合

偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。

偏向锁的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连 CAS 操作都不做了。

假设当前虚拟机启用了偏向（启用参数-XX:+UseBiasedLocking，这是 JDK 1.6 的默认值），那么，当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为 “01 ”，即偏向模式。同时使用 CAS 操作把获取到这个锁的线程的 ID记录在对象的 Mark Word 之中，如果 CAS 操作成功，持有偏向锁的钱程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如 Locking 、Unlocking 及对 Mark Word的Update 等）。

当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”） 或轻量级锁定（标志位为 “00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。偏向锁、 轻量级锁的状态转化及对象 Mark Word 的关系如图所示。

image.png

同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说，它并不一定总是对程序运行有利，如果程序中大多数的锁总是被多个不同的线程访问，那偏向模式就是多余的。在具体问题具体分析的前提下，有时候使用参数XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。

加锁流程

  • 从当前线程的栈帧中寻找一个空闲的 Lock Record，将 obj 属性指向当前锁对象
  • 获取偏向锁时，会先进行各种判断，如加锁流程图所示，最终只有两种场景能尝试获取锁：匿名偏向、批量重偏向。
  • 使用 CAS 尝试将自己的线程 ID 填充到锁对象 markword 里，修改成功则获取到锁。
  • 如果不是步骤1的两种场景，或者 CAS 修改失败，则会撤销偏向锁，并升级为轻量级锁。
  • 如果线程成功获取偏向锁，之后每次进入该同步块时，只需要简单的判断锁对象 markword 里的线程ID是否自己，如果是则直接进入，几乎没有额外开销。

解锁流程：

  • 偏向锁的解锁很简单，就是将 obj 属性赋值为 null，这边很重要的点是不会将锁对象 markword 的线程ID还原回0。
  • 偏向锁流程中，markword 的状态变化如下图所示： image.png

3.2 轻量级锁流程

轻量级锁是由偏向锁升级来的，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级会轻量级锁。

  • 适用场景：线程交替执行同步块 若出现在同一时间（多个线程）访问同一个锁的情况，就会导致轻量级膨胀为重量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁。

加锁流程 在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝 （官方把这份拷贝加了一个 Displaced 前辙，即Displaced Mark Word ）。

然后，虚拟机将使用CAS操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针。如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word 的锁标志位（Mark Word 的最后 2bit ）将转变为 “00”，即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如图所示。 image.png 解锁流程：

  • 将 obj 属性赋值为 null
  • 使用 CAS 将 displaced_header 属性暂存的 displaced mark word 还原回锁对象的 markword。

3.3 重量级锁流程

如果这个更新操作（轻量级锁）失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。如果有两条以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为“10”，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后而等待锁的线程也要进入阻塞状态。

上而描述的是轻量级锁的加锁过程，它的解锁过程也是通过CAS操作来进行的，如果对象的 Mark Word 仍然指向着线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和 线程中复制的 Displaced Mark Word 替换回来，如果替换成功，越个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程。

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用 CAS 操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了 CAS 操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

加锁流程： 当轻量级锁出现竞争时，会膨胀成重量级锁。

  • 分配一个 ObjectMonitor，并填充相关属性。
  • 将锁对象的 markword 修改为：该 ObjctMonitor 地址 + 重量级锁标记位（10）
  • 尝试获取锁，如果失败了则尝试自旋获取锁
  • 如果多次尝试后还是失败，则将该线程封装成 ObjectWaiter，插入到 cxq 链表中，当前线程进入阻塞状态
  • 当其他锁释放时，会唤醒链表中的节点，被唤醒的节点会再次尝试获取锁，获取成功后，将自己从 cxq（EntryList）链表中移除此时的线程栈、锁对象、ObjectMonitor 之间的关系如下图所示： image.png 解锁流程：
  • 将重入计数器-1，ObjectMonitor 里的 _recursions 属性。
  • 先释放锁，将锁的持有者 owner 属性赋值为 null，此时其他线程已经可以获取到锁，例如自旋的线程。
  • 从 EntryList 或 cxq 链表中唤醒下一个线程节点。

3.4 小总结

  • 只有一个线程进入临界区：偏向锁
  • 多个线程交替进入临界区：轻量级锁
  • 多线程同时进入临界区：重量级锁

升级过程 image.png 偏向锁： 指的是JVM认为只有某个线程才会执行同步代码（没有竞争环境），所以在Mark Word 会直接记录线程ID,只要线程进来执行代码了，会比对线程ID判断是否相等，相等则当前线程获取得到锁，执行同步代码。如果线程ID不相等，则用CAS尝试来修改当前线程ID,如果CAS修改成功，那还是能获取得到锁，执行同步代码

如果CAS失败了，说明有竞争环境，此时会对偏向锁撤销，升级为轻量级锁，在轻量级锁的状态下，当前线程会在栈帧下创建Lock Record, Lock Record 会把Mark Word 的信息拷贝进去，且有Owner 指针指向加锁对象，线程执行同步代码时，则用CAS视图将Mark Word 指向到Lock Record，假设CAS修改成功，则获取得到轻量级锁。

假设CAS失败，则适应性自旋（重试），自旋一定次数后，还是CAS失败，则升级为重量级锁

4. 总结

4.1 synchronised和reentrantlock的区别

  • 底层实现：synchronized 是 Java 中的关键字，是 JVM 层面的锁；ReentrantLock 是 JDK 层次的锁实现。

  • 是否需要手动释放：synchronized 不需要手动获取锁和释放锁，在发生异常时，会自动释放锁，因此不会导致死锁现象发生；ReentrantLock 在发生异常时，如果没有主动通过 unLock() 去释放锁，很可能会造成死锁现象，因此使用 ReentrantLock 时需要在 finally 块中释放锁。

  • 锁的公平性：synchronized 是非公平锁；ReentrantLock 默认是非公平锁，但是可以通过参数选择公平锁。

  • 是否可中断：synchronized 是不可被中断的；ReentrantLock 则可以被中断。

  • 灵活性：使用 synchronized 时，等待的线程会一直等待下去，直到获取到锁；ReentrantLock 的使用更加灵活，有立即返回是否成功的，有响应中断、有超时时间等。

  • 性能上：随着近些年 synchronized 的不断优化，ReentrantLock 和 synchronized 在性能上已经没有很明显的差距了，所以性能不应该成为我们选择两者的主要原因。官方推荐尽量使用 synchronized，除非 synchronized 无法满足需求时，则可以使用 Lock。

  • synchronized 关键字结合 wait() 和 notify()/notifyAll() 方法使用，可以实现等待/通知机制，

  • ReentrantLock 类则需要借助于 Condition 接口与 newCondition() 方法。

Condition 是 JDK1.5 之后才有的，它具有很好的灵活性，比如可以实现多路通知功能，也就是在一个 Lock 对象中可以创建多个 Condition 实例（即对象监视器），线程对象可以注册在指定的 Condition 中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。 在使用 notify()/notifyAll() 方法进行通知时，被通知的线程是由 JVM 选择的。而 synchronized 关键字就相当于整个 Lock 对象中只有一个 Condition 实例，所有的线程都注册在它一个身上。如果执行 notifyAll() 方法的话，就会通知所有处于等待状态的线程，这样会造成很大的效率问题，而 Condition 实例的 signalAll() 方法只会唤醒注册在该 Condition 实例中的所有等待线程。

增加的新特点： ① 等待可中断；② 可实现公平锁；③ 可实现选择性通知（锁可以绑定多个条件）：

4.2 自旋锁和适应性自旋锁

（1）自旋锁

前面我们讨论互斥同步的时候，提到了互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力。同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间去挂起和恢复线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一 下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁。

自旋锁就是让某线程进入已被其它线程占用的同步代码时循环等待,避免阻塞唤醒导致上下文切换开销。

  • 优点
    • 许多情况下，共享数据的锁定状态持续时间较短，切换线程不值得
    • 通过让线程执行忙循环 来等待锁的释放，从而不让出CPU，避免导致上下文切换开销
  • 缺点
    • 若锁被其它线程长时间占用，会带来许多性能上的开销

自旋锁在JDK 1.4.2中就已经引入，只不过默认是关闭的，可以使用 :XX:+UseSpinning 参数来开启，在JDK 1.6 中就已经改为默认开启了。自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时间很长，那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次数的默认值是 10 次，用户可以使用参数-XX:PreBlockSpin 来更改。

（2）适应性自旋锁

  • 自适应意味着自旋的时间（次数）不再固定
  • 由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。

如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。 比如自旋锁：

4.3 synchronized 锁能降级

可以的，具体的触发时机：在全局安全点（safepoint）中，执行清理任务的时候会触发尝试降级锁。 当锁降级时，主要进行了以下操作：

  • 恢复锁对象的 markword 对象头
  • 重置 ObjectMonitor，然后将该 ObjectMonitor 放入全局空闲列表，等待后续使用。

参考

  1. 全网最硬核的 synchronized 面试题深度解析
  2. synchronized 锁
avatar
文章
阅读
粉丝