【备战秋招系列-4】Java高频知识——并发、Spring、MySQL、redis

并发 20

P1：Java 内存模型

Java 线程的通信由 JMM 控制，JMM 的主要目的是定义程序中各种变量的访问规则，关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。此处的变量包括实例字段、静态字段和构成数组元素的对象，但不包括局部变量与方法参数，因为它们是线程私有的，不存在多线程竞争问题。为了获得更好的执行效率，JMM 没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器是否要进行调整代码执行顺序这类优化措施，JMM 遵循一个基本原则：只要不改变程序执行结果，编译器和处理器怎么优化都行。例如编译器分析某个锁只会单线程访问就消除该锁，某个 volatile 变量只会单线程访问就把它当作普通变量。

JMM 规定了所有变量都存储在主内存中，每条线程还有自己的工作内存，工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作都必须在工作空间中进行，而不能直接读写主内存中的数据。不同线程之间也无法直接访问对方工作内存中的变量，两个线程之间的通信必须经过主内存，JMM 通过控制主内存与每个线程的工作内存之间的交互来提供内存可见性保证。

关于主内存与工作内存之间的交互，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存等实现细节，JMM 定义了 8 种原子操作：

• lock：作用于主内存变量，把变量标识为一条线程独占的状态。
• unlock：作用于主内存变量，把处于锁定状态的变量释放出来，释放后的变量才能被其他线程锁定。
• read：作用于主内存变量，把变量值从主内存传到工作内存。
• load：作用于工作内存变量，把 read 从主存中得到的值放入工作内存的变量副本。
• use：作用于工作内存变量，把工作内存中的变量值传给执行引擎，每当虚拟机遇到需要使用变量值的字节码指令时执行该操作。
• assign：作用于工作内存变量，把从执行引擎接收的值赋给工作内存变量，每当虚拟机遇到给变量赋值的字节码指令时执行该操作。
• store：作用于工作内存变量，把工作内存中的变量值传送到主内存。
• write：作用于主内存变量，把 store 从工作内存取到的变量值放入主内存变量中。

如果要把一个变量从主内存拷贝到工作内存，就要按顺序执行 read 和 load ，如果要把变量从工作内存同步回主内存，就要按顺序执行 store 和 write 。JMM 只要求这两种操作必须按顺序执行，但不要求连续，也就是说 read 和 load、store 和 write 之间可插入其他指令。这种定义十分严谨但过于复杂，之后 Java 将内存操作简化为 lock、unlock、read 和 write 四种，但这只是语言描述上的等价化简。

---

P2：as-if-serial 和 happens-before 规则

as-if-serial

as-if-serial 的语义是：不管怎么重排序，单线程程序的执行结果不能被改变，编译器和处理器必须遵循 as-if-serial 语义。

为了遵循 as-if-serial 语义，编译器和处理器不会对存在数据依赖关系的操作重排序，因为这种重排序会改变执行结果。但是如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

as-if-serial 语义把单线程程序保护了起来，给了程序员一种幻觉：单线程程序是按程序的顺序执行的，使程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

happens-before

先行发生原则，是 JMM 中定义的两项操作之间的偏序关系，它是判断数据是否存在竞争，线程是否安全的重要手段。

JMM 将 happens-before 要求禁止的重排序按是否会改变程序执行结果分为两类。对于会改变结果的重排序 JMM 要求编译器和处理器必须禁止这种重排序，对于不会改变结果的重排序，JMM 对编译器和处理器不做要求。

JMM 存在一些天然的 happens-before 关系，无需任何同步器协助就已经存在。如果两个操作的关系不在此列，并且无法从这些规则推导出来，它们就没有顺序性保障，虚拟机可以对它们随意进行重排序。

