共计 11775 个字符，预计需要花费 30 分钟才能阅读完成。
前言
Synchronized 原理是面试中的一个难点。网上的各种材料太乱了，概念艰涩难懂，看了不少材料、博客，花了不少工夫，才整顿成这篇笔记。看完对你大有帮忙。
1、内存布局
要想理解 Synchronized 的原理，你先必须理解下Java 对象内存布局。
我这里就先介绍下 Java 内存布局。
当你通过关键字 new 关键字创立一个类的实例对象，对象存于内存的堆中，并给其调配一个内存地址，那么是否想过如下这些问题：
- 这个实例对象是以怎么的状态存在内存中的？
- 一个 Object 对象在内存中占用多大？
- 对象中的属性是如何在内存中调配的？
ps：创立一个对象的形式有很多种。你能够想想有哪些哦!
Java 对象在内存中的布局分为三块区域：对象头 、 实例数据 和对齐填充。如下图：
实例变量
即 实例数据 。寄存类的 属性数据信息 ， 包含父类的属性信息。
《2020 最新 Java 根底精讲视频教程和学习路线！》
- 如果对象有属性字段，则这里会有数据信息。如果对象无属性字段，则这里就不会有数据。
- 依据字段类型的不同占不同的字节。例如 boolean 类型占 1 个字节，int 类型占 4 个字节等等。这部分内存按 4 字节对齐。这部分的存储程序会受到虚拟机调配策略参数（FieldsAllocationStyle）和字段在 Java 源码中定义程序的影响。HotSpot 虚拟机 默认的调配策略为 longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers）。从调配策略中能够看出，雷同宽度的字段总是被调配到一起。在满足这个前提条件的状况下，在父类中定义的变量会呈现在子类之前。如果 CompactFields 参数值为 true（默认为 true），那子类之中较窄的变量也可能会插入到父类变量的空隙之中。
填充数据
填充数据不是必须存在的，仅仅是为了字节对齐 。因为 HotSpot VM 的主动内存管理系统要求 对象起始地址必须是 8 字节的整数倍 ，换句话说，就是对象的大小必须是 8 字节的整数倍。而对象头局部正好是 8 字节的倍数（1 倍或者 2 倍），因而， 当对象实例数据局部没有对齐时 ，就须要 通过对齐填充来补全。
为什么要对齐数据？
字段内存对齐的其中一个起因，是让字段只呈现在同一 CPU 的缓存行中。如果字段不是对齐的，那么就有可能呈现跨缓存行的字段。也就是说，该字段的读取可能须要替换两个缓存行，而该字段的存储也会同时净化两个缓存行。这两种状况对程序的执行效率而言都是不利的。其实对其填充的 最终目标是为了计算机高效寻址。
对象头
对象头是实现 synchronized 的锁对象的根底 ，咱们重点剖析下。
咱们能够在 Hotspot 官网文档 中找到它的形容（如下）：.
object header
Common structure at the beginning of every GC-managed heap object. (Every oop points to an object header.) Includes fundamental information about the heap object’s layout, type, GC state, synchronization state, and identity hash code. Consists of two words. In arrays it is immediately followed by a length field. Note that both Java objects and VM-internal objects have a common object header format.
从中能够发现，它是 Java 对象和虚拟机外部对象都有的独特格局，由 两个字 (计算机术语) 组成。另外，如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录 数组长度 的数据，因为虚拟机能够通过一般 Java 对象的元数据信息确定 Java 对象的大小，然而从数组的元数据中无奈确定数组的大小。
它外面提到了 对象头由两个字组成，这两个字是什么呢？咱们还是在下面的那个 Hotspot 官网文档中往上看，能够发现还有另外两个名词的定义解释，别离是 mark word 和 klass pointer：
klass pointer
The second word of every object header. Points to another object (a metaobject) which describes the layout and behavior of the original object. For Java objects, the “klass” contains a C++ style “vtable”.
mark word
The first word of every object header. Usually a set of bitfields including synchronization state and identity hash code. May also be a pointer (with characteristic low bit encoding) to synchronization related information. During GC, may contain GC state bits.
从中能够发现对象头中那两个字：第一个字就是 mark word，第二个就是 klass pointer。
Mark Word
即 标记字段 。用于 存储对象本身的运行时数据，如哈希码（HashCode）、GC 分代年龄、锁状态标记、线程持有的锁、偏差线程 ID、偏差工夫戳 等等。Mark Word 在 32 位 JVM 中的长度是 32bit，在 64 位 JVM 中长度是 64bit。咱们关上 openjdk 的源码包，对应门路 /openjdk/hotspot/src/share/vm/oops，Mark Word 对应到 C ++ 的代码 markOop.hpp，能够从正文中看到它们的组成，本文所有代码是基于 Jdk1.8。
因为对象头的信息是与对象本身定义的数据没有关系的额定存储老本，因而 思考到 JVM 的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多无效的数据，它会依据对象自身的状态复用本人的存储空间。
Mark Word 在不同的锁状态下存储的内容不同，在 32 位 JVM 中是这么存的:
在 64 位 JVM 中是这么存的:
尽管它们在不同位数的 JVM 中长度不一样，然而根本组成内容是统一的。
- 锁标记位（lock）：辨别锁状态，11 时示意对象待 GC 回收状态, 只有最初 2 位锁标识 (11) 无效。
- biased_lock：是否偏差锁，因为失常锁和偏差锁的锁标识都是 01，没方法辨别，这里引入一位的偏差锁标识位。
- 分代年龄（age）：示意对象被 GC 的次数，当该次数达到阈值的时候，对象就会转移到老年代。
- 对象的 hashcode（hash）：运行期间调用 System.identityHashCode()来计算，提早计算，并把后果赋值到这里。当对象加锁后，计算的后果 31 位不够示意，在偏差锁，轻量锁，分量锁，hashcode 会被转移到 Monitor 中。
- 偏差锁的线程 ID（JavaThread）：偏差模式的时候，当某个线程持有对象的时候，对象这里就会被置为该线程的 ID。在前面的操作中，就无需再进行尝试获取锁的动作。
- epoch：偏差锁在 CAS 锁操作过程中，偏差性标识，示意对象更偏差哪个锁。
- ptr_to_lock_record：轻量级锁状态下，指向栈中锁记录的指针。当锁获取是无竞争的时，JVM 应用原子操作而不是 OS 互斥。这种技术称为轻量级锁定。在轻量级锁定的状况下，JVM 通过 CAS 操作在对象的题目字中设置指向锁记录的指针。
- ptr_to_heavyweight_monitor：重量级锁状态下，指向对象监视器 Monitor 的指针。如果两个不同的线程同时在同一个对象上竞争，则必须将轻量级锁定降级到 Monitor 以治理期待的线程。在重量级锁定的状况下，JVM 在对象的 ptr_to_heavyweight_monitor 设置指向 Monitor 的指针。
Klass Pointer
即 类型指针 ， 是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
数组长度（只有数组对象有）
如果对象是一个数组，那在对象头中还必须有一块数据用于记录数组长度。因为虚拟机能够通过一般 Java 对象的元数据信息确定 Java 对象的大小，然而从数组的元数据中无奈确定数组的大小。
至此，咱们曾经理解了对象在堆内存中的整体构造布局，如下图所示：
2、Synchronized 底层实现
这里咱们次要剖析一下 synchronized 对象锁（也就是重量级锁）。在 32 位和 64 位机器上锁标识位都为 10，其中指针指向的是 monitor 对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现形式，如：monitor 能够与对象一起创立销毁或当线程试图获取对象锁时主动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。在 Java 虚拟机 (HotSpot) 中，monitor 是由 ObjectMonitor 实现的，其次要数据结构如下（位于 HotSpot 虚拟机源码 ObjectMonitor.hpp 文件，C++ 实现）
ObjectMonitor() {
_header = NULL;
_count = 0; // 记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; // 处于 wait 状态的线程，会被退出到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; // 处于期待锁 block 状态的线程，会被退出到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
} 咱们剖析下下面源码中几个要害属性：
- _WaitSet 和_EntryList：用来保留 ObjectWaiter 对象列表（ObjectWaiter 对象：每个期待锁的线程都会被封装成 ObjectWaiter 对象）。
- _owner：指向持有 ObjectMonitor 对象的线程。
当多个线程同时拜访一段同步代码时，首先会进入 _EntryList 汇合，当线程获取到对象的 monitor 后进入 _Owner 区域并把 monitor 中的 owner 变量设置为以后线程同时 monitor 中的 计数器 count加 1，若线程调用 wait() 办法，将开释以后持有的 monitor，owner 变量复原为 null，count 自减 1，同时该线程进入 WaitSet 汇合中期待被唤醒。若以后线程执行结束也将开释 monitor(锁)并复位变量的值，以便其余线程进入获取 monitor(锁)。如下图所示（图片起源：Thread Synchronization）:
由此看来，monitor 对象存在于每个 Java 对象的对象头中 (存储的是指针)，synchronized 锁便是通过这种形式获取锁的，也是为什么 Java 中任意对象能够作为锁的起因，同时也是 notify/notifyAll/wait 等办法存在于顶级对象 Object 中的起因。
上面咱们将进一步剖析 synchronized 在字节码层面的具体语义实现。
3、synchronized 润饰代码块底层原理
当初咱们从新定义一个 synchronized 润饰的同步代码块（i++），在代码块中操作共享变量 i，如下：
public class TestSafeAddI {
public int i;
public void addI() {synchronized (this) {i++;}
}
}应用反编译工具，查看编译后的字节码（残缺）：
如何查看字节码文件，有多种工具，我这里提供 2 种：
形式一：luyten 工具
运行工具，而后 Settings 抉择 ByteCode，而后导入本地的.class 文件即可。
形式二：应用 idea 编辑器的同学，能够在 idea 中选中编译后的.class 文件，而后 View->Show ByteCode
class com.top.test.mutiTheread.TestSafeAddI
Minor version: 0
Major version: 52
Flags: PUBLIC, SUPER
public int i;
Flags: PUBLIC
public void <init>();
Flags: PUBLIC
Code:
linenumber 3
0: aload_0 /* this */
1: invokespecial java/lang/Object.<init>:()V
4: return
public void addI();
Flags: PUBLIC
Code:
linenumber 7
0: aload_0 /* this */
1: dup
2: astore_1
3: monitorenter
linenumber 8
4: aload_0 /* this */
5: dup
6: getfield com/top/test/mutiTheread/TestSafeAddI.i:I
9: iconst_1
10: iadd
11: putfield com/top/test/mutiTheread/TestSafeAddI.i:I
linenumber 9
14: aload_1
15: monitorexit
16: goto 24
19: astore_2
20: aload_1
21: monitorexit
22: aload_2
23: athrow
linenumber 10
24: return
StackMapTable: 00 02 FF 00 13 00 02 07 00 10 07 00 11 00 01 07 00 12 FA 00 04
Exceptions:
Try Handler
Start End Start End Type
----- ----- ----- ----- ----
4 16 19 24 Any
19 22 19 24 Any 咱们次要关注字节码中的如下代码：
3: monitorenter // 进入同步办法
//.......... 省略其余
15: monitorexit // 退出同步办法
16: goto 24
// 省略其余.......
21: monitorexit // 退出同步办法 从字节码中可知同步语句块的实现应用的是 monitorenter 和monitorexi指令，其中 monitorenter 指令指向同步代码块的开始地位，monitorexit 指令则指明同步代码块的完结地位。
当执行 monitorenter 指令时:
- 以后线程将试图获取 objectref(即对象锁) 所对应的 monitor 的持有权，当 objectref 的 monitor 的进入计数器为 0，那线程能够胜利获得 monitor，并将计数器值设置为 1，取锁胜利。
- 如果以后线程曾经领有 objectref 的 monitor 的持有权，那它能够重入这个 monitor，重入时计数器的值也会加 1。这正是 synchronized 的可重入个性。（对于可重入锁能够看这篇: 可重入锁 -synchronized 是可重入锁吗？）
- 假使其余线程曾经领有 objectref 的 monitor 的所有权，即指标锁对象的计数器不为 0。那以后线程将被阻塞，直到正在执行线程执行结束.
当执行 monitorexit 时:
- Java 虚拟机则需将锁对象的计数器减 1。当计数器减为 0 时，那便代表该锁曾经被开释掉了。这样其余线程将有机会持有 monitor。
- 计数器不为 0，示意以后线程还持有该对象锁。
值得注意的是：一条指令 Monitorenter 能够对应到多条 monitorexit 指令。这是因为 Java 虚拟机须要确保所取得的锁在失常执行门路，以及异样执行门路上都可能被解锁。也就是说：编译器将会确保无论办法通过何种形式实现，办法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，而无论这个办法是失常完结还是异样完结。为了保障在办法异样实现时 monitorenter 和 monitorexit 指令仍然能够正确配对执行，编译器会主动产生一个异样处理器，这个异样处理器申明可解决所有的异样，它的目标就是用来执行 monitorexit 指令。从字节码中也能够看出多了一个 monitorexit 指令，它就是异样完结时被执行的开释 monitor 的指令。
4、synchronized 润饰办法底层原理
synchronized 润饰办法与润饰代码块有不同。
咱们把下面的同步办法改下，改成 synchronized 润饰办法：
public class TestSafeAddI {
public int i;
public synchronized void addI() {i++;}
} 反编译后的字节码如下：
class com.top.test.mutiTheread.TestSafeAddI
Minor version: 0
Major version: 52
Flags: PUBLIC, SUPER
public int i;
Flags: PUBLIC
public void <init>();
Flags: PUBLIC
Code:
linenumber 3
0: aload_0 /* this */
1: invokespecial java/lang/Object.<init>:()V
4: return
public synchronized void addI();
Flags: PUBLIC, SYNCHRONIZED
Code:
linenumber 7
0: aload_0 /* this */
1: dup
2: getfield com/top/test/mutiTheread/TestSafeAddI.i:I
5: iconst_1
6: iadd
7: putfield com/top/test/mutiTheread/TestSafeAddI.i:I
linenumber 8
10: return 当用 synchronized 标记办法 时，并 没有 monitorenter 指令和 monitorexit 指令 ，从字节码中，咱们能够看到办法的 拜访标记 包含 ACC_SYNCHRONIZED 了。该标识指明了该办法是一个 同步办法 ，JVM 通过该 ACC_SYNCHRONIZED 拜访标记来分别一个办法是否申明为同步办法，从而执行相应的同步调用。在 进入该办法时 ，Java 虚拟机须要 进行 monitorenter 操作 。而在 退出该办法时 ，不论是失常返回，还是向调用者抛异样，Java 虚拟机均须要 进行 monitorexit 操作 。
这里 monitorenter 和 monitorexit 操作所对应的锁对象是 隐式 的。对于实例办法来说，这两个操作对应的锁对象是 this；对于静态方法来说，这两个操作对应的锁对象则是所在类的 Class 实例。
同时咱们还必须留神到的是在 Java 晚期版本中，synchronized 属于 重量级锁 ，效率低下。因为监视器锁（monitor）是依赖于底层的操作系统的 Mutex Lock 来实现的，而操作系统实现线程之间的切换时须要 从用户态转换到外围态 。这个状态之间的转换须要绝对比拟长的工夫，工夫老本绝对较高，这也是为什么 晚期的 synchronized 效率低 的起因。。
5、锁的降级
锁的降级，咱们能够了解为：Java 虚拟机对 synchronized 的优化
为了尽量避免低廉的线程阻塞、唤醒操作，Java 虚构机会在线程进入阻塞状态之前，以及被唤醒后竞争不到锁的状况下，进入 自旋状态 ，在处理器上 空跑并且轮询 锁是否被开释。如果此时锁恰好被开释了，那么以后线程便毋庸进入阻塞状态，而是间接取得这把锁。咱们称其为 自旋锁 。同时在Java6 之后 Java 官网对从 JVM 层面对 synchronized 较大优化，所以当初的 synchronized 锁效率也优化得很不错了，Java 6 之后，为了缩小取得锁和开释锁所带来的性能耗费，引入了 轻量级锁 和偏差锁（也叫：偏斜锁，英文单词为，Biased Locking）。
锁的降级：锁的状态总共有四种（下面的 Mark Word 图构造也能够看出），无锁状态、偏差锁、轻量级锁和重量级锁 。随着锁的竞争，锁能够 从偏差锁降级到轻量级锁，再降级的重量级锁。
ps: 有的观点认为 Java 不会进行锁降级。实际上，锁降级的确是会产生的，当 JVM 进入 平安点（SafePoint）的时候，会查看是否有闲置的 Monitor，而后试图进行降级。
对于重量级锁，后面咱们已详细分析过。上面咱们将介绍偏差锁、轻量级锁、自旋锁以及 JVM 的其余优化伎俩。
6、偏差锁
偏差锁 是 Java 6 之后退出的新锁，它是一种针对加锁操作的优化伎俩。
偏差锁是 最乐观的 一种状况：在大多数状况下，锁不仅不存在多线程竞争，而且总是由同一线程屡次取得。因而为了 缩小同一线程获取锁的代价 而引入偏差锁。
偏差锁的 核心思想 是：如果一个线程取得了锁，那么锁就进入偏差模式，此时 Mark Word 的构造也变为偏差锁构造，当这个线程再次申请锁时，无需再做任何同步操作，间接能够获取锁。这样就省去了大量无关锁申请的操作，从而也就提供程序的性能。
加锁时 ，如果该锁对象反对偏差锁，那么 Java 虚构机会通过CAS 操作，将 以后线程的地址 （我了解的是线程 ID，不过都能确定惟一线程） 记录在锁对象的标记字段之中，并且将标记字段的最初三位设置为101。（便于了解，我把 Mark Word 的结构图再放在这里）
CAS 是一个原子操作，它会比拟指标地址的值是否和期望值相等，如果相等，则替换为一个新的值。
在接下来的运行过程中，每当有线程申请这把锁，Java 虚拟机只需判断锁对象标记字段中：最初三位是否为 101，是否蕴含以后线程的地址，以及 epoch 值 是否和锁对象的类的 epoch 值雷同。如果都满足，那么以后线程持有该偏差锁，能够间接返回。
了解 epoch 值：
咱们先从 偏差锁的撤销 讲起。当申请加锁的线程和锁对象标记字段的线程地址不匹配时（而且 epoch 值相等，如若不等，那么以后线程能够将该锁重偏差至本人），Java 虚拟机须要撤销该偏差锁。这个撤销过程十分麻烦，它要求持有偏差锁的线程达到平安点，再将偏差锁替换成轻量级锁。
如果某一类锁对象的 总撤销数超过了一个阈值 （对应 Java 虚拟机参数 -XX:BiasedLockingBulkRebiasThreshold，默认为 20），那么 Java 虚构机会发表这个类的 偏差锁生效 。
具体的做法便是在每个类中保护一个 epoch 值，你能够了解为第几代偏差锁。当设置偏差锁时，Java 虚拟机须要将该 epoch 值复制到锁对象的标记字段中。
在发表某个类的偏差锁生效时，Java 虚拟机实则将该类的 epoch 值加 1，示意之前那一代的偏差锁曾经生效。而新设置的偏差锁则须要复制新的 epoch 值。
为了保障以后持有偏差锁并且已加锁的线程不至于因而丢锁，Java 虚拟机须要遍历所有线程的 Java 栈，找出该类已加锁的实例，并且将它们标记字段中的 epoch 值加 1。该操作须要所有线程处于平安点状态。
如果 总撤销数超过另一个阈值 （对应 Java 虚拟机参数 -XX:BiasedLockingBulkRevokeThreshold，默认值为 40），那么 Java 虚构机会认为 这个类曾经不再适宜偏差锁 。此时，Java 虚构机会 撤销该类实例的偏差锁 ，并且在 之后 的加锁过程中间接为该类实例设置 轻量级锁。
7、轻量级锁
假使偏差锁失败，并不会立刻收缩为重量级锁，而是先降级为轻量级锁
轻量级锁时 Java6 引入的。
轻量级锁是一种比拟乐观的状况：多个线程在不同的时间段申请同一把锁，也就是说没有锁竞争。
标记字段（mark word）的最初两位被用来示意该对象的锁状态。其中，00 代表轻量级锁，01 代表无锁（或偏差锁），10 代表重量级锁。
当进行 加锁 操作时，Java 虚构机会判断是否曾经是重量级锁。如果不是，它会在 以后线程 的以后 栈桢 中划出一块空间，作为该锁的 锁记录 ，并且将 锁对象的标记字段 复制 到该锁记录中（能够了解为保留之前锁对象的标记字段。如果是同一个线程这个值会是 0：前面的锁记录清零就是这个意思）。
而后，Java 虚构机会尝试用 CAS（compare-and-swap）操作替换锁对象的标记字段。
假如以后锁对象的标记字段为 X…XYZ，Java 虚构机会比拟该字段是否为 X…X01（锁标记位 01 示意偏差锁）。如果是，则替换为方才调配的锁记录的地址。因为内存对齐的缘故，它的最初两位为 00（锁标记位 00 示意轻量级锁）。此时，该线程已胜利取得这把锁，能够继续执行了。
如果不是 X…X01，那么有两种可能。第一，该线程反复获取同一把锁（此刻持有的是轻量级锁）。此时，Java 虚构机会将锁记录清零，以代表该锁被反复获取（可重入锁能够浏览下：）。第二，其余线程持有该锁（此刻持有的是轻量级锁）。此时，Java 虚构机会将这把锁收缩为重量级锁，并且阻塞以后线程。
当进行 解锁 操作时，如果以后锁记录（你能够将一个线程的所有锁记录设想成一个栈构造，每次加锁压入一条锁记录，解锁弹出一条锁记录，以后锁记录指的便是栈顶的锁记录）的值为 0，则代表反复进入同一把锁，间接返回即可。
否则，Java 虚构机会尝试用 CAS 操作，比拟锁对象的标记字段的值是否为以后锁记录的地址。如果是，则替换为锁记录中的值，也就是锁对象本来的标记字段。此时，该线程曾经胜利开释这把锁。
如果不是，则意味着这把锁曾经被收缩为 重量级锁。此时，Java 虚构机会进入重量级锁的开释过程，唤醒因竞争该锁而被阻塞了的线程。
8、自旋锁
轻量级锁失败后，虚拟机为了防止线程实在地在操作系统层面挂起，还会进行一项称为自旋锁的优化伎俩。
这是 基于在大多数状况 下，线程持有锁的工夫都不会太长，如果间接挂起操作系统层面的线程可能会得失相当，毕竟操作系统实现线程之间的切换时须要从用户态转换到外围态，这个状态之间的转换须要绝对比拟长的工夫，工夫老本绝对较高。
因而自旋锁会假如在不久未来，以后的线程能够取得锁，因而虚构机会让以后想要获取锁的线程做几个空循环 (这也是称为自旋的起因)，个别不会太久，可能是 50 个循环或 100 循环，在通过若干次循环后，如果失去锁，就顺利进入临界区。如果还不能取得锁，那就会将线程在操作系统层面挂起。
这就是自旋锁的优化形式，这种形式的确也是能够晋升效率的。最初没方法也就只能降级为重量级锁了。
举个例子： 咱们能够用等红绿灯作为例子。Java 线程的阻塞相当于熄火停车，而自旋状态相当于怠速停车。如果红灯的等待时间十分长，那么熄火停车绝对省油一些；如果红灯的等待时间十分短，比如说咱们在 synchronized 代码块里只做了一个整型加法，那么在短时间内锁必定会被释放出来，因而怠速停车更加适合。然而，对于 Java 虚拟机来说，它并不能看到红灯的剩余时间，也就没方法依据等待时间的长短来抉择自旋还是阻塞。Java 虚拟机给出的计划是自适应自旋，依据以往自旋期待时是否可能取得锁，来动静调整自旋的工夫（循环数目）。就咱们的例子来说，如果之前不熄火等到了绿灯，那么这次不熄火的工夫就长一点；如果之前不熄火没等到绿灯，那么这次不熄火的工夫就短一点。
自旋状态还带来另外一个副作用，那便是 不偏心的锁机制。处于阻塞状态的线程，并没有方法立即竞争被开释的锁。然而，处于自旋状态的线程，则很有可能优先取得这把锁。（对于偏心锁与非偏心锁能够看这篇：偏心锁和非偏心锁 -ReentrantLock 是如何实现偏心、非偏心的）
9、锁打消
打消锁是虚拟机另外一种锁的优化，这种优化更彻底，Java 虚拟机在 JIT 编译时 (能够简略了解为当某段代码行将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种形式打消没有必要的锁，能够节俭毫无意义的申请锁工夫。
如下 StringBuffer 的 append 是一个同步办法，然而在 add 办法中的 StringBuffer 属于一个局部变量，并且不会被其余线程所应用，因而 StringBuffer 不可能存在共享资源竞争的情景，JVM 会主动将其锁打消。
public class StringBufferRemoveSync {public void add(String str1, String str2) {
//StringBuffer 是线程平安, 因为 sb 只会在 append 办法中应用, 不可能被其余线程援用
// 因而 sb 属于不可能共享的资源,JVM 会主动打消外部的锁
StringBuffer sb = new StringBuffer();
sb.append(str1).append(str2);
}
public static void main(String[] args) {StringBufferRemoveSync rmsync = new StringBufferRemoveSync();
for (int i = 0; i < 10000000; i++) {rmsync.add("abc", "123");
}
}
} 总结
我整顿的还不够欠缺，比方：内存布局的压缩指针和字段重排列我都没有提及。
链接：https://juejin.im/post/6894099621694406669