文章目录
- 使用
- Monitor
- Java对象头
- 轻量级锁
- 锁膨胀
- 自旋CAS
- 偏向锁
- 偏向锁撤销的情况
- hashCode()导致偏向锁被动撤销
- 线程争抢导致偏向锁被动撤销
- 调用 wait/notify导致偏向锁撤销
- wait/notify
- Park/UnPark
- Park/UnPark原理
-
修饰实例方法: 锁实例对象,
-
修饰静态方法: 锁类对象
-
修饰代码块: 锁参数中传入的自定义加锁对象
什么样的代码放入synchronized中?
1.代码被多个线程访问
2.代码中有共享的数据
3.共享数据被多条语句操作
Monitor
Monitor 被翻译为监视器或管程,是操作系统层次的数据结构
每个 Java 对象都可以关联一个 Monitor 对象
如果使用 synchronized 给对象上锁(重量级)之后,该对象头的Mark Word 中就被设置指向 Monitor 对象的指针
模拟多线程竞争Synchronized锁对象的流程
-
刚开始 Monitor 中 Owner 为 null
-
当 Thread-2 执行 synchronized(obj) 就会将 Monitor 的所有者 Owner 置为 Thread-2,Monitor中只能有一个 Owner
-
在 Thread-2 上锁的过程中,如果 Thread-3,Thread-4,Thread-5 也来执行 synchronized(obj),就会进入EntryList BLOCKED(阻塞队列)
-
Thread-2 执行完同步代码块的内容,然后唤醒 EntryList 中等待的线程来竞争锁,竞争的时是非公平的
-
WaitSet 中的 Thread-0,Thread-1 是之前获得过锁,但条件不满足Runable进入 WAITING 状态的线程,需要被其他线程唤醒
Java对象头
被synchronized的对象,对象头的MarkWord中的某个字段会指向Monitor地址,具体来看下对象头是什么结构
以 32 位虚拟机为例
普通对象:
数组对象:
其中 Mark Word 结构为:
- hashcode:对象哈希值、用于HashMap等结构中定位
- age:jvm分代年龄,大于某个值后进入老年代
- thread:线程id
- ptr_to_lockrecode:轻量级锁模式下 指向线程栈中锁记录
- ptr_to_heavyweight_monitor:重量级级锁模式下 指向monitor
Mark Word记录了对象和锁有关的信息,当这个对象被synchronized关键字当成同步锁时,围绕这个锁的一系列操作都和Mark Word有关
Mark Word在32位JVM中的长度是32bit,在64位JVM中长度是64bit
64 位虚拟机 Mark Word:
轻量级锁
轻量级锁的使用场景:如果一个对象虽然有多线程要加锁,但加锁的时间是错开的(也就是没有竞争),那么可以使用轻量级锁来优化
轻量级锁对使用者是透明的,即语法仍然是 synchronized
假设有两个方法同步块,利用同一个对象加锁
class TestSyn{static final Object obj = new Object() ; public static void method1(){synchronized (obj){method2();}}public static void method2(){synchronized (obj){}}
}
-
创建锁记录(Lock Record)对象,每个线程的栈帧都会包含一个锁记录的结构,内部可以存储锁定对象的Mark Word
-
让锁记录中 Object reference 指向锁对象,并尝试用 cas (交换并设置)替换 Object 的 Mark Word,将 Mark Word 的值存入锁记录
-
如果 cas 替换成功,对象头中存储了锁记录地址和状态 00 (代表轻量级锁),表示由该线程给对象加锁,这时图示如下
-
如果 cas 失败,有两种情况
-
当退出 synchronized 代码块(解锁时)如果有取值为 null 的锁记录,表示有重入,这时重置锁记录,表示重入计数减一
-
当退出 synchronized 代码块(解锁时)锁记录的值不为 null,这时使用 cas 将 Mark Word 的值恢复给对象头
成功,则解锁成功
失败,说明轻量级锁进行了锁膨胀或已经升级为重量级锁,进入重量级锁解锁流程
锁膨胀
如果在尝试加轻量级锁的过程中,CAS 操作无法成功,这时一种情况就是有其它线程为此对象加上了轻量级锁(有竞争),这时需要进行锁膨胀,将轻量级锁变为重量级锁
如有以下流程:
-
当 Thread-1 进行轻量级加锁时,Thread-0 已经对该对象加了轻量级锁
-
这时 Thread-1 加轻量级锁失败,进入锁膨胀流程,为 Object 对象申请 Monitor 锁(重量级锁),让 Object 指向重量级锁地址,然后自己进入 Monitor 的 EntryList BLOCKED阻塞队列
当 Thread-0 退出同步块解锁时,使用 cas 将 Mark Word 的值恢复给对象头,失败。这时会进入重量级解锁流程,即按照 Monitor 地址找到 Monitor 对象,设置 Owner 为 null,唤醒 EntryList 中 BLOCKED 线程
自旋CAS
重量级锁竞争的时候,还可以使用自旋来进行优化,避免阻塞带来的上下文切换,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞
自旋重试成功的情况:
自旋重试失败的情况:
注意:
- 自旋会占用 CPU 时间,单核 CPU 自旋就是浪费,多核 CPU 自旋才能发挥优势
- 在 Java 6 之后自旋锁是自适应的,比如对象刚刚的一次自旋操作成功过,那么认为这次自旋成功的可能性会高,就多自旋几次;反之,就少自旋甚至不自旋,总之,比较智能
- Java 7 之后不能控制是否开启自旋功能
偏向锁
轻量级锁在没有竞争时(就自己这个线程),每次重入仍然需要执行 CAS 操作
Java 6 中引入了偏向锁来做进一步优化:只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头hashcode字段中,之后发现这个线程 ID 是自己的(锁对象ptr_to_lockrecode同时指向线程栈帧中的锁记录)就表示没有竞争,不用重新 CAS。以后只要不发生竞争,这个对象就归该线程所有
class TestSyn{static final Object obj = new Object() ;public static void method1(){synchronized (obj){method2();}}public static void method2(){synchronized (obj){method3();}}public static void method3(){synchronized (obj){}}
}
轻量级锁下,主线程每次申请锁都需要CAS
偏向锁下。无需CAS
偏向锁撤销的情况
hashCode()导致偏向锁被动撤销
调用了对象的 hashCode,但偏向锁的对象 MarkWord 中存储的是线程 id,如果调用 hashCode 会导致偏向锁被撤销并重新生成锁对象hashcode
故轻量级重量级锁调用hashCode是没有问题的
在调用 hashCode 后使用偏向锁,记得去掉 -XX:-UseBiasedLocking
线程争抢导致偏向锁被动撤销
当有其它线程使用偏向锁对象时,会将偏向锁升级为轻量级锁
调用 wait/notify导致偏向锁撤销
锁对象一旦调用wait/notify会导致该锁上的线程状态改变
wait/notify
接synchronized,当一个线程暂时不满足条件,应该进去等待队列,等着另一个线程执行完毕,线程满足条件,由另一个线程唤醒之
注意,wait/notify需要在synchroniezd代码块中才能使用
API 介绍
- obj.wait() 让进入 object 监视器的线程到 waitSet 等待
- obj.notify() 在 object 上正在 waitSet 等待的线程中挑一个唤醒
- obj.notifyAll() 让 object 上正在 waitSet 等待的线程全部唤醒
- 唤醒后的线程进入Runable状态,等待CPU时间片
Park/UnPark
这套组合与wait/notify是一样的效果,但这套组合要优于wait/notify,它们是 LockSupport 类中的方法
LockSupport.park();
LockSupport.unpark(暂停线程对象)
先 park 再 unpark
与 Object 的 wait & notify 相比
- wait,notify 和 notifyAll 必须配合 Object Monitor(重量级锁) 一起使用,而 park,unpark 不必
- park & unpark 是以线程为单位来【阻塞】和【唤醒】线程,而 notify 只能随机唤醒一个等待线程,notifyAll 是唤醒所有等待线程,就不那么【精确】
- park & unpark 可以先 unpark,而 wait & notify 不能先 notify
Park/UnPark原理
每个线程都有自己的一个 Parker 对象,由三部分组成 _counter , _cond 和 _mutex
打个比喻
- 当前线程调用 Unsafe.park() 方法
- 检查 _counter(counter) ,本情况为 0,这时,获得 _mutex 互斥锁,类比monitor的owner
- 线程进入 _cond 条件变量阻塞,类比monitor的waitset
- 设置 _counter = 0
- 调用 Unsafe.unpark(Thread_0) 方法,设置 _counter 为 1
- 唤醒 _cond 条件变量中的 Thread_0
- Thread_0 恢复运行
- 设置 _counter 为 0
- 调用 Unsafe.unpark(Thread_0) 方法,设置 _counter 为 1
- 当前线程调用 Unsafe.park() 方法
- 检查 _counter ,本情况为 1,这时线程无需阻塞,继续运行
- 设置 _counter 为 0