• 程序次序规则：在一个线程内，按照控制流顺序，书写在前面的操作先行发生于书写在后面的操作。
• 管程锁定规则：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。
• volatile 规则：对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作。
• 线程启动规则：线程对象的 start 方法先行发生于此线程的每一个动作。
• 线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测。
• 线程中断规则：对线程 interrupt 方法的调用先行发生于被中断线程的代码检测到中断事件的发生。
• 对象终结规则：一个对象的初始化完成先行发生于它的 finalize 方法的开始。
• 传递性：如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那么操作 A 先行发生于操作 C 。

区别

as-if-serial 保证单线程程序的执行结果不被改变，happens-before 保证正确同步的多线程程序的执行结果不被改变。这两种语义的目的都是为了在不改变程序执行结果的前提下尽可能提高程序执行的并行度。

---

P3：指令重排序

重排序指从源代码到指令序列的重排序，在执行程序时为了提高性能，编译器和处理器通常会对指令进行重排序，分为三种：

• 编译器优化的重排序：编译器在不改变单线程程序语义的前提下可以重排语句的执行顺序。
• 指令级并行的重排序：如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
• 内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作操作看上去可能是乱序执行。

从 Java 源代码到最终实际执行的指令序列，会分别经历编译器优化重排序、指令级并行重排序和内存系统重排序，这些重排序可能会导致多线程程序出现内存可见性问题。

对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序。对于处理器重排序，JMM 的处理器重排序规则会要求 Java 编译器在生成指令序列时，插入特定类型的内存屏障指令，即一组用于实现对内存操作顺序限制的处理器指令，通过内存屏障指令来禁止特定类型的处理器重排序。JMM 属于语言级的内存模型，它确保在不同的编译器和处理器平台上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

---

P4：原子性、可见性和有序性

原子性

由 JMM 直接保证的原子性变量操作包括 read、load、assign、use、store 和 write，基本数据类型的访问都是具备原子性的，例外就是 long 和 double 的非原子性协定，允许虚拟机将没有被 volatile 修饰的 64 位数据的操作划分为两次 32 位的操作。

如果应用场景需要更大范围的原子性保证，JMM 还提供了 lock 和 unlock 操作满足这种需求，尽管 JVM 没有把这两种操作直接开放给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作，这两个字节码指令反映到 Java 代码中就是 synchronized 关键字。

可见性

可见性就是指当一个线程修改了共享变量的值时，其他线程能够立即得知修改。JMM 通过在变量修改后将值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式实现可见性，无论是普通变量还是volatile变量都是如此，区别是 volatile 保证新值能立即同步到主内存以及每次使用前立即从主内存刷新，因此说 volatile 保证了多线程操作变量的可见性，而普通变量则不能保证。

除了 volatile 之外，还有两个关键字能实现可见性，分别是 synchronized 和 final，同步块的可见性是由"对一个变量执行unlock 前必须先把此变量同步回主内存中，即先执行 store 和 write"这条规则获得的。final 的可见性是指：被 final 修饰的字段在构造方法中一旦被初始化完成，并且构造方法没有把"this"引用传递出去，那么其他线程就能看到 final 字段的值。

有序性

有序性可以总结为：在本线程内观察所有操作是有序的，在一个线程内观察另一个线程，所有操作都是无序的。前半句是指"as-if-serial 语义"，后半句是指"指令重排序"和"工作内存与主内存同步延迟"现象。

Java 提供了 volatile 和 synchronized 保证线程间操作的有序性，volatile 本身就包含了禁止指令重排序的语义，而 synchronized 则是由"一个变量在同一个时刻只允许一条线程对其进行lock操作"这条规则获得的，该规则决定了持有同一个锁的两个同步块只能串行进入。

---

P5：volatile 关键字

轻量级的线程操作可见方式，JMM 为 volatile 定义了一些特殊的访问规则，当一个变量被定义为 volatile 后具备两种特性：

• 保证此变量对所有线程的可见性
  可见性是指当一条线程修改了这个变量的值，新值对于其他线程来说是立即可以得知的。而普通变量并不能做到这一点，普通变量的值在线程间传递时均需要通过主内存来完成。
  volatile 变量在各个线程的工作内存中不存在一致性问题，但 Java 的运算操作符并非原子操作，这导致 volatile 变量运算在并发下仍是不安全的。
