synchronized 重量锁 以及锁升级原理 （全套）
-
Monitor实现的锁属于重量级锁，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。
-
在JDK 1.6引入了两种新型锁机制：偏向锁和轻量级锁，它们的引入是为了解决在没有多线程竞争或基本没有竞争的场景下因使用传统锁机制带来的性能开销问题。
Monitor 被翻译为监视器，是由jvm提供，c++语言实现
在代码中想要体现monitor需要借助javap命令查看clsss的字节码，比如以下代码：
public class SyncTest {
static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
synchronized (lock) {
counter++;
}
}
}
找到这个类的class文件，在class文件目录下执行javap -v SyncTest.class，反编译效果如下：
- monitorenter 上锁开始的地方
- monitorexit 解锁的地方
- 其中被monitorenter和monitorexit包围住的指令就是上锁的代码
- 有两个monitorexit的原因，第二个monitorexit是为了防止锁住的代码抛异常后不能及时释放锁
在使用了synchornized代码块时需要指定一个对象，所以synchornized也被称为对象锁
monitor主要就是跟这个对象产生关联，如下图
Monitor内部具体的存储结构：
-
Owner：存储当前获取锁的线程的，只能有一个线程可以获取
-
EntryList：关联没有抢到锁的线程，处于Blocked状态的线程
-
WaitSet：关联调用了wait方法的线程，处于Waiting状态的线程
具体的流程：
- 代码进入synchorized代码块，先让lock（对象锁）关联的monitor，然后判断Owner是否有线程持有
- 如果没有线程持有，则让当前线程持有，表示该线程获取锁成功
- 如果有线程持有，则让当前线程进入entryList进行阻塞，如果Owner持有的线程已经释放了锁，在EntryList中的线程去竞争锁的持有权（非公平）
- 如果代码块中调用了wait()方法，则会进去WaitSet中进行等待
对象的内存结构
在HotSpot虚拟机中，对象在内存中存储的布局可分为3块区域：对象头（Header）、实例数据（Instance Data）和对齐填充
markword 占8字节，指向monitor的指针
类型指针表明他是怎么类
如果数据能被8整除无需对其填充
MarkWord
-
hashcode：25位的对象标识Hash码
-
age：对象分代年龄占4位
-
biased_lock：偏向锁标识，占1位 ，0表示没有开始偏向锁，1表示开启了偏向锁
-
thread：持有偏向锁的线程ID，占23位
-
epoch：偏向时间戳，占2位
-
ptr_to_lock_record：轻量级锁状态下，指向栈中锁记录的指针，占30位
-
ptr_to_heavyweight_monitor：重量级锁状态下，指向对象监视器Monitor的指针，占30位
我们可以通过lock的标识，来判断是哪一种锁的等级
- 后三位是001表示无锁
- 后三位是101表示偏向锁
- 后两位是00表示轻量级锁
- 后两位是10表示重量级锁
再说Monitor重量级锁
每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的Mark Word 中就被设置指向 Monitor 对象的指针
简单说就是：每个对象的对象头都可以设置monoitor的指针，让对象与monitor产生关联
轻量级锁
在很多的情况下，在Java程序运行时，同步块中的代码都是不存在竞争的，不同的线程交替的执行同步块中的代码。这种情况下，用重量级锁是没必要的。因此JVM引入了轻量级锁的概念。
static final Object obj = new Object();
public static void method1() {
synchronized (obj) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized (obj) {
// 同步块 B
}
}
加锁的流程
1.在线程栈中创建一个Lock Record，将其obj字段指向锁对象。
2.通过CAS指令将Lock Record的地址存储在对象头的mark word中（数据进行交换），如果对象处于无锁状态则修改成功，代表该线程获得了轻量级锁。
3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置Lock Record第一部分为null，起到了一个重入计数器的作用。
4.如果CAS修改失败，说明发生了竞争，需要膨胀为重量级锁。
解锁过程
1.遍历线程栈,找到所有obj字段等于当前锁对象的Lock Record。
2.如果Lock Record的Mark Word为null，代表这是一次重入，将obj设置为null后continue。
3.如果Lock Record的 Mark Word不为null，则利用CAS指令将对象头的mark word恢复成为无锁状态。如果失败则膨胀为重量级锁。
2.2.5 偏向锁
轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现
这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有
static final Object obj = new Object();
public static void m1() {
synchronized (obj) {
// 同步块 A
m2();
}
}
public static void m2() {
synchronized (obj) {
// 同步块 B
m3();
}
}
public static void m3() {
synchronized (obj) {
}
}
加锁的流程
1.在线程栈中创建一个Lock Record，将其obj字段指向锁对象。
2.通过CAS指令将Lock Record的线程id存储在对象头的mark word中，同时也设置偏向锁的标识为101，如果对象处于无锁状态则修改成功，代表该线程获得了偏向锁。
3.如果是当前线程已经持有该锁了，代表这是一次锁重入。设置Lock Record第一部分为null，起到了一个重入计数器的作用。与轻量级锁不同的时，这里不会再次进行cas操作，只是判断对象头中的线程id是否是自己，因为缺少了cas操作，性能相对轻量级锁更好一些
Java中的synchronized有偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。
| 描述 | |
|---|---|
| 重量级锁 | 底层使用的Monitor实现，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。 |
| 轻量级锁 | 线程加锁的时间是错开的（也就是没有竞争），可以使用轻量级锁来优化。轻量级修改了对象头的锁标志，相对重量级锁性能提升很多。每次修改都是CAS操作，保证原子性 |
| 偏向锁 | 一段很长的时间内都只被一个线程使用锁，可以使用了偏向锁，在第一次获得锁时，会有一个CAS操作，之后该线程再获取锁，只需要判断mark word中是否是自己的线程id即可，而不是开销相对较大的CAS命令 |
一旦锁发生了竞争，都会升级为重量级锁
锁一旦升级，就不会降回去
无锁状态
偏向锁状态
一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
轻量级锁状态
当锁是偏向锁时，被另一线程所访问，偏向锁就好升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提供性能。
重量级锁状态
当锁为轻量级锁时，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数后还没获取到锁，就进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
重量级锁需要通过操作系统在用户态与核心态之间切换，就像它的名字是一个重量级操作，这也是synchronized效率不高的原因
对象刚创建出来是无锁状态，如果某个线程获得到了偏向锁，那么锁对象的markword中54bit存ThreadID，锁标志位由0变为1，如果有多个线程竞争，偏向锁升级为轻量级锁，CAS一定数量后还是没有获取锁，就会升级为重量级锁，就是monitor
下去，当自旋一定次数后还没获取到锁，就进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
重量级锁需要通过操作系统在用户态与核心态之间切换，就像它的名字是一个重量级操作，这也是synchronized效率不高的原因
1587
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
