锁升级

Java对象头

以32位虚拟机为例
普通对象：

数组对象：

Mark Word结构：

---

无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁（锁升级）

在JDK1.6之前synchronized属于重量级的锁，每次加锁都是通过操作系统来申请锁，所以会造成synchronized的效率比较低，尤其是随着时代的发展，多线程高并发越来越多，synchronized效率低的缺点就越来越明显，所以JDK1.6后对它进行了优化，不再是一开始就向操作系统申请锁，锁对象分成 无锁 - 偏向锁 - 轻量级锁 - 重量级锁四个状态。

在对象头的mark word中最低的三位代表锁状态，其中1位是偏向锁位两位是普通锁位，具体如下图：

这次主要关注mark word的后三位的变化，根据变化我们可以得出实际上对象的锁状态可以分成无锁、偏向锁、轻量级锁、重量级锁4个状态，GC过程中有对对象的锁降级，这个不是重点，先不管了。

锁升级流程开始：
1. 无锁 - > 偏向锁：
首先最开始对象是无锁状态，当一个线程准备对这个对象加锁前验证这三个字节发现了无锁状态，把对象是否偏向设置为1，锁标志位还是01，并把markword的线程ID改为当前线程ID，此时对象处于偏向锁状态。
2. 偏向锁 -> 轻量级锁：
一个线程继续对该该对象加锁，发现是偏向锁状态，判断偏向锁线程是否是当前线程，如果是则是直接进入，如果偏向线程不是当前线程，也就是存在锁竞争，那么就撤销偏向锁，升级为轻量级锁。
3. 轻量级锁实现：
轻量级锁实现方式是各个线程在自己的线程栈生成LockRecord ，用CAS操作将锁对象的markword设置为指向自己这个线程的LockRecord的指针，设置成功者得到锁，没有成功的将继续使用CAS一直循环直到成功，所以轻量级锁也叫自旋锁
4. 轻量级锁 -> 重量级锁：
当轻量级锁自旋次数达到最大次数，就会升级为重量级锁

这里CAS操作也比较重要，具体CAS原理大家可以转载到这片文章【什么是CAS机制？】 这位博主讲的还是挺详细的

---

Monitor（针对于重量级锁）

Monitor被翻译为监视器或管程

每个Java对象都可以关联一个Monitor对象，如果使用synchronized给对象上锁（重量级）之后，该对象头的Mark Word中就被设置指向Monitor对象的指针。

多个线程争抢锁流程如下图：

Monitor结构图：

• 刚开始Monitor中Owner为nul
• 当Thread-2执行synchronize(obj)就会将Monitor的Owner（所有者）置为Thread-2，Monitor只能有一个Owner
• 在Thread-2上锁的过程中，如果Thread-3，Thread-4，Thread-5也来执行synchronize(obj)，就会进入EntryList ，状态是BLOCKED
• Thread-2执行完同步代码块的内容，然后唤醒EntryList中等待的线程来竞争锁，竞争时是非公平的（并非是谁先来是获得锁，这里获得锁是随机的）
• 图中WaitSet中的Thread-0，Thread-1是之前获得过锁，但条件不满足（被调用了wait方法），然后进入WAITING状态的线程

注意：

• synchronize必须是进入同一个对象的monitor才有上述的效果
• 不加synchronize的对象不会关联监视器，不遵从以上规则