• 禁止指令重排序优化
  使用 volatile 变量进行写操作，汇编指令操作是带有 lock 前缀的，相当于一个内存屏障，后面的指令不能重排到内存屏障之前的位置。只有一个处理器时不需要使用内存屏障，但如果有两个或更多的处理器访问同一块内存，且其中有一个在观测另一个，就需要使用内存屏障来保证一致性了。
  使用 lock 前缀的指令在多核处理器中会引发两件事：① 将当前处理器缓存行的数据写回到系统内存。② 这个写回内存的操作会使其他在CPU里缓存了该内存地址的数据无效。
  这种操作相当于对缓存中的变量做了一次 store 和 write 操作，可以让 volatile 变量的修改对其他处理器立即可见。

静态变量 i 执行多线程 i++ 的不安全问题

通过反编译会发现一个自增语句是由 4 条字节码指令构成的，依次为getstatic、iconst_1、iadd、putstatic，当getstatic把 i 的值取到操作栈顶时，volatile保证了 i 的值在此刻是正确的，但是在执行iconst_1、iadd这些指令时，其他线程可能已经改变了i的值，而操作栈顶的值就变成了过期的数据，所以 putstatic 指令执行后就可能把较小的 i 值同步回了主内存。

即使编译出来只有一条字节码指令也不能意味着这条指令就是一个原子操作，一条字节码指令在解释执行时，解释器要运行很多行代码才能实现它的语义。如果是编译执行，一条字节码指令也可能转化成若干条本地机器码指令。

适用场景

运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

变量不需要与其他状态变量共同参与不变约束。

volatile的内存语义

从内存语义角度来说，volatile的写-读与锁的释放-获取具有相同的内存效果。

• 写内存语义：当写一个volatile变量时，JMM 会把该线程对应的本地内存中的共享变量值刷新到主内存。
• 读内存语义：当读一个volatile变量时，JMM 会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

volatile指令重排序的特点

当第二个操作是volatile 写时，不管第一个操作是什么都不能重排序，确保写之前的操作不会被编译器重排序到写之后。

当第一个操作是volatile 读时，不管第二个操作是什么都不能重排序，确保读之后的操作不会被编译器重排序到读之前。

当第一个操作是volatile 写，第二个操作是 volatile 读时不能重排序。

JSR-133 增强 volatile 语义的原因

在旧的内存模型中，虽然不允许 volatile 变量之间重排序，但允许 volatile 变量与普通变量重排序，可能导致内存不可见问题。为了提供一种比锁更轻量级的线程通信机制，严格限制了编译器和处理器对 volatile 变量与普通变量的重排序，确保 volatile 的写-读和锁的释放-获取具有相同的内存语义。

---

P6：final 关键字

final 可以保证可见性，被 final 修饰的字段在构造方法中一旦被初始化完成，并且构造方法没有把 this 的引用传递出去，那么在其他线程中就能看见 final 字段的值。

JSR-133 增强 final语义的原因

在旧的 JMM 中，一个严重的缺陷就是线程可能看到 final 域的值会改变。比如一个线程看到一个 int 类型 final 域的值为0，此时该值是还未初始化之前的零值，过一段时间之后该值被某线程初始化后这个线程再去读这个 final 域的值会发现值变为1。

为了修复该漏洞，JSR-133 通过为 final 域增加写和读重排序规则，提供初始化安全保证：只要对象是正确构造的（被构造对象的引用在构造方法中没有逸出），那么不需要使用同步就可以保证任意线程都能看到这个final域在构造方法中被初始化之后的值。

写 final 域重排序规则

禁止把 final 域的写重排序到构造方法之外，编译器会在final域的写之后，构造方法的 return之前，插入一个Store Store屏障。该规则可以确保在对象引用为任意线程可见之前，对象的 final 域已经被正确初始化过了，而普通域不具有这个保障。

