1. synchronized 使用

1.1 线程安全问题

  并发编程中，当多个线程同时访问同一个资源的时候，就会存在线程安全问题。

  由于每个线程执行的过程是不可控的，所以很可能导致最终的结果与实际期望的结果相违背或者直接导致程序出错。下面的代码，每执行一次 add10K() 方法，都会循环 10000 次 count+=1 操作。在 calc() 方法中我们创建了两个线程，每个线程调用一次 add10K() 方法，我们来想一想执行 calc() 方法得到的结果应该是多少呢？

public class Test {private long count = 0;private void add10K() {int idx = 0;while(idx++ < 10000) {count += 1;}}public static long calc() {final Test test = new Test();// 创建两个线程，执行 add() 操作Thread th1 = new Thread(()->{test.add10K();});Thread th2 = new Thread(()->{test.add10K();});// 启动两个线程th1.start();th2.start();// 等待两个线程执行结束th1.join();th2.join();return count;}
}

  如上面程序，直觉告诉我们应该是20000，因为在单线程里调用两次add1OK()方法，但实际的结果是10000-20000之间的随机数。为什么呢？

  java并发程序都是基于多线程的，自然也就会涉及到任务切换，任务切换的时机大多数都是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里的一条语句往往需要多条CPU指令完成，如count += 1，至少需要三条CPU指令。

• 指令1：首先，需要把变量count从内存加载到CPU寄存器；
• 指令2：之后，在寄存器中执行+1操作；
• 指令3：最后，将结果写入内存（缓存机制导致可能写入的是CPU缓存而不是内存）。

  操作系统做任务切换，可以发生在任何一条CPU指令执行完，注意是CPU指令，而不是高级语言里的一条语句。对于上面三条指令来说，我们假设count=0，如果线程A在指令1执行完后做线程切换，线程A和线程B按照下图的序列执行，那么两个线程都执行了count +=1的操作，得到的结果不是我们期望的2，而是1。

基本上所有的并发模式在解决线程安全问题时，都采用“序列化访问临界资源”的方案，即在同一时刻，只能有一个线程访问临界资源，也称作同步互斥访问。
通常来说，是在访问临界资源的代码前面加上一个锁，当访问完临界资源后释放锁，让其他线程继续访问。
在Java中，提供了两种方式来实现同步互斥访问：synchronized和Lock。

  

1.2 synchronized 概念

  synchronized 它可以把任意一个非 NULL 的对象当作锁。他属于独占式的悲观锁，同时属于可重入锁。Synchronized 是非公平锁。每个对象都有个 monitor 对象，加锁就是在竞争 monitor 对象，代码块加锁是在前后分别加 上 monitorenter 和 monitorexit 指令来实现的，方法加锁是通过一个标记位来判断的。

  

1.3 synchronized 的作用范围

Synchronized 的作用范围如下：

1. 普通同步方法，锁是当前实例对象；
2. 静态同步方法，锁是当前类的class对象；
3. 同步方法块，锁是括号里面的对象；
4. 不能继承，父类的同步方法被子类重写后默认不是 synchronized 的，必须显示指定。

public class TestSynchronized {static int count;// 普通同步方法：锁的是当前实例对象public synchronized void add(int value) {count += value;}// 静态同步方法：锁的是当前类的 class 对象public static synchronized void add1(int value) {count += value;}// 同步代码块：锁的是当前实例对象（this）public void add3(int value) {synchronized (this) {count += value;}}// 同步代码块：锁的是当前类的 class 对象public void add4(int value) {synchronized (TestSynchronized.class) {count += value;}}
}

  

2. synchronized 原理

  上面的代码，利用 javap 工具查看生成的 class 文件信息来分析 Synchronized 的实现。

  javap 的命令：javap -v TestSynchronized.class，上面代码生成的反编译结果为：

同步方法  

同步代码块  

