【JavaEE精炼宝库】多线程进阶（2）synchronized原理、JUC类——深度理解多线程编程

一、synchronized 原理

1.1 基本特点：

结合上面的锁策略，我们就可以总结出，synchronized 具有以下特性(只考虑 JDK 1.8)：

• 开始时是乐观锁，如果锁冲突频繁，就转换为悲观锁。

• 开始是轻量级锁实现，如果锁被持有的时间较长，就转换成重量级锁。

• 实现轻量级锁的时候大概率用到的自旋锁策略。

• 是一种不公平锁。

• 是一种可重入锁。

• 不是读写锁。

1.2 加锁工作过程：

JVM 将 synchronized 锁分为无锁、偏向锁、轻量级锁、重量级锁状态。会根据情况，进行依次升级。

1.2.1 偏向锁：

第一个尝试加锁的线程，优先进入偏向锁状态。 偏向锁不是真的 “加锁”，只是给对象头中做一个 “偏向锁的标记”，记录这个锁属于哪个线程。如果后续没有其他线程来竞争该锁，那么就不用进行其他同步操作了（避免了加锁解锁的开销）。如果后续有其他线程来竞争该锁（刚才已经在锁对象中记录了当前锁属于哪个线程了，很容易识别当前申请锁的线程是不是之前记录的线程），那就取消原来的偏向锁状态，进入一般的轻量级锁状态。偏向锁本质上相当于 “延迟加锁”。能不加锁就不加锁，尽量来避免不必要的加锁开销。但是该做的标记还是得做的，否则无法区分何时需要真正加锁。

1.2.2 轻量级锁：

随着其他线程进入竞争，偏向锁状态被消除，进入轻量级锁状态（自适应的自旋锁）。此处的轻量级锁就是通过 CAS 来实现。通过 CAS 检查并更新一块内存（比如 null => 该线程引用）如果更新成功，则认为加锁成功，如果更新失败，则认为锁被占用，继续自旋式的等待（并不放弃CPU）。

自旋操作是一直让 CPU 空转，比较浪费 CPU 资源。因此此处的自旋不会一直持续进行，而是达到一定的时间 / 重试次数，就不再自旋了。也就是所谓的 “自适应” 。

1.2.3 重量级锁：

如果竞争进一步激烈，自旋不能快速获取到锁状态，就会膨胀为重量级锁。此处的重量级锁就是指用到内核提供的 mutex 。

执行加锁操作，先进入内核态，在内核态判定当前锁是否已经被占用，如果该锁没有占用，则加锁成功，并切换回用户态，如果该锁被占用，则加锁失败。此时线程进入锁的等待队列，挂起等待被操作系统唤醒。经历了一系列的沧海桑田，这个锁被其他线程释放了，操作系统也想起了这个被挂起的线程，于是唤醒这个线程，尝试重新获取锁。

1.3 锁消除：

编译器 + JVM 判断锁是否可消除。 如果可以，就直接消除。

锁消除常常运用在：有些应用程序的代码中，用到了 synchronized，但其实没有在多线程环境下。(例如 StringBuffer)

StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

此时每个 append 的调用都会涉及加锁和解锁，但如果只是在单线程中执行这个代码，那么这些加锁解锁操作是没有必要的，白白浪费了一些资源开销。

1.4 锁粗化：

一段逻辑中如果出现多次加锁解锁，编译器 + JVM 会自动进行锁的粗化。 锁粗化这里涉及一个概念粒度（不是力度）：加锁的范围内，包含代码的多少，包含的代码越多，就认为锁的粒度就越粗，反之，锁的粒度就越细。

综上可以看到，synchronized 的策略是比较复杂的，在背后做了很多事情，目的为了让程序猿哪怕啥都不懂，也不至于写出特别慢的程序。JVM 开发者为了 Java 程序猿操碎了心。

1.5 面试题：

1. 什么是偏向锁?

答：偏向锁不是真的加锁，而只是在锁的对象头中记录⼀个标记(记录该锁所属的线程)。如果没有其他线程参与竞争锁，那么就不会真正执行加锁操作，从而降低程序开销。⼀旦真的涉及到其他的线程竞争，再取消偏向锁状态，进入轻量级锁状态。

2. synchronized 实现原理是什么？

答：刚开始是一个标记，遇到所冲突升级成轻量级锁，采用自旋锁的方式实现，随着锁冲突的升级，锁升级为重量级锁，采用挂起等待锁的方式，来实现锁。

二、JUC（java.util.concurrent）的常见类

在 java.util.concurrent 中放了和多线程相关的组件。

2.1 Callable 接口：

Callable 是⼀个接口，相当于把线程封装了⼀个 “返回值”。方便程序猿借助多线程的方式计算结果。可以认为是一个带返回参数的 runnable 。里面要重写的方法是 call( )。

• 理解 Callable 和 FutureTask：

Callable 和 Runnable 相对，都是描述一个 “任务”。Callable 描述的是带有返回值的任务，Runnable
描述的是不带返回值的任务。Callable 通常需要搭配 FutureTask 来使用 FutureTask 用来保存 Callable 的返回结果。因为 Callable 往往是在另⼀个线程中执行的，啥时候执行完并不确定。FutureTask 就可以负责这个等待结果出来的工作（如果在 futureTask.get()线程还没执行完毕就会阻塞等待）。

FutureTask 可以直接传入 Thread 的构造方法当中，于是我们掌握的 Thread 的构造方式又多了一种。

我们可以将它们的关系理解成吃麻辣烫的情形：去吃麻辣烫，Callable 就是菜篮，重写的 call 方法里面就是点的菜，当餐点好后，前台会给你一张 “小票” ，后厨开始工作（Thread 启动）。这个小票就是 FutureTask，后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没有（线程是否执行完毕）。

演示案例：创建线程计算 1 + 2 + 3 + … + 1000，使用 Callable 版本。

import java.util.concurrent.*;
public class demo2 {
   
    public