对于引用类型，增加了约束：在构造方法内对一个 final 引用的对象的成员域的写入，与随后在构造方法外把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。

读 final 域重排序规则

在一个线程中，初次读对象引用和初次读该对象包含的final域，JMM 禁止处理器重排序这两个操作。编译器会在读final域操作的前面插入一个Load Load 屏障，该规则可以确保在读一个对象的 final 域之前，一定会先读包含这个 final 域的对象的引用。

---

P7：synchronized 关键字

每个 Java 对象都有一个关联的 monitor 监视器，使用 synchronized 时，JVM 会根据 synchronized 的使用环境找到对应对象的 monitor，再根据 monitor 的状态进行加、解锁的判断。如果成功加锁就成为该 monitor 的唯一持有者，monitor 在被释放前不能再被其他线程获取。

方法元信息中会使用 ACC_SYNCHRONIZED 标识该方法是一个同步方法，同步代码块中会使用 monitorenter 和 monitorexit 这两个字节码指令获取和释放 monitor。这两个字节码指令都需要一个引用类型的参数来指明要锁定和解锁的对象，对于同步普通方法，锁是当前实例对象；对于静态同步方法，锁是当前类的 Class 对象；对于同步方法块，锁是 synchronized 括号里的对象。

在执行 monitorenter 指令时，首先要去尝试获取对象的锁。如果这个对象没有被锁定，或者当前线程已经持有了那个对象的锁，那么就把锁的计数器的值增加 1，而在执行 monitorexit 指令时会将锁计数器的值减 1。一旦计数器的值为 0，锁随即就被释放了。如果获取锁对象失败，那当前线程就应该被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。

例如有两个线程 A 和 B 竞争 monitor，当线程 A 竞争到锁时，会将 monitor 中的 owner 设置为 A，把线程 B 阻塞并放到等待竞争资源的 ContentionList 队列。ContentionList 中的部分线程会进入 EntryList，EntryList 中的线程会被指定为 OnDeck 竞争候选者线程，如果获得了锁资源将进入 Owner 状态，释放锁资源后进入 !Owner 状态。被阻塞的线程会进入 WaitSet。

被 synchronized 修饰的同步块对一条线程来说是可重入的，并且同步块在持有锁的线程执行完毕并释放锁之前，会无条件地阻塞后面其他线程的进入。从执行成本的角度看，持有锁是一个重量级的操作。在主流 JVM 实现中，Java 的线程是映射到操作系统的原生内核线程之上的，如果要阻塞或唤醒一条线程，则需要操作系统帮忙完成，这就不可避免陷入用户态到核心态的转换中，进行这些状态转换需要耗费很多的处理器时间。

不公平的原因

所有收到锁请求的线程首先自旋，如果通过自旋也没有获取锁资源将被放入 ContentionList 队列，该做法对于已经进入队列的线程是不公平的。

为了防止 ContentionList 尾部的元素被大量线程进行 CAS 访问影响性能，Owner 线程会在释放锁时将 ContentionList 的部分线程移动到 EntryList 并指定某个线程为 OnDeck 线程，Owner 并没有将锁直接传递给 OnDeck 线程而是把锁竞争的权利交给它，该行为叫做竞争切换，牺牲了公平性但提高了性能。

---

P8：锁优化

JDK 6 对 synchronized 做了很多优化，引入了适应自旋、锁消除、锁粗化、偏向锁和轻量级锁等提高锁的效率，锁一共有 4 个状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，这种只能升级不能降级的锁策略是为了提高获得锁和释放锁的效率。

自旋锁与自适应自旋

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

自旋锁在 JDK 1.4中就已经引入，只不过默认是关闭的，在 JDK 6中就已经改为默认开启了。自旋等待不能代替阻塞，自旋等待本身虽然避免了线程切换的开销，但它要占用处理器时间，所以如果锁被占用的时间很短，自旋的效果就会非常好，反之只会白白消耗处理器资源。因此自旋的时间必须有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程。自旋次数的默认次数是 10 次。