  从反编译的结果中可以看到：对于同步方法，JVM 采用 ACC_synchronized 标记符来实现同步；对于同步代码块，JVM 采用 monitorenter、monitorexit 两个指令来实现同步。

2.1 同步代码块

  JVM采用monitorenter、monitorexit 两个指令来实现同步。关于monitorenter 和 monitorexit 的介绍，大致如下：

1. 可以把执行monitorenter指令理解为加锁，执行monitorexit理解为释放锁；
2. 每个对象维护着一个记录着被锁次数的计数；
3. 未被锁定的对象的该计数器为0，当一个线程获得锁（执行monitorenter）后，该计数器自增变为1，当同一个线程再次获得该对象的锁的时候，计数器再次自增。当同一个线程释放锁（执行monitorexit指令）的时候，计数器再自减；
4. 当计数器为0的时候。锁将被释放，其他线程便可以获得锁。

  

2.2 同步方法

  对于同步方法，JVM 采用 ACC_synchronized 标记符来实现同步。关于同步方法的介绍，大致如下：

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

  

2.3 monitor

  无论是同步方法还是同步代码块都是基于监视器Monitor实现的。

  

2.3.1 monitor 是什么

  所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。

  每个对象都存在着一个Monitor与之关联，对象与其Monitor之间的关系有存在多种实现方式，如Monitor可以与对象一起创建销毁。

  

2.3.2 monitor 如何实现线程同步

  在 Java 虚拟机(HotSpot)中，monitor 是由 ObjectMonitor 实现的（位于 HotSpot 虚拟机源码 ObjectMonitor.hpp 文件，C++ 实现的）。

ObjectMonitor中有几个关键属性：

• _owner：指向持有ObjectMonitor对象的线程；
• _WaitSet：存放处于wait状态的线程队列；
• _EntryList：存放处于等待锁block状态的线程队列；
• _recursions：锁的重入次数；
• _count：用来记录该线程获取锁的次数。

Monitor 实现线程同步的过程如下：

1. 线程 T 等待对象锁：_EntryList 中加入 T；
2. 线程 T 获取对象锁：_EntryList 移除 T，_owner 置为 T，计数器 _count 加 1；
3. 线程T中锁对象调用 wait() ：_owner 置为 null，计数器 _count 减 1，_WaitSet中加入 T 等待被唤醒；
4. 持有对象锁的线程T执行完毕：复位变量的值，以便其他线程进入获取monitor。

  

3. 解决三大问题：原子性、可见性和有序性

3.1 保证原子性

  在并发编程中的原子性：一个或者多个操作在 CPU 执行的过程中不被中断，也就是一段代码，或者一个变量的操作，在一个线程没有执行完之前，不能被其他线程执行。

  synchronized 修饰的代码在同一时间只能被一个线程访问，在锁未释放之前，无法被其他线程访问到。

即使在执行过程中，CPU 时间片用完，线程放弃了 CPU，但并没有进行解锁。而由于 synchronized 的锁是可重入的，下一个时间片还是只能被他自己获取到，还是会由同一个线程继续执行代码，直到所有代码执行完。从而保证 synchronized 修饰的代码块在同一时间只能被一个线程访问。

  

3.2 保证有序性

  单线程重排序要遵守 as-if-serial 语义，不管怎么重排序，单线程程序的执行结果都不能被改变。因为不会改变执行结果，所以无须关心这种重排的干扰，可以认为单线程程序是按照顺序执行的。

  synchronized 修饰的代码，同一时间只能被同一线程访问。那么也就是单线程执行的。所以，可以保证其有序性。

如果在本线程内观察，所有操作都是天然有序的。

  

3.3 保证可见性

JMM 关于 synchronized 的两条语义规定保证了可见性：

• 线程解锁前，必须把共享变量的最新值刷新到主内存中
• 线程加锁前，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值。

  这也是 Happens-Before 规则中的一部分：对一个锁的解锁 Happens-Before 可见于后续对这个锁的加锁。Happens-Before 规则详见《02 - Java内存模型：看 Java 如何解决可见性和有序性问题》

  

4. synchronized 优化

4.1 为什么要优化

