Monitor、synchronized原理

1、Monitor概念

java对象头

以32位虚拟机为例

Integer 8(头)+4(value)

int 4

image-20210909113844420

image-20210909114103760

Monitor(锁)

Monitor被翻译为监视器管程
每个Java对象都可以关联一个Monitor对象,如果使用synchronized 给对象上锁(重量级)之后,该对象头的Mark Word中就被设置指向Monitor对象的指针

image-20210909114255129

image-20210909114618806

EntryList等待队列

分析:

  • 刚开始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 是之前获得过锁,但条件不满足进入WAITING状态的线程,后面讲wait-notify时会分析

注意:

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

原理之synchronized

image-20210910101626519

image-20210910102214813

从上面可以看出,不管你的代码有没有出错,都会解锁

synchronized优化

image-20210910102346689

每个对象会关联一个monitor,检查monitor里面是否有owner。

没有竞争的时候是轻量级锁,有了竞争就会升级为Monitor

image-20210910102858498

image-20210910103029609

2、synchronized原理进阶

2.1、轻量级锁

轻量级锁的使用场景:如果一个对象虽然有多线程访问,但多线程访问的时间是错开的( 也就是没有竞争),那么可以使用轻量级锁来优化。

轻量级锁对使用者是透明的,即语法仍然是synchronized

image-20210910103250573

image-20210910103325191

image-20210910103435267

未加锁 01 ,轻量级锁 00 ,交换成功了就表示加锁成功

image-20210910103605603

交换成功后,markword里面存的是锁记录的地址和00

cas保证这个操作是原子性的。

image-20210910103811680

自己线程又给自己加锁,锁重入,Lock Record 表示加锁的次数

image-20210910104049264

image-20210910104143114

2.2锁膨胀

如果在尝试加轻量级锁的过程中,CAS操作无法成功,这时一-种情况就是有其它线程为此对象加上了轻量级锁(有竞争) , 这时需要进行锁膨胀,将轻量级锁变为重量级锁。

image-20210910104257643

image-20210910104329287

当1去加锁的时候,发现已经被加锁了,1就会进入锁膨胀,去阻塞状态

重量级锁10

image-20210910104533374

image-20210910104617140

先轻量级锁方式解锁,失败,升级为重量级锁解锁方式

2.3自旋优化

重量级锁竞争的时候,还可以使用自旋来进行优化,如果当前线程自旋成功(即这时候持锁线程已经退出了同步块,释放了锁),这时当前线程就可以避免阻塞。

让线程先不进入阻塞,先进行循环,如果循环中别人释放了锁,就不用进入阻塞(就会发生上下文切换)了,拥有owner

自旋重试成功的情况

image-20210910105009021

自旋需要cpu,所以在多核cpu下才有意义。

image-20210910105147758

  • 在Java 6之后自旋锁是自适应的,比如对象刚刚的- -次自旋操作成功过,那么认为这次自旋成功的可能性会高,就多自旋几次;反之,就少自旋甚至不自旋,总之,比较智能。
  • 自旋会占用CPU时间,单核CPU自旋就是浪费,多核CPU自旋才能发挥优势。
  • Java7之后不能控制是否开启自旋功能

2.4偏向锁

轻量级锁在没有竞争时(就自己这个线程)每次重入仍然需要执行CAS操作

Java 6中引入了偏向锁来做进一步优化: 只有第一次使用 CAS将线程ID设置到对象的Mark Word头,之后发现这个线程ID是自己的就表示没有竞争,不用重新CAS。以后只要不发生竞争,这个对象就归该线程所有

image-20210910105529042

image-20210910105647778

cas就是交换markword的过程

image-20210910105827850

偏向状态

image-20210910110025703

biased_lock:1表示偏向锁

一个对象创建时:

  • 如果开启了偏向锁(默认开启),那么对象创建后,markword 值为0x05即最后3位为101,这时它的thread. epoch、 age 都为0
  • 偏向锁是默认是延迟的,不会在程序启动时立即生效,如果想避免延迟,可以加VM参数-XX:BiasedLockingStartupDelay=0来禁用延迟
  • 如果没有开启偏向锁,那么对象创建后,markword值为0x01即最后3位为001,这时它的hashcode、 age都为0,第- -次用到hashcode时才会赋值

在上面测试代码运行时在添加VM参数-xx: -UseBiasedLocking禁用偏向锁

加锁顺序:偏向锁>轻量级锁>重量级锁

调用对象的hashCode() 会禁用掉偏向锁

image-20210910111231076

撤销 - 其他线程使用对象

当有其它线程使用偏向锁对象时,会将偏向锁升级为轻量级锁

撤销-调用wait/notify

只有重量级锁有wait/notify

批量重定向

如果对象虽然被多个线程访问,但没有竞争,这时偏向了线程TI的对象仍有机会重新偏向T2,重偏向会重置对象的Thread ID

当撤销偏向锁阈值超过20次后,jvm 会这样觉得,我是不是偏向错了呢,于是会在给这些对象加锁时重新偏向至加锁线程

批量撤销

当撤销偏向锁阈值超过40次后,jvm 会这样觉得,自己确实偏向错了,根本就不该偏向。于是整个类的所有对象都会变为不可偏向的,新建的对象也是不可偏向的

锁消除

重置对象的Thread ID

当撤销偏向锁阈值超过20次后,jvm 会这样觉得,我是不是偏向错了呢,于是会在给这些对象加锁时重新偏向至加锁线程

批量撤销

当撤销偏向锁阈值超过40次后,jvm 会这样觉得,自己确实偏向错了,根本就不该偏向。于是整个类的所有对象都会变为不可偏向的,新建的对象也是不可偏向的

锁消除

当发现没必要加锁的时候(局部方法),jvm会自动把你写的加锁操作优化,锁取消

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值