在 JDK 6 中对自旋锁的优化，引入了自适应自旋。自旋的时间不再是固定的了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过锁，那在以后要获取这个锁时将有可能之间省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行时间的增长以及性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越精准。

锁消除

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

锁粗化

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

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

如果虚拟机探测到有一串零碎的操作都对同一个对象加锁，将会把加锁同步的范围扩展（粗化）到整个操作序列的外部。

偏向锁

偏向锁的目的是为了在资源没有被多线程竞争的情况下尽量减少锁带来的性能开销。轻量级锁是在无竞争的情况下使用 CAS 操作消除同步互斥量，偏向锁是在无竞争的情况下把整个同步都去掉，连 CAS 操作都不做了。

偏向锁的意思就是这个锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他线程获取，则持有偏向锁的线程将永远不需要再进行同步。

当一个线程访问同步代码块并获取锁时，会在对象头和帧栈中的锁记录里存储锁偏向的线程 ID，以后该线程再进入和退出同步代码块不需要进行 CAS 操作来加锁和解锁，只需要简单地测试一下对象头的"Mark Word"里是否存储着指向当前线程的偏向锁。如果测试成功表示线程已经获得了锁，如果失败则需要再测试一下"Mark Word"中偏向锁的标识是否设置成了 1 即表示当前使用偏向锁，如果设置了就尝试使用 CAS 将对象头的偏向锁指向当前线程，否则使用 CAS 方式竞争锁。

偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销需要等待全局安全点即此时没有正在执行的字节码，它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态则将对象头设为无锁状态。如果线程还活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的"Mark Word"要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。

轻量级锁

轻量级是相对于操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为重量级锁。轻量级锁并不是用来代替重量级锁的，它设计的初衷是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

在代码即将进入同步块的时候，如果此同步对象没有被锁定，虚拟机首先将在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的Mark Word的拷贝。然后虚拟机将使用 CAS 操作尝试把对象的 Mark Word 更新为指向锁记录的指针，如果这个更新操作成功了，即代表该线程拥有了这个对象的锁，并且锁标志位将转变为"00"，表示此对象处于轻量级锁定状态。

如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是则说明当前线程以及拥有了这个对象的锁，直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态变为"10"，此时Mark Word中存储的就是指向重量级锁的指针，后面等待锁的线程也必须进入阻塞状态。

解锁操作也同样是通过 CAS 操作来进行，如果对象的 Mark Word 仍然指向线程的锁记录，那就用 CAS 操作把对象当前的 Mark Word 和线程复制的 Mark Word 替换回来。假如能够替换成功，那整个同步过程就顺利完成了，如果替换失败，则说明有其他线程尝试过获取该锁，就要在释放锁的同时唤醒被挂起的线程。

偏向锁、轻量级锁和重量级锁的区别

偏向锁的优点是加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距，缺点是如果线程间存在锁竞争会带来额外锁撤销的消耗，适用于只有一个线程访问同步代码块的场景。

轻量级锁的优点是竞争的线程不会阻塞，提高了程序的响应速度，缺点是如果线程始终得不到锁会自旋消耗CPU，适用于追求响应时间和同步代码块执行非常快的场景。

重量级锁的优点是线程竞争不使用自旋不会消耗CPU，缺点是线程会被阻塞，响应时间很慢，适应于追求吞吐量、同步代码块执行较慢的场景。

---

P9：Lock 接口

自 JDK 5 起 Java 类库提供了 juc 并发包，Lock 接口是 juc 包的顶层接口。基于Lock 接口，用户能够以非块结构来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面去实现同步。Lock 并未用到 synchronized，而是利用了 volatile 的可见性。