  synchronized 监视器锁在互斥同步上对性能的影响很大。

  Java 的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统的帮忙，这就要从用户态转换到内核态，状态转换需要花费很多的处理器时间。

  所以频繁的通过 synchronized 实现同步会严重影响到程序效率，这种锁机制也被称为重量级锁，为了减少重量级锁带来的性能开销，JDK 对synchronized 进行了种种优化。

  

4.2 自旋锁和自适应自旋锁

  大多数情况下，线程持有锁的时间都不会太长，为了这一段很短的时间频繁地阻塞和唤醒线程是非常不值得的。所以引入自旋锁。

  

4.2.1 自旋锁

  当锁被占用时，当前想要获取锁的线程不会被立即挂起，而是做几个空循环，看持有锁的线程是否会很快释放锁。

  在经过若干次循环后，如果得到锁，就顺利进入临界区；如果还不能获得锁，那就会将线程在操作系统层面挂起。

  

4.2.2 自旋锁与阻塞的最大区别

  主要区别：是不是放弃处理器的执行时间。阻塞放弃了CPU时间，进入了等待区，等待被唤醒。响应慢。自旋锁一直占用CPU时间，时刻检查共享资源是否可以被访问，所以响应速度更快。

  

4.2.4 自旋锁优点

  自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来 说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会 导致线程发生两次上下文切换。

4.2.4 自旋锁缺点

  如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合 使用自旋锁了，因为自旋锁在获取锁前一直都是占用 cpu 做无用功，占着 XX 不 XX，同时有大量 线程在竞争一个锁，会导致获取锁的时间很长，线程自旋的消耗大于线程阻塞挂起操作的消耗， 其它需要 cup 的线程又不能获取到 cpu，造成 cpu 的浪费。所以这种情况下我们要关闭自旋锁。

  所以自旋的次数直接决定了自旋锁的性能。JDK6 中-XX:+UseSpinning 开启，JDK自旋的默认次数为10次，可以通过参数-XX:PreBlockSpin来调整，在 JDK7 中去掉了该参数由 JVM 控制。

  

4.2.5 自适应自旋锁

  所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。

  如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。

  有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。

  

4.3 锁消除

  如果JVM检测到某段代码不可能存在共享数据竞争，JVM会对这段代码的同步锁进行锁消除。

  在动态编译同步块的时候，JIT编译器可以借助一种被称为逃逸分析（Escape Analysis）的技术来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。

  如果同步块所使用的锁对象通过这种分析被证实只能够被一个线程访问，那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。

public void test() {Vector<Integer> vector = new Vector<>();for (int i = 0; i < 10; i++) {vector.add(i);}System.out.println(vector);}

  Vector 的 add() 方法是 synchronized 修饰的。在运行这段代码时，JVM 可以明显检测到变量 vector 没有逃逸出方法 test() 之外，所以 JVM 可以大胆地将 vector 内部的加锁操作消除。

  

4.4 锁粗化

  很多时候，我们提倡尽量减小锁的粒度，可以避免不必要的阻塞。 让同步块的作用范围尽可能小，仅在共享数据的实际作用域中才进行同步，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。

  但是如果在一段代码中连续的用同一个监视器锁反复的加锁解锁，甚至加锁操作出现在循环体中的时候，就会导致不必要的性能损耗，这种情况就需要锁粗化。

  锁粗化就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如下面的例子：

for (int i = 0; i < 10000; i++) {synchronized (this) {System.out.println(i);}}

会被粗化成下面的代码：

synchronized (this) {for (int i = 0; i < 10000; i++) {System.out.println(i);}
}

  

4.5 锁膨胀

4.5.1 Java 对象头

  对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

  普通对象的对象头包括两部分：Mark Word 和 Class Metadata Address （类型指针），如果是数组对象还包括一个额外的 Array length 数组长度部分。

