synchronized实现原理及代码证明各种锁
对象头
在上一篇文章《AtmoicXXX 与 AtmoicXXXArray 源码分析》中，简单的介绍了对象头，咱们今天仔细的介绍下对象头。
|--------------------------------------------------------------------------------------------------------------|--------------------|
| Object Header (96 bits) | State |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| Mark Word (64 bits) | Klass Word (32 bits) | |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| unused:25 | identity_hashcode:31 | cms_free:1 | age:4 | biased_lock:1 | lock:2 | OOP to metadata object | Normal |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| thread:54 | epoch:2 | cms_free:1 | age:4 | biased_lock:1 | lock:2 | OOP to metadata object | Biased |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| ptr_to_lock_record | lock:2 | OOP to metadata object | Lightweight Locked |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| ptr_to_heavyweight_monitor | lock:2 | OOP to metadata object | Heavyweight Locked |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|
| | lock:2 | OOP to metadata object | Marked for GC |
|--------------------------------------------------------------------------------|-----------------------------|--------------------|首先对象头的代码定义在HotSpot代码中，
class oopDesc {
friend class VMStructs;
private:
volatile markOop _mark;
union _metadata {
Klass* _klass;
narrowKlass _compressed_klass;
} _metadata;
// Fast access to barrier set. Must be initialized.
static BarrierSet* _bs;
// 其他代码生活
}在普通实例对象中，oopDesc的定义包含两个成员，分别是mark和metadata，mark 表示对象标记、属于markOop类型，也就是接下来要讲解的Mark World，它记录了对象和锁有关的信息metadata表示类元信息，类元信息metadata存储的是对象指向它的类元数据(Klass)的首地址，其中Klass表示普通指针、compressedklass表示压缩类指针。
对象头由两部分组成，一部分用于存储自身的运行时数据，称之为 Mark Word，另外一部分是类型指针，及对象指向它的类元数据的指针。
Mark Word
Mark Word用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，占用内存大小与虚拟机位长一致。Mark Word对应的类型是markOop。源码位于markOop.hpp中。
klass pointer
这一部分用于存储对象的类型指针，该指针指向它的类元数据，JVM通过这个指针确定对象是哪个类的实例。该指针的位长度为JVM的一个字大小，即32位的JVM为32位，64位的JVM为64位。如果应用的对象过多，使用64位的指针将浪费大量内存，统计而言，64位的JVM将会比32位的JVM多耗费50%的内存。为了节约内存可以使用选项-XX:+UseCompressedOops开启指针压缩，其中，oop即ordinaryobject pointer普通对象指针。开启该选项后，下列指针将压缩至32位：
- 每个Class的属性指针（即静态变量）
- 每个对象的属性指针（即对象变量）
- 普通对象数组的每个元素指针
当然，也不是所有的指针都会压缩，一些特殊类型的指针JVM不会优化，比如指向PermGen的Class对象指针(JDK8中指向元空间的Class对象指针)、本地变量、堆栈元素、入参、返回值和NULL指针等。
synchronized原理
首先先简单的写2个有synchronized的代码
public void testSpin() {
synchronized (lock) {
System.out.println(Thread.currentThread().getName() + "打印对象头");
for (int i = 0; i < 5; i++) {
if (i==4) {
System.out.println(ClassLayout.parseInstance(lock).toPrintable());
}
}
}
}
public synchronized void testSpin1() {
synchronized (lock) {
System.out.println(Thread.currentThread().getName() + "打印对象头");
for (int i = 0; i < 5; i++) {
System.out.println(ClassLayout.parseInstance(lock).toPrintable());
try {
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}通过javap -v -p反编译后
public void testSpin();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=4, args_size=1
0: aload_0
1: getfield #3 // Field lock:Ljava/lang/Object;
4: dup
5: astore_1
6: monitorenter //锁进入
7: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream;
10: new #12 // class java/lang/StringBuilder
13: dup
14: invokespecial #13 // Method java/lang/StringBuilder."<init>":()V
17: invokestatic #14 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
20: invokevirtual #15 // Method java/lang/Thread.getName:()Ljava/lang/String;
23: invokevirtual #16 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
26: ldc #17 // String 打印对象头
28: invokevirtual #16 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
31: invokevirtual #18 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
34: invokevirtual #19 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
37: iconst_0
38: istore_2
39: iload_2
40: iconst_5
41: if_icmpge 71
44: iload_2
45: iconst_4
46: if_icmpne 65
49: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream;
52: aload_0
53: getfield #3 // Field lock:Ljava/lang/Object;
56: invokestatic #20 // Method org/openjdk/jol/info/ClassLayout.parseInstance:(Ljava/lang/Object;)Lorg/openjdk/jol/info/ClassLayout;
59: invokevirtual #21 // Method org/openjdk/jol/info/ClassLayout.toPrintable:()Ljava/lang/String;
62: invokevirtual #19 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
65: iinc 2, 1
68: goto 39
71: aload_1
72: monitorexit //锁释放
73: goto 81
76: astore_3
77: aload_1
78: monitorexit //锁释放
79: aload_3
80: athrow
81: return
Exception table:
from to target type
7 73 76 any
76 79 76 any
public synchronized void testSpin1();
descriptor: ()V
flags: ACC_PUBLIC, ACC_SYNCHRONIZED // 锁标志
Code:
stack=3, locals=3, args_size=1
0: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream;
3: new #12 // class java/lang/StringBuilder
6: dup
7: invokespecial #13 // Method java/lang/StringBuilder."<init>":()V
10: invokestatic #14 // Method java/lang/Thread.currentThread:()Ljava/lang/Thread;
13: invokevirtual #15 // Method java/lang/Thread.getName:()Ljava/lang/String;
16: invokevirtual #16 上面反编译后的代码可以看出，同步代码块是monitorenter和monitorexit实现的，同步方法是通过ACC_SYNCHRONIZED标志实现的。
首先我们来看一下JVM规范中对于monitorenter和monitorexit的描述：
monitorenter
Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:
- If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor.
- If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count.
- If another thread already owns the monitor associated with objectref, the thread blocks until the monitor's entry count is zero, then tries again to gain ownership.
翻译过来：
每一个对象都会和一个监视器monitor关联。监视器被占用时会被锁住，其他线程无法来获取该monitor。当JVM执行某个线程的某个方法内部的monitorenter时，它会尝试去获取当前对象对应的monitor的所有权。其过程如下：
1. 若monior的进入数为0，线程可以进入monitor，并将monitor的进入数置为1。当前线程成为monitor的owner（所有者）
2. 若线程已拥有monitor的所有权，允许它重入monitor，则进入monitor的进入数加1
3. 若其他线程已经占有monitor的所有权，那么当前尝试获取monitor的所有权的线程会被阻塞，直到monitor的进入数变为0，才能重新尝试获取monitor的所有权。
synchronized的锁对象会关联一个monitor,这个monitor不是我们主动创建的,是JVM的线程执行到这个同步代码块,发现锁对象没有monitor就会创建monitor,monitor内部有两个重要的成员变量owner:拥有这把锁的线程,recursions会记录线程拥有锁的次数,当一个线程拥有monitor后其他线程只能等待。
monitorexit
The objectref must be of type reference.
The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref.
The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.
翻译过来：
1. 能执行monitorexit指令的线程一定是拥有当前对象的monitor的所有权的线程。
2. 执行monitorexit时会将monitor的进入数减1。当monitor的进入数减为0时，当前线程退出monitor，不再拥有monitor的所有权，此时其他被这个monitor阻塞的线程可以尝试去获取这个monitor的所有权。
monitorexit插入在方法结束处和异常处，JVM保证每个monitorenter必须有对应的monitorexit。
同步方法（ACC_SYNCHRONIZED）
首先看看JVM文档对于Synchronization的介绍，可以总结为：同步方法在反汇编后，会增加ACC_SYNCHRONIZED修饰。会隐式调用monitorenter和monitorexit。在执行同步方法前会调用monitorenter，在执行完同步方法后会调用monitorexit。
monitor锁
可以看出无论是synchronized代码块还是synchronized方法，其线程安全的语义实现最终依赖一个叫monitor的东西，那么这个神秘的东西是什么呢？下面让我们来详细介绍一下。在HotSpot虚拟机中，monitor是由ObjectMonitor实现的。其源码是用c++来实现的，位于HotSpot虚拟机源码ObjectMonitor.hpp文件中。ObjectMonitor主要数据结构如下：
ObjectMonitor() {
_header = NULL;
_count = 0;
_waiters = 0,
_recursions = 0; // 线程的重入次数
_object = NULL; // 存储该monitor的对象
_owner = NULL; // 标识拥有该monitor的线程
_WaitSet = NULL; // 处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ; // 多线程竞争锁时的单向列表
FreeNext = NULL ;
_EntryList = NULL ; // 处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}- owner：初始时为NULL。当有线程占有该monitor时，owner标记为该线程的唯一标识。当线程释放monitor时，owner又恢复为NULL。owner是一个临界资源，JVM是通过CAS操作来保证其线程安全的。
- cxq：竞争队列，所有请求锁的线程首先会被放在这个队列中（单向链接）。cxq是一个临界资源，JVM通过CAS原子指令来修改cxq队列。修改前cxq的旧值填入了node的next字段，cxq指向新值（新线程）。因此cxq是一个后进先出的stack（栈）。
- EntryList：cxq队列中有资格成为候选资源的线程会被移动到该队列中。
- WaitSet：因为调用wait方法而被阻塞的线程会被放在该队列中。
每一个Java对象都可以与一个监视器monitor关联，我们可以把它理解成为一把锁，当一个线程想要执行一段被synchronized圈起来的同步方法或者代码块时，该线程得先获取到synchronized修饰的对象对应的monitor。
我们的Java代码里不会显示地去创造这么一个monitor对象，我们也无需创建，事实上可以这么理解：monitor并不是随着对象创建而创建的。我们是通过synchronized修饰符告诉JVM需要为我们的某个对象创建关联的monitor对象。每个线程都存在两个ObjectMonitor对象列表，分别为free和used列表。同时JVM中也维护着global locklist。当线程需要ObjectMonitor对象时，首先从线程自身的free表中申请，若存在则使用，若不存在则从global list中申请。
ObjectMonitor的数据结构中包含：owner、WaitSet和_EntryList，它们之间的关系转换可以用下图表示：
synchronized锁升级过程
高效并发是从JDK 5到JDK 6的一个重要改进，HotSpot虛拟机开发团队在这个版本上花费了大量的精力去实现各种锁优化技术，包括偏向锁( Biased Locking )、轻量级锁( Lightweight Locking )和如适应性自旋(Adaptive Spinning)、锁消除( Lock Elimination)、锁粗化( Lock Coarsening )等，这些技术都是为了在线程之间更高效地共享数据，以及解决竞争问题，从而提高程序的执行效率。
无锁--》偏向锁--》轻量级锁–》重量级锁
偏向锁
偏向锁是JDK 6中的重要引进，因为HotSpot作者经过研究实践发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低，引进了偏向锁。偏向锁的“偏”，就是偏心的“偏”、偏袒的“偏”，它的意思是这个锁会偏向于第一个获得它的线程，会在对象头存储锁偏向的线程ID，以后该线程进入和退出同步块时只需要检查是否为偏向锁、锁标志位以及ThreadID即可。
偏向锁与hashcode
偏向锁的时候，对象头中保存的是线程ID，那么hashcode保存在哪里呢，或者是先计算了hashcode，还能实现偏向锁吗？
- 当一个对象已经计算过identity hash code，它就无法进入偏向锁状态；
- 当一个对象当前正处于偏向锁状态，并且需要计算其identity hash code的话，则它的偏向锁会被撤销，并且锁会膨胀为重量锁；
- 重量锁的实现中，ObjectMonitor类里有字段可以记录非加锁状态下的mark word，其中可以存储identity hash code的值。或者简单说就是重量锁可以存下identity hash code。
请一定要注意，这里讨论的hash code都只针对identity hash code。用户自定义的hashCode()方法所返回的值跟这里讨论的不是一回事。Identity hash code是未被覆写的 java.lang.Object.hashCode() 或者 java.lang.System.identityHashCode(Object) 所返回的值。
偏向锁的获取
当线程第一次访问同步块并获取锁时，偏向锁处理流程如下：
- 虚拟机将会把对象头中的偏向模式为“1”，即偏向模式；
- 同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作，偏向锁的效率高。
具体来说，在线程进行加锁时，如果该锁对象支持偏向锁，那么 Java 虚拟机会通过 CAS操作，将当前线程的地址记录在锁对象的标记字段之中，并且将标记字段的最后三位设置为：1 01；
在接下来的运行过程中，每当有线程请求这把锁，Java 虚拟机只需判断锁对象标记字段中：最后三位是否为： 1 01，是否包含当前线程的地址，以及 epoch 值是否和锁对象的类的epoch 值相同。如果都满足，那么当前线程持有该偏向锁，可以直接返回；
偏向锁的撤销
epoch是什么
如果某一类锁对象的总撤销数超过了一个阈值（对应 jvm参数 -XX:BiasedLockingBulkRebiasThreshold，默认为 20），那么 Java 虚拟机会宣布这个类的偏向锁失效；进行批量重偏向；具体的做法便是在每个类中维护一个 epoch 值，你可以理解为第几代偏向锁。当设置偏向锁时，Java 虚拟机需要将该 epoch 值复制到锁对象的标记字段中；
- 在宣布某个类的偏向锁失效时，Java 虚拟机实则将该类的 epoch 值加 1，表示之前那一代的偏向锁已经失效。而新设置的偏向锁则需要复制新的 epoch 值；为了保证当前持有偏向锁并且已加锁的线程不至于因此丢锁，Java 虚拟机需要遍历所有线程的 Java 栈，找出该类已加锁的实例，并且将它们标记字段中的 epoch 值加 1。该操作需要所有线程处于安全点状态；
- 如果总撤销数超过另一个阈值（对应 jvm 参数 -XX:BiasedLockingBulkRevokeThreshold，默认值为 40），那么 Java 虚拟机会认为这个类已经不再适合偏向锁。此时，Java 虚拟机会撤销该类实例的偏向锁，并且在之后的加锁过程中直接为该类实例设置轻量级锁(这里说的就是偏向批量撤销)。
代码示例：
import org.openjdk.jol.info.ClassLayout;
import java.util.ArrayList;
import java.util.List;
/**
* 批量重偏向
*/
public class ReBiasLock1 {
public static void main(String[] args) throws Exception {
//延时产生可偏向对象
//默认4秒之后才能进入偏向模式，可以通过参数-XX:BiasedLockingStartupDelay=0设置
Thread.sleep(5000);
//创造100个偏向线程t1的偏向锁
List<TestDemo> listA = new ArrayList<>();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
TestDemo a = new TestDemo();
synchronized (a) {
listA.add(a);
}
}
try {
//为了防止JVM线程复用，在创建完对象后，保持线程t1状态为存活
Thread.sleep(100000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
t1.start();
//睡眠3s钟保证线程t1创建对象完成
Thread.sleep(3000);
System.out.println("打印t1线程，list中第20个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(19)).toPrintable()));
//创建线程t2竞争线程t1中已经退出同步块的锁
Thread t2 = new Thread(() -> {
//这里面只循环了30次！！！
for (int i = 0; i < 30; i++) {
TestDemo a = listA.get(i);
if (i == 22) {
a = listA.get(10);
}
synchronized (a) {
//分别打印第19次和第20次偏向锁重偏向结果
if (i == 18 || i == 19) {
System.out.println("第" + (i + 1) + "次偏向结果");
System.out.println((ClassLayout.parseInstance(a).toPrintable()));
}
if (i == 22) {
// 该对象已经是轻量级锁，无法降级，因此只能是轻量级锁
System.out.println("第" + (i + 1) + "次偏向结果");
System.out.println((ClassLayout.parseInstance(a).toPrintable()));
}
}
}
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
t2.start();
Thread.sleep(3000);
System.out.println("打印list中第11个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(10)).toPrintable()));
System.out.println("打印list中第26个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(25)).toPrintable()));
System.out.println("打印list中第41个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(40)).toPrintable()));
}
}
import org.openjdk.jol.info.ClassLayout;
import java.util.ArrayList;
import java.util.List;
/**
* 偏向批量撤销
*/
public class ReBiasLock2 {
public static void main(String[] args) throws Exception {
//默认4秒之后才能进入偏向模式，可以通过参数-XX:BiasedLockingStartupDelay=0设置
Thread.sleep(5000);
List<TestDemo> listA = new ArrayList<>();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 100; i++) {
TestDemo a = new TestDemo();
synchronized (a) {
listA.add(a);
}
}
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
t1.start();
Thread.sleep(3000);
Thread t2 = new Thread(() -> {
//这里循环了40次。前20次进行锁撤销，后面执行 批量重偏向
for (int i = 0; i < 40; i++) {
TestDemo a = listA.get(i);
synchronized (a) {
}
}
try {
Thread.sleep(10000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
t2.start();
//———————————分割线，前面代码不再赘述——————————————————————————————————————————
Thread.sleep(3000);
System.out.println("打印list中第11个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(10)).toPrintable()));
System.out.println("打印list中第26个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(25)).toPrintable()));
System.out.println("打印list中第90个对象的对象头：");
System.out.println((ClassLayout.parseInstance(listA.get(89)).toPrintable()));
// 在执行20次偏向锁撤销，达到偏向批量撤销阈值
Thread t3 = new Thread(() -> {
for (int i = 20; i < 40; i++) {
TestDemo a = listA.get(i);
synchronized (a) {
if (i == 20 || i == 22) {
System.out.println("thread3 第" + i + "次");
System.out.println((ClassLayout.parseInstance(a).toPrintable()));
}
}
}
});
t3.start();
Thread.sleep(10000);
System.out.println("重新输出新实例A");
// 新对象无法偏向
System.out.println((ClassLayout.parseInstance(new TestDemo()).toPrintable()));
}
}
偏向锁的相关参数
偏向锁在Java 6之后是默认启用的，但在应用程序启动几秒钟之后才激活，可以使用-XX:BiasedLockingStartupDelay=0参数关闭延迟，如果确定应用程序中所有锁通常情况下处于竞争状态，可以通过XX:-UseBiasedLocking=false参数关闭偏向锁。
偏向锁的使用场景
- 偏向锁是为了在资源没有被多线程竞争的情况下尽量减少锁带来的性能开销。
- 在锁对象的对象头中有一个
ThreadId字段，当第一个线程访问锁时，如果该锁没有被其他线程访问过，即ThreadId字段为空，那么JVM让其持有偏向锁，并将ThreadId字段的值设置为该线程的ID。当下一次获取锁的时候，会判断ThreadId是否相等，如果一致就不会重复获取锁，从而提高了运行效率。 - 如果存在锁的竞争情况，偏向锁就会被撤销并升级为轻量级锁。
偏向锁的状态
匿名偏向(Anonymously biased)在此状态下thread pointer为NULL(0)，意味着还没有线程偏向于这个锁对象。第一个试图获取该锁的线程将会面临这个情况，使用原子CAS指令可将该锁对象绑定于当前线程。这是允许偏向锁的类对象的初始状态。
可重偏向(Rebiasable)在此状态下，偏向锁的epoch字段是无效的（与锁对象对应的class的mark_prototype的epoch值不匹配）。下一个试图获取锁对象的线程将会面临这个情况，使用原子CAS指令可将该锁对象绑定于当前线程**。在批量重偏向的操作中，未被持有的锁对象都被至于这个状态，以便允许被快速重偏向。
已偏向(Biased)这种状态下，thread pointer非空，且epoch为有效值——意味着其他线程正在持有这个锁对象。
轻量级锁
什么是轻量级锁
轻量级锁是JDK 6之中加入的新型锁机制，它名字中的“轻量级”是相对于使用monitor的传统锁而言的，因此传统的锁机制就称为“重量级”锁。首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的。引入轻量级锁的目的：在多线程交替执行同步块的情况下，尽量避免重量级锁引起的性能消耗，但是如果多个线程在同一时刻进入临界区，会导致轻量级锁膨胀升级重量级锁，所以轻量级锁的出现并非是要替代重量级锁。
轻量级锁的获取
当关闭偏向锁功能或者多个线程竞争偏向锁导致偏向锁升级为轻量级锁，则会尝试获取轻量级锁，其步骤如下：
1. 判断当前对象是否处于无锁状态（hashcode、0、01），如果是，则JVM首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word），将对象的Mark Word复制到栈帧中的Lock Record中，将Lock Reocrd中的owner指向当前对象。
2. JVM利用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，如果成功表示竞争到锁，则将锁标志位变成00，执行同步操作。
3. 如果失败则，这种情况：
3.1 判断当前对象的Mark Word是否指向当前线程的栈帧，如果是则表示当前线程已经持有当前对象的锁，再增加一个lock record，如图所示，然后执行同步代码块。
3.2否则只能说明该锁对象已经被其他线程抢占了，这时轻量级锁需要膨胀为重量级锁，锁标志位变成10，后面等待的线程将会进入阻塞状态。
轻量级锁的释放
轻量级锁的释放也是通过CAS操作来进行的，主要步骤如下：
1. 取出在获取轻量级锁保存在Displaced Mark Word中的数据。
2. 用CAS操作将取出的数据替换当前对象的Mark Word中，如果成功，则说明释放锁成功。
3. 如果CAS操作替换失败，说明有其他线程尝试获取该锁，则需要将轻量级锁需要膨胀升级为重量级锁。
轻量级锁的使用场景
对于轻量级锁，其性能提升的依据是“对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，如果打破这个依据则除了互斥的开销外，还有额外的CAS操作，因此在有多线程竞争的情况下，轻量级锁比重量级锁更慢。
偏向锁膨胀为轻量级锁代码
/**
* 偏向锁膨胀为轻量级锁
*/
public class DemoLightWeight {
public static void main(String[] args) throws Exception {
TestDemo testDemo = new TestDemo();
//子线程
Thread t1 = new Thread() {
@Override
public void run() {
synchronized (testDemo) {
System.out.println("t1 lock ing");
System.out.println(ClassLayout.parseInstance(testDemo).toPrintable());
}
}
};
t1.start();
t1.join();
//主线程
synchronized (testDemo) {
System.out.println("main lock ing");
//System.out.println(Integer.toHexString(testDemo.hashCode()));
System.out.println(ClassLayout.parseInstance(testDemo).toPrintable());
}
}
}
重量级锁
就是上面介绍的monitor锁。来个代码示例
/**
* 轻量级膨胀到重量级
*/
public class DemoHeavyWeight {
public static void main(String[] args) throws Exception {
TestDemo testDemo = new TestDemo();
Thread t1 = new Thread(){
@Override
public void run() {
synchronized (testDemo){
System.out.println("t1 lock ing");
System.out.println(ClassLayout.parseInstance(testDemo).toPrintable());
}
}
};
t1.start();
synchronized (testDemo){
System.out.println("main lock ing");
System.out.println(ClassLayout.parseInstance(testDemo).toPrintable());
}
}
}
自旋锁
前面我们讨论monitor实现锁的时候，知道monitor会阻塞和唤醒线程，线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，这些操作给系统的并发性能带来了很大的压力。同时，虚拟机的开发团队也注意到在许多应用上，共享数据的锁定状态只会持续很短的一段时间，为了这段时间阻塞和唤醒线程并不值得。如果物理机器有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程“稍等一下”，但不放弃处理器的执行时间，看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只需让线程执行一个忙循环(自旋) , 这项技术就是所谓的自旋锁。自旋锁在JDK 1.4.2中就已经引入，只不过默认是关闭的，可以使用-XX:+UseSpinning参数来开启，在JDK 6中就已经改为默认开启了。自旋等待不能代替阻塞，且先不说对处理器数量的要求，自旋等待本身虽然避免了线程切换的开销，但它是要占用处理器时间的，因此，如果锁被占用的时间很短，自旋等待的效果就会非常好，反之，如果锁被占用的时间很长。那么自旋的线程只会白白消耗处理器资源，而不会做任何有用的工作，反而会带来性能上的浪费。因此，自旋等待的时间必须要有一定的限度，如果在多线程交替执行同步块的情况下，可以避免重量级锁引起的性能消耗。
自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了。自旋次数的默认值是10次，用户可以使用参数-XX : PreBlockSpin来更改。
适应性自旋锁
在JDK 6中引入了自适应的自旋锁。自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100次循环。另外，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能省略掉自旋过程，以避免浪费处理器资源。有了自适应自旋，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测就会越来越准确，虛拟机就会变得越来越“聪明”了。
锁消除
锁消除是指虚拟机即时编译器（JIT）在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。
锁消除的主要判定依据来源于逃逸分析（参考附录）的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。
变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是程序员自己应该是很清楚的，怎么会在明知道不存在数据争用的情况下要求同步呢?实际上有许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过了大部分读者的想象。
下面这段非常简单的代码仅仅是输出3个字符串相加的结果，无论是源码字面上还是程序语义上都没有同步,虚拟机发现它的动态作用域被限制在concatString( )方法内部。也就是说, new StringBuilder()对象的引用永远不会“逃逸”到concatString ( )方法之外，其他线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。
public class LockCoarsening {
public static void main(String[] args) {
concatString("aa","bb","cc","dd");
}
public static String concatString(String str1, String str2, String str3, String str4) {
return new StringBuffer().append(str1).append(str2).append(str3).append(str4).toString();
}
}
锁粗化
原则上，我们在编写代码的时候，总是推荐将同步块的作用范围限制得尽量小，只在共享数据的实际作用域中才进行同步，这样是为了使得需要同步的操作数量尽可能变小，如果存在锁竞争，那等待锁的线程也能尽快拿到锁。大部分情况下，上面的原则都是正确的，但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，那即使没有线程竞争，频繁地进行互斥同步操作也会导致不必要的性能损耗。
附录
1、逃逸分析：
逃逸分析是“一种确定指针动态范围的静态分析，它可以分析在程序的哪些地方可以访问到指针”。
在 Java 虚拟机的即时编译语境下，逃逸分析将判断新建的对象是否逃逸。即时编译器判断对象是否逃逸的依据，一是对象是否被存入堆中（静态字段或者堆中对象的实例字段），二是对象是否被传入未知代码中。前者很好理解：一旦对象被存入堆中，其他线程便能获得该对象的引用。即时编译器也因此无法追踪所有使用该对象的代码位置。关于后者，由于 Java 虚拟机的即时编译器是以方法为单位的，对于方法中未被内联的方法调用，即时编译器会将其当成未知代码，毕竟它无法确认该方法调用会不会将调用者或所传入的参数存储至堆中。因此，我们可以认为方法调用的调用者以及参数是逃逸的。通常来说，即时编译器里的逃逸分析是放在方法内联之后的，以便消除这些“未知代码”入口。
1、基于逃逸分析的优化：
即时编译器可以根据逃逸分析的结果进行诸如锁消除、栈上分配以及标量替换的优化。
我们先来看一下锁消除。如果即时编译器能够证明锁对象不逃逸，那么对该锁对象的加锁、解锁操作没有意义。这是因为其他线程并不能获得该锁对象，因此也不可能对其进行加锁。在这种情况下，即时编译器可以消除对该不逃逸锁对象的加锁、解锁操作。
不过，基于逃逸分析的锁消除实际上并不多见。一般来说，开发人员不会直接对方法中新构造的对象进行加锁。事实上，逃逸分析的结果更多被用于将新建对象操作转换成栈上分配或者标量替换。我们知道，Java 虚拟机中对象都是在堆上分配的，而堆上的内容对任何线程都是可见的。与此同时，Java 虚拟机需要对所分配的堆内存进行管理，并且在对象不再被引用时回收其所占据的内存。如果逃逸分析能够证明某些新建的对象不逃逸，那么 Java 虚拟机完全可以将其分配至栈上，并且在 new 语句所在的方法退出时，通过弹出当前方法的栈桢来自动回收所分配的内存空间。这样一来，我们便无须借助垃圾回收器来处理不再被引用的对象。不过，由于实现起来需要更改大量假设了“对象只能堆分配”的代码，因此 HotSpot 虚拟机并没有采用栈上分配，而是使用了标量替换这么一项技术。所谓的标量，就是仅能存储一个值的变量，比如 Java 代码中的局部变量。与之相反，聚合量则可能同时存储多个值，其中一个典型的例子便是 Java 对象。标量替换这项优化技术，可以看成将原本对对象的字段的访问，替换为一个个局部变量的访问。
由于该对象没有被实际分配，因此和栈上分配一样，它同样可以减轻垃圾回收的压力。与栈上分配相比，它对字段的内存连续性不做要求，而且，这些字段甚至可以直接在寄存器中维护，无须浪费任何内存空间。
2、部分逃逸分析
C2 的逃逸分析与控制流无关，相对来说比较简单。Graal 则引入了一个与控制流有关的逃逸分析，名为部分逃逸分析（partial escape analysis）[2]。它解决了所新建的实例仅在部分程序路径中逃逸的情况。
部分逃逸分析将根据控制流信息，判断出新建对象仅在部分分支中逃逸，并且将对象的新建操作推延至对象逃逸的分支中。这将使得原本因对象逃逸而无法避免的新建对象操作，不再出现在只执行 if-else 分支的程序路径之中。综上，与 C2 所使用的逃逸分析相比，Graal 所使用的部分逃逸分析能够优化更多的情况，不过它编译时间也更长一些。
3、总结：
在 Java 虚拟机的即时编译语境下，逃逸分析将判断新建的对象是否会逃逸。即时编译器判断对象逃逸的依据有两个：一是看对象是否被存入堆中，二是看对象是否作为方法调用的调用者或者参数。即时编译器会根据逃逸分析的结果进行优化，如锁消除以及标量替换。后者指的是将原本连续分配的对象拆散为一个个单独的字段，分布在栈上或者寄存器中。部分逃逸分析是一种附带了控制流信息的逃逸分析。
逃逸分析的主要优化点是：栈上分配，标量替换，同步消除。其中同步消除比较少，栈上分配在HotSpot中暂未实现，主要是标量替换。
逃逸分析的缺点是：分析过程比较耗费性能或者分析完毕后发现非逃逸的对象很少。
逃逸程度：不逃逸，方法逃逸，线程逃逸；其中栈上分配不支持线程逃逸，标量替换不支持方法逃逸。
- 发表于:
- 本文为 InfoQ 中文站特供稿件
- 首发地址：https://www.infoq.cn/article/f66a1ea339e71c2012713a91f
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