重入锁 ReentrantLock 是 Lock 接口最常见的一种实现，它与 synchronized 一样是可重入的，在基本用法上也很相似，不过它增加了一些高级功能，主要包括以下三项：

• 等待可中断：是指持有锁的线程长期不释放锁时，正在等待的线程可以选择放弃等待而处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。
• 公平锁：是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁，而非公平锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的，ReentrantLock在默认情况下也是非公平的，但可以通过带有布尔值的构造方法要求使用公平锁。不过一旦使用了公平锁，将会导致性能急剧下降，明显影响吞吐量。
• 锁绑定多个条件：是指一个 ReentrantLock 对象可以同时绑定多个 Condition 对象。在 synchronized中，锁对象的 wait 跟它的notify/notifyAll 方法配合可以实现一个隐含的条件，如果要和多于一个的条件关联时就不得不额外添加一个锁，而 ReentrantLock 可以多次调用 newCondition 方法。

一般优先考虑使用synchronized：① synchronized 是 Java 语法层面的同步，足够清晰和简单。② Lock 应该确保在 finally 中释放锁，否则一旦受同步保护的代码块中抛出异常，则有可能永远不会释放持有的锁。这一点必须由程序员自己来保证，而使用 synchronized 可以由 JVM 来确保即使出现异常锁也能被正常释放。③ 尽管在 JDK 5 时ReentrantLock 的性能领先于 synchronized，但在 JDK 6 进行锁优化之后，二者的性能基本能够持平。从长远来看 JVM 更容易针对synchronized进行优化，因为 JVM 可以在线程和对象的元数据中记录 synchronized 中锁的相关信息，而使用Lock的话 JVM 很难得知具体哪些锁对象是由特定线程持有的。

ReentrantLock 的可重入实现

以非公平锁为例，通过 nonfairTryAcquire 方法获取锁，该方法增加了再次获取同步状态的处理逻辑：通过判断当前线程是否为获取锁的线程来决定获取操作是否成功，如果是获取锁的线程再次请求则将同步状态值进行增加并返回 true，表示获取同步状态成功。

成功获取锁的线程再次获取锁，只是增加了同步状态值，这就要求 ReentrantLock 在释放同步状态时减少同步状态值。如果该锁被获取了 n 次，那么前 n-1 次 tryRelease 方法必须都返回fasle，只有同步状态完全释放了才能返回 true，该方法将同步状态是否为 0 作为最终释放的条件，当同步状态为 0 时，将占有线程设置为null，并返回 true 表示释放成功。

对于非公平锁只要 CAS 设置同步状态成功则表示当前线程获取了锁，而公平锁则不同。公平锁使用 tryAcquire 方法，该方法与nonfairTryAcquire 的唯一区别就是判断条件中多了对同步队列中当前节点是否有前驱节点的判断，如果该方法返回 true 表示有线程比当前线程更早地请求获取锁，因此需要等待前驱线程获取并释放锁之后才能继续获取锁。、

---

P10：读写锁

ReentrantLock 是排他锁，在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一个读锁和一个写锁，通过分离读写锁使并发性相比一般的排他锁有了很大提升。

除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。只需要在读操作时获取读锁，写操作时获取写锁即可，当写锁被获取时后续的读写操作都会被阻塞，写锁释放之后所有操作继续执行，编程方式相对于使用等待/通知机制的实现方式变得简单。

读写锁同样依赖自定义同步器来实现同步功能，而读写状态就是其同步器的同步状态。读写锁的自定义同步器需要在同步状态即一个整形变量上维护多个读线程和一个写线程的状态。如果在一个 int 型变量上维护多种状态，就一定要按位切割使用这个变量，读写锁将变量切分成了两个部分，高 16 位表示读，低 16 位表示写。

写锁是一个支持重入的排他锁，如果当前线程已经获得了写锁则增加写状态，如果当前线程在获取写锁时，读锁已经被获取或者该线程不是已经获得写锁的线程则当前线程进入等待状态。写锁的释放与 ReentrantLock 的释放过程类似，每次释放均减少写状态，当写状态为 0时表示写锁已被释放，从而等待的读写线程能够继续访问读写锁，同时前次写线程的修改对后续读写线程可见。