  Mark Word：用于存储对象自身的运行时数据，如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等等，占用内存大小与虚拟机位长一致。

   Class Metadata Address：类型指针指向对象的类元数据，虚拟机通过这个指针确定该对象是哪个类的实例。

   下图描述了在 32 位虚拟机上，在对象不同状态时 mark word 各个比特位区间的含义。

  

4.5.2 偏向锁、轻量级锁、重量级锁

  从Java对象头的Mark word中可以看到，synchronized锁一共具有四种状态：无锁、偏向锁、轻量级锁、重量级锁。

  偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。

  

4.5.2.1 偏向锁

  目的：大多数情况下锁不仅不存在多线程竞争，而且总是由同一个线程多次获取，所以引入偏向锁让线程获得锁的代价更低。

  偏向锁认为环境中不存在竞争情况，锁只被一个线程持有，一旦有不同的线程获取或竞争锁对象，偏向锁就升级为轻量级锁。

  偏向锁在无多线程竞争的情况下可以减少不必须要的轻量级锁执行路径。

  

4.5.2.2 轻量级锁

  目的：在大多数情况下同步块并不会出现竞争情况，大部分情况是不同线程交替持有锁，所以引入轻量级锁可以减少重量级锁对线程的阻塞带来的开销。

  轻量级锁认为环境中线程几乎没有对锁对象的竞争，即使有竞争也只需要稍微等待（自旋）下就可以获取锁，但是自旋次数有限制，如果超过该次数，则会升级为重量级锁。

  

4.5.2.3 重量级锁

  监视器锁 Monitor

  

4.5.3 锁的膨胀升级

  synchronized锁膨胀过程就是无锁 → 偏向锁 → 轻量级锁 → 重量级锁的一个过程。这个过程是随着多线程对锁的竞争越来越激烈，锁逐渐升级膨胀的过程。

  如下分析，从一个没有线程访问的锁逐渐升级到重量级锁的过程：

    1）一个锁对象刚刚开始创建的时候，没有任何线程来访问它，此时线程状态为无锁状态。Mark word（锁标志位-01 是否偏向-0）；

    2）当线程 A 来访问这个对象锁时，它会偏向这个线程A。线程 A 检查 Mark word（锁标志位-01 是否偏向-0）为无锁状态。此时，有线程访问锁了，无锁升级为偏向锁，Mark word（锁标志位-01，是否偏向-1，线程 ID-线程 A 的 ID）；

    3）当线程 A 执行完同步块时，不会主动释放偏向锁。持有偏向锁的线程执行完同步代码后不会主动释放偏向锁，而是等待其他线程来竞争才会释放锁。Mark word 不变（锁标志位-01，是否偏向-1，线程 ID-线程 A 的ID）；

    4）当线程 A 再次获取这个对象锁时，检查 Mark word（锁标志位-01，是否偏向-1，线程 ID-线程 A 的 ID），偏向锁且偏向线程 A，可以直接执行同步代码。这样偏向锁保证了总是同一个线程多次获取锁的情况下，每次只需要检查标志位就行，效率很高；

    5）当线程 A 执行完同步块之后，线程 B 获取这个对象锁检查 Mark word（锁标志位-01，是否偏向-1，线程ID-线程 A 的 ID），偏向锁且偏向线程 A。有不同的线程获取锁对象，偏向锁升级为轻量级锁，并由线程 B 获取该锁；

    6）当线程 A 正在执行同步块时，也就是正持有偏向锁时，线程 B 获取来这个对象锁。检查 Mark word（锁标志位-01，是否偏向-1，线程ID-线程 A 的 ID），偏向锁且偏向线程A。

    线程A撤销偏向锁:
1. 等到全局安全点执行撤销偏向锁，暂停持有偏向锁的线程 A 并检查线程 A 的状态；

