Monitor 被翻译为监视器或管程。
每个 Java 对象都可以关联一个 Monitor 对象,如果使用 synchronized 给对象上锁(重量级)之后,该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针。
(1)刚开始 Monitor 中 Owner 为 null。
(2)当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2,Monitor 中只能有一个 Owner。
(3)在 Thread-2 上锁的过程中,如果 Thread-3,Thread-4,Thread-5 也来执行 synchronized(obj),就会进入 EntryList BLOCKER。
(4)Thread-2 执行完同步代码块的内容,然后唤醒 EntryList 中等待的线程来竞争锁,竞争是非公平的。
(5)图中 WaitSet 中的 Thread-0, Thread-1 是之前获得过锁的,当条件不满足加入 WAITING 状态的线程,后面涉及到 wait-notify 时会分析
注意:(1)synchronized 必须是进入同一个对象的 monitor 才有上述的效果(2)不加 synchronized 的对象不会关联监视器,不遵从以上规则
故事角色老王 - JVM小南 - 线程小女 - 线程房间 - 对象房间门上 - 防盗锁 - Monitor房间门上 - 小南书包 - 轻量级锁房间门上 - 刻上小南大名 - 偏向锁批量重刻名 - 一个类的偏向锁撤销到达 20 阈值不能刻名字 - 批量撤销该类对象的偏向锁,设置该类不可偏向
轻量级锁的使用场景:如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以使用轻量级来优化。
轻量级锁对使用者是透明的,即语法仍然是 synchronized。
(1)创建锁记录(Lock Record)对象,每个线程都的栈帧都会包含一个锁记录的结构,内部可以存储锁定对象的 Mark Word
(2)让锁记录中 Object reference 指向锁对象,并尝试用 cas 替换 Object 的 Mark Word,将 Mark Word 的值存入锁记录
如果 cas 替换成功,对象头中存储了 锁记录地址和状态 00 ,表示由该线程给对象加锁,这时图示如下
如果 cas 失败,有两种情况
1️⃣如果是其它线程已经持有了该 Object 的轻量级锁,这时表明有竞争,进入锁膨胀过程
2️⃣如果是自己执行了 synchronized 锁重入,那么再添加一条 Lock Record 作为重入的计数
(3)当退出 synchronized 代码块(解锁时)如果有取值为 null 的锁记录,表示有重入,这时重置锁记录,表示重入计数减一
当退出 synchronized 代码块(解锁时)锁记录的值不为 null ,这时使用 cas 将 Mark Word 的值恢复给对象头1️⃣成功,则解锁成功
2️⃣失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程
如果在尝试加轻量级锁的过程中, CAS 操作无法成功,这时一种情况就是有其它线程为此对象加上了轻量级锁(有竞争),这时需要进行锁膨胀, 将轻量级锁变为重量级锁 。
(1)当 Thread-1 进行轻量级加锁时,Thread-0 已经对该对象加了轻量级锁
(2)这时 Thread-1 加轻量级锁失败,进入锁膨胀流程
1️⃣即为 Object 对象申请 Monitor 锁,让 Object 指向重量级锁地址2️⃣然后自己进入 Monitor 的 Entry
(3)当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败。这时会进入重量级解锁流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null ,唤醒 EntryList 中 BLOCKED 线程
重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞。
(1)自旋会占用 CPU 时间,单核 CPU 自旋就是浪费,多核 CPU 自旋才能发挥优势。
(2)在 Java6 之后自旋锁是自适应的,比如对象刚刚的一次自旋操作成功过,那么认为这次自旋成功的可能性会高,就多自旋几次;反之,就少自旋甚至不自旋,总之,比较智能。
(3)Java7 之后不能控制是否开启自旋功能。
轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作。
Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头,之后发现这个线程 ID 是自己的就表示没有竞争,不用重新 CAS 。以后只要不发生竞争,这个对象就归该线程所有
一个对象创建时:(1)如果开启了偏向锁(默认开启),那么对象创建后, markword 值为 0x05 即最后 3 位为 101 ,这时它的 thread 、 epoch 、 age 都为 0(2)偏向锁是默认是延迟的,不会在程序启动时立即生效,如果想避免延迟,可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟(3)如果没有开启偏向锁,那么对象创建后, markword 值为 0x01 即最后 3 位为 001 ,这时它的 hashcode、 age 都为 0 ,第一次用到 hashcode 时才会赋值
注意处于偏向锁的对象解锁后,线程 id 仍存储于对象头中
调用了对象的 hashCode,但偏向锁的对象 MarkWord 中存储的是线程 id,如果调用 hashCode 会导致偏向锁被撤销。
1️⃣轻量级锁会在锁记录中记录 hashCode
2️⃣重量级锁会在 Monitor 中记录 hashCode
在调用 hashCode 后使用偏向锁,记得去掉【-XX:-UseBiasedLocking】
当有其他线程使用偏向锁对象时,会将偏向锁升级为轻量级锁。
如果对象虽然被多个线程访问,但没有竞争,这时偏向了线程 T1 的对象仍有机会重新偏向 T2,重偏向会重置对象的 Thread ID。
当撤销偏向锁阈值超过 20 次后,jvm 会这样觉得,我是不是偏向错了呢,于是会在给这些对象加锁时重新偏向至加锁线程。
当撤销偏向锁阈值超过 40 次后,jvm 会这样觉得,自己确实偏向错了,根本就不该偏向。于是这个类的所有对象都会变为不可偏向的,新建的对象也是不可偏向的。
锁消除是发生在编译器级别的一种锁优化方式。有时候我们写的代码完全不需要加锁,却执行了加锁操作。通过编译器将其优化,将锁消除。