读锁是一个支持重入的共享锁，它能够被多个线程同时获取，在没有其他写线程访问时，读锁总会被成功地获取，而所做的只是线程安全地增加读状态。如果当前线程已经获取了读锁，则增加读状态。如果当前线程在获取读锁时，写锁已被其他线程获取则进入等待状态。读锁的每次释放均会减少读状态，减少的值是（1<<16），读锁的每次释放是线程安全的。

锁降级指的是写锁降级成为读锁，如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。锁降级指的是把持住当前拥有的写锁，再获取到读锁，随后释放先前拥有的写锁的过程。

锁降级中读锁的获取是必要的，主要是为了保证数据的可见性，如果当前线程不获取读锁而是直接释放写锁，假设此刻另一个线程 A 获取了写锁修改了数据，那么当前线程是无法感知线程 A 的数据更新的。如果当前线程获取读锁，即遵循锁降级的步骤，线程 A 将会被阻塞，直到当前线程使用数据并释放读锁之后，线程 A 才能获取写锁进行数据更新。

---

P11：AQS 队列同步器

队列同步器是用来构建锁或者其他同步组件的基础框架，它使用了一个 volatile int state 变量作为共享资源，如果线程获取资源失败，则进入同步 FIFO 队列中等待；如果获取成功就执行临界区代码，执行完释放资源时，会通知同步队列中的等待线程来获取资源后出队并执行。

使用方式

同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法 getState、setState 和 compareAndSetState 来进行操作，因为它们能够保证状态的改变是安全的。子类推荐被定义为自定义同步组件的静态内部类，同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型地同步组件。

和锁的关系

同步器是实现锁的关键，在锁的实现中聚合同步器，利用同步器实现锁的语义。锁是面向使用者的，它定义了使用者与锁交互的接口，隐藏了实现细节；同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所关注的领域。

同步队列

AQS 中每当有新的线程请求资源时，该线程都会进入一个等待队列，只有当持有锁的线程释放锁资源后该线程才能持有资源。等待队列通过双向链表实现，线程会被封装在链表的 Node 节点中，Node 的等待状态包括：CANCELLED 表示线程已取消、SIGNAL 表示线程需要唤醒、CONDITION 表示线程正在等待、PROPAGATE 表示后继节点会传播唤醒操作，只会在共享模式下起作用。

两种模式

独占模式表示锁会被一个线程占用，其他线程必须等到持有锁的线程释放锁后才能获取到锁继续执行，在同一时间内只能有一个线程获取到这个锁，ReentrantLock 就采用的是独占模式。

共享模式表示多个线程获取同一个锁的时候有可能会成功，ReadLock 就采用的是共享模式。

独占模式通过 acquire 和 release 方法获取和释放锁，共享模式通过 acquireShared 和 releaseShared 方法获取和释放锁。

独占式的获取和释放流程

在获取同步状态时，同步器调用 acquire 方法，维护一个同步队列，使用 tryAcquire 方法安全地获取线程同步状态，获取状态失败的线程会构造同步节点并通过 addWaiter 方法被加入到同步队列的尾部，并在队列中进行自旋。之后会调用 acquireQueued 方法使得该节点以死循环的方式获取同步状态，如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞节点被中断实现，移出队列或停止自旋的条件是前驱节点是头结点并且成功获取了同步状态。

在释放同步状态时，同步器调用 tryRelease 方法释放同步状态，然后调用 unparkSuccessor 方法（该方法使用 LockSupport 唤醒处于等待状态的线程）唤醒头节点的后继节点，进而使后继节点重新尝试获取同步状态。

只有当前驱节点是头节点时才能够尝试获取同步状态原因