      2. 如果线程 A 不处于活动状态或者已经退出同步代码块，则将对象锁设置为无锁状态，然后再升级为轻量级锁。由线程 B获取轻量级锁。

      3. 如果线程 A 还在执行同步代码块，也就是线程 A 还需要这个对象锁，则偏向锁膨胀为轻量级锁。

    线程A膨胀为轻量级锁过程：
1. 在升级为轻量级锁之前，持有偏向锁的线程（线程 A ）是暂停的；

      2. 线程 A 栈帧中创建一个名为锁记录的空间（Lock Record）；

      3. 锁对象头中的 Mark Word 拷贝到线程A 的锁记录中；

      4. Mark Word 的锁标志位变为 00，指向锁记录的指针指向线程 A 的锁记录地址，Mark word（锁标志位-00，其他位-线程A锁记录的指针）；

      5. 当原持有偏向锁的线程（线程 A ）获取轻量级锁后，JVM唤醒线程A，线程 A 执行同步代码块。

    7）线程 A 持有轻量级锁，线程 A 执行完同步块代码之后，一直没有线程来竞争对象锁，正常释放轻量级锁。释放轻量级锁操作：CAS 操作将线程A的锁记录（Lock Record）中的 Mark Word 替换回锁对象头中。

    8）线程 A 持有轻量级锁，执行同步块代码过程中，线程B来竞争对象锁。Mark word（锁标志位-00，其他位-线程A锁记录的指针）

      1. 线程 B 会先在栈帧中建立锁记录，存储锁对象目前的 Mark Word 的拷贝；

      2. 线程 B 通过 CAS 操作尝试将锁对象的 Mark Word 的指针指向线程 B 的 Lock Record，如果成功，说明线程 A 刚刚释放锁，线程 B 竞争到锁，则执行同步代码块；

      3. 因为线程 A 一直持有锁，大部分情况下 CAS 是会失败的。CAS 失败之后，线程B尝试使用自旋的方式来等待持有轻量级锁的线程释放锁；

      4. 线程 B 不会一直自旋下去，如果自旋了一定次数后还是失败，线程 B 会被阻塞，等待释放锁后唤醒。此时轻量级锁就会膨胀为重量级锁。Mark word（锁标志位-10，其他位-重量级锁 monitor 的指针）；

      5. 线程 A 执行完同步块代码之后，执行释放锁操作，CAS 操作将线程A的锁记录（Lock Record）中的 Mark Word 替换回锁对象对象头中，因为对象头中已经不是原来的轻量级锁的指针了，而是重量级锁的指针，所以 CAS 操作会失败。

      6. 释放轻量级锁 CAS 操作替换失败之后，需要在释放锁的同时需要唤醒被挂起的线程 B。线程 B 被唤醒，获取重量级锁monitor。

  

4.6 总结

  多并发编程中通过同步互斥访问临界资源来解决线程安全问题，Java中常用 synchronized 标记同步块达到加锁的目的。synchronized 用法有两种，修饰方法和修饰同步代码块。

   synchronized 的实现原理：每一个 Java 对象都会关联一个Monitor，通过 Monitor 对线程的操作实现 synchronized 对象锁。并发编程中synchronized 可以保证原子性、可见性、有序性。

  synchronized 实现同步会严重影响到程序效率，为了减少重量级锁带来的性能开销，JDK 对 Synchronized 进行了优化。

  自旋锁：当锁被占用时，当前想要获取锁的线程不会被立即挂起，而是做几个空循环，看持有锁的线程是否会很快释放锁。如果此时锁释放，当前线程就可以获得锁。

  锁消除：如果 JVM 检测到某段代码不可能存在共享数据竞争，会对这段代码的同步锁进行锁消除。

  锁粗化：将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。

  偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。

  synchronized 锁膨胀过程就是无锁 → 偏向锁 → 轻量级锁 → 重量级锁的一个过程。这个过程是随着多线程对锁的竞争越来越激烈，锁逐渐升级膨胀的过程。