头节点是成功获取到同步状态的节点，而头节点的线程释放同步状态之后，将会唤醒其后继节点，后继节点的线程被唤醒后需要检查自己的前驱节点是否是头节点。

维护同步队列的FIFO原则，节点和节点在循环检查的过程中基本不相互通信，而是简单地判断自己的前驱是否为头节点，这样就使得节点的释放规则符合FIFO，并且也便于对过早通知的处理（过早通知是指前驱节点不是头结点的线程由于中断而被唤醒）。

共享式的获取和释放流程

在获取同步状态时，同步器调用 acquireShared 方法，该方法调用 tryAcquireShared 方法尝试获取同步状态，返回值为 int 类型，当返回值大于等于 0 时表示能够获取到同步状态。因此在共享式获取锁的自旋过程中，成功获取到同步状态并退出自旋的条件就是该方法的返回值大于等于0。

释放同步状态时，调用 releaseShared 方法，释放同步状态后会唤醒后续处于等待状态的节点。对于能够支持多线程同时访问的并发组件，它和独占式的主要区别在于 tryReleaseShared 方法必须确保同步状态安全释放，一般通过循环和 CAS 来保证，因为释放同步状态的操作会同时来自多个线程。

---

P12：线程

现代操作系统在运行一个程序时会为其创建一个进程，而操作系统调度的最小单位是线程，线程也叫轻量级进程。在一个进程中可以创建多个线程，这些线程都拥有各自的计数器、堆栈和局部变量等属性，并且能够访问共享的内存变量。处理器在这些线程上告诉切换，让使用者感觉到这些线程在同时执行。

生命周期

① NEW：新建状态，是线程被创建且未启动的状态，此时还未调用 start 方法。

② RUNNABLE：Java 线程将操作系统中的就绪和运行两种状态统称为 RUNNABLE，此时线程有可能正在等待操作系统分配CPU时间片，也有可能正在执行。

③ BLOCKED：阻塞状态，可能由于锁被其他线程占用、调用了 sleep 或 join 方法、执行了 wait 方法等。

④ WAITING：等待状态，处于该状态的线程不会被分配CPU时间片，当前线程需要等待其他线程通知或中断。导致线程进入该状态的方法：无参数的 wait 和 join 方法、LockSupport 的 park 方法。

⑤ TIME_WAITING：限期等待状态，可以在指定时间内自行返回。导致线程进入该状态的方法：有参数的 wait 和 join 方法、LockSupport 的 parkNanos 和 parkUntil 方法。

⑥ TERMINATED：终止状态，表示当前线程已经执行完毕或异常退出。

实现方式

① 继承 Thread 类并重写 run 方法。优点是实现简单，缺点是不符合里氏替换原则，不可以继承其他类。② 实现 Runnable 接口并重写 run 方法。优点是避免了单继承的局限性，使编程更加灵活，实现解耦操作，对外暴露细节少。③实现 Callable 接口并重写 call 方法。优点是可以获取线程执行结果的返回值，并且可以抛出异常。

方法

① wait 是Object类的方法，调用 wait 方法的线程会进入 WAITING 状态，只有等待其他线程的通知或被中断后才会解除阻塞，调用wait方法会释放锁资源。② sleep 是 Thread 类的方法，调用 sleep 方法会导致当前线程进入休眠状态，与 wait 不同的是该方法不会释放锁资源，进入的是 TIMED-WAITING 状态。③ yiled 方法会使当前线程让出 CPU 时间片给优先级相同或更高的线程，回到 RUNNABLE 状态，与其他线程一起重新竞争CPU时间片。④ join 方法用于等待其他线程运行终止，如果当前线程调用了另一个线程的 join 方法，则当前线程进入阻塞状态，当另一个线程结束时当前线程才能从阻塞状态转为就绪态，等待获取CPU时间片。底层使用的是wait，也会释放锁。

守护线程

守护线程是一种支持型线程，因为它主要被用作程序中后台调度以及支持性工作，当 JVM