自旋锁

我是廖志伟一名Java开发工程师、Java领域优质创作者、CSDN博客专家、51CTO专家博主、阿里云专家博主、清华大学出版社签约作者、产品软文创造者、技术文章评审老师、问卷调查设计师、个人社区创始人、开源项目贡献者。

跑过十五公里、徒步爬过衡山、有过三个月减肥20斤的经历、是个喜欢躺平的狠人。

拥有多年一线研发和团队管理经验研究过主流框架的底层源码(Spring、SpringBoot、Spring

MVC、SpringCould、Mybatis、Dubbo、Zookeeper)消息中间件底层架构原理(RabbitMQ、RockerMQ、Kafka)、Redis缓存、MySQL关系型数据库、

ElasticSearch全文搜索、MongoDB非关系型数据库、Apache

ShardingSphere分库分表读写分离、设计模式、领域驱动DDD、Kubernetes容器编排等。

有从0到1的高并发项目经验利用弹性伸缩、负载均衡、报警任务、自启动脚本最高压测过200台机器有着丰富的项目调优经验。

希望各位读者大大多多支持用心写文章的博主现在时代变了信息爆炸酒香也怕巷子深博主真的需要大家的帮助才能在这片海洋中继续发光发热所以赶紧动动你的小手点波关注❤️点波赞点波收藏⭐甚至点波评论✍️都是对博主最好的支持和鼓励

博客主页

程序开发这条路不能停停下来容易被淘汰掉吃不了自律的苦就要受平庸的罪持续的能力才能带来持续的自信。

我本是是一个很普通程序员放在人堆里除了与生俱来的盛世美颜就剩180的大高个了就是我这样的一个人默默写博文也有好多年了。

有句老话说的好牛逼之前都是傻逼式的坚持希望自己可以通过大量的作品、时间的积累、个人魅力、运气、时机可以打造属于自己的技术影响力。

内心起伏不定我时而激动时而沉思。

我希望自己能成为一个综合性人才具备技术、业务和管理方面的精湛技能。

我想成为产品架构路线的总设计师团队的指挥者技术团队的中流砥柱企业战略和资本规划的实战专家。

这个目标的实现需要不懈的努力和持续的成长但我必须努力追求。

因为我知道只有成为这样的人才我才能在职业生涯中不断前进并为企业的发展带来真正的价值。

在这个不断变化的时代我必须随时准备好迎接挑战不断学习和探索新的领域才能不断地向前推进。

我坚信只要我不断努力我一定会达到自己的目标。

经过多年在CSDN创作上千篇文章的经验积累我已经拥有了不错的写作技巧。

同时我还与清华大学出版社签下了四本书籍的合约并将陆续在明年出版。

这些书籍包括了基础篇、进阶篇、架构篇的《Java项目实战—深入理解大型互联网企业通用技术》以及《解密程序员的思维密码–沟通、演讲、思考的实践》。

具体出版计划会根据实际情况进行调整希望各位读者朋友能够多多支持

阅读前快速浏览目录和章节概览可帮助了解文章结构、内容和作者的重点。

了解自己希望从中获得什么样的知识或经验是非常重要的。

建议在阅读时做笔记、思考问题、自我提问以加深理解和吸收知识。

阅读结束后反思和总结所学内容并尝试应用到现实中有助于深化理解和应用知识。

与朋友或同事分享所读内容讨论细节并获得反馈也有助于加深对知识的理解和吸收。

在这个美好的时刻本人不再啰嗦废话现在毫不拖延地进入文章所要讨论的主题。

接下来我将为大家呈现正文内容。

Synchronized能保证同一时刻被Synchronized修饰的代码最多只有1个线程执行。

synchronized如果加在方法上/对象上那么它作用的对象是非静态的它取得的锁是对象锁

synchronized如果作用的对象是一个静态方法或一个类它取到的锁是类锁这个类所有的对象用的是同一把锁。

Synchronized加锁是通过对象内部的监视器锁来实现的监视器锁本质又是依赖于底层的操作系统的Mutex

Lock来实现的操作系统实现线程之间的切换这就需要从用户态转换到核心态这个成本非常高状态之间的转换需要比较长的时间。

Sun程序员发现大部分程序大多数时间都不会发生多个线程同时访问竞态资源的情况大多数对象的加锁和解锁都是在特定的线程中完成出现线程竞争锁的情况概率比较低比例非常高所以引入了偏向锁和轻量级锁。

第一步检测MarkWord是否为可偏向状态是偏向锁是1锁标识位是01。

第二步如果是可偏向状态测试线程ID是不是当前线程ID。

如果是就直接执行同步代码块。

第三步如果测试线程ID不是当前线程ID且当前对象的MarkWord标识为可偏向状态这说明该对象已经被其他线程获取过锁不能偏向于当前线程就需要通过CAS操作竞争锁竞争成功就把MarkWord的线程ID替换为当前线程ID同时执行同步代码块。

第四步假设线程B来CAS失败了需要将当前对象的偏向锁撤销然后再进行锁竞争这个时候JVM后台线程会启动偏向锁撤销过程。

偏向锁撤销触发通常有二种情况当在对象头的Epoch字段计数到一定次数时会触发偏向锁撤销或者有多个线程尝试竞争该对象的锁都失败了也会触发偏向锁的撤销。

当有多个线程尝试获取同一个对象的锁时通常只有一个线程能够获取成功而其他线程则需要进入等待状态。

当这个对象曾经被偏向锁优化过且当前正在尝试获取锁的线程不是偏向线程时如果该线程获取锁成功JVM会撤销该对象的偏向锁状态并重新获取锁。

这个过程不需要等待其他线程都失败只要有一个线程成功获取锁即可触发偏向锁的撤销。

在Java对象的内存布局中有一个叫做对象头的部分其中的Epoch字段是为了解决ABA问题而设置的。

与此同时当一个对象从偏向锁升级为轻量级锁或重量级锁时对象的标记字MarkWord中保存的线程ID可能会发生变化。

为了能够判断一个线程是否是因为ABA问题导致的线程变化会将Epoch字段的值加一来表示变化次数。

因此在线程之间竞争锁时可以通过比较Epoch字段的值是否相同来判断锁是否发生了变化。

如果发生了变化说明对象的状态已经被其他线程修改需要重新竞争锁。

与此同时这个Epoch字段并没有直接关系到偏向锁撤销的过程。

ABA问题指的是在多线程编程中当多个线程对一个内存位置进行读取和修改时可能会出现一种情况最初的值被读取然后被修改为新的值A再次被修改为原来的值也就是回到了最初的值B但此时中间可能有其他线程对这个内存位置进行了修改所以此时相对于最初的值B这个内存位置已经发生了变化无论是A还是其他值都与最初的B不同。

在这种情况下如果仅仅判断最终的值是否等于B可能出现问题需要使用其他机制来判断这个内存位置是否发生过变化。

偏向锁撤销不一定会挂起所有持有偏向锁的线程只有在线程竞争锁时才会挂起线程。

如果没有其他线程竞争锁偏向锁撤销的过程只会涉及到当前对象的MarkWord不会影响到其他线程。

撤销偏向锁的过程会挂起所有持有偏向锁的线程例如线程A并清除它们的MarkWord中的偏向锁信息标记位、偏向线程ID、Epoch次数。

然后遍历偏向锁的对象所在的线程的栈查找锁对象的锁记录将那些已经被访问过的记录清除以表明这些线程都不再持有该锁。

在撤销偏向锁的过程中需要清除那些曾经持有该偏向锁对象的线程的锁记录。

这是因为在偏向锁状态下持有锁的线程会在对象头中记录一个标记位和持有该锁的线程ID。

而在撤销偏向锁的过程中需要清除这些锁记录因为它们已经不再持有该锁以便其他线程可以重新争夺锁的所有权。

第五步完成偏向锁撤销后持有偏向锁的线程不会被挂起而是会继续执行同步代码块。

线程A尝试获取该锁如果获取成功就可以继续执行同步代码块了当线程A尝试获取该锁失败时视情况继续进行自旋或者进行阻塞等待导致进一步升级为轻量级锁或重量级锁。

安全点是jvm为了保证在垃圾回收的过程中引用关系不会发生变化设置的安全状态在这个状态上会暂停所有线程工作。

一般有循环的末尾方法临返回前调用方法的call指令后可能抛异常的位置这些位置都可以算是安全点。

轻量级锁升级

轻量级锁升级过程是在当前线程的栈帧中建立一个名为锁记录的空间用于存储锁对象目前的MarkWord的拷贝拷贝无锁状态对象头中的MarkWord复制到锁记录中。

这么做是因为在申请对象锁时需要以该值作为CAS的比较条件。

同时在升级到重量级锁的时候能通过这个比较判定是否在持有锁的过程中这个锁被其他线程申请过如果被其他线程申请了在释放锁的时候要唤醒被挂起的线程。

无锁的markword中可能存有hashCode锁撤销之后必须恢复这个markword要用于锁撤销后的还原。

如果轻量级锁解锁为无锁状态直接将拷贝的markword

拷贝成功后虚拟机将使用CAS操作把对象中对象头MarkWord替换为指向锁记录的指针然后把锁记录空间里的owner指针指向加锁的对象。

这个过程的目的是为了实现轻量级锁的互斥访问。

CAS操作的作用是将对象头MarkWord指针指向锁记录空间从而表示当前线程持有这个对象的锁。

锁记录空间里的owner指针指向加锁的对象是为了在释放锁的时候能够知道哪个对象需要进行通知从而唤醒被挂起等待锁的线程。

同时轻量级锁的升级过程也可以通过锁记录空间来判断是否在持有锁的过程中这个锁被其他线程申请过如果被其他线程申请了在释放锁的时候要唤醒被挂起的线程从而保证多个线程对同一个对象的访问是互斥的。

如果这个更新动作成功了那么当前线程就拥有了该对象的锁并且对象MarkWord的锁标志位设置为“00”即表示此对象处于轻量级锁定状态。

如果这个更新操作失败了虚拟机首先会检查对象MarkWord中的Lock

Lock

Word是一个对象头的一部分用于实现Java对象的锁定。

当一个线程获取了对象的锁时Lock

Word就会被设置为指向该线程的栈帧表示这个对象被该线程持有了锁。

其他线程如果要获取该对象的锁会检查Lock

Word中的锁标志是否为0如果为0则表示该对象没有被锁定可以获取锁。

如果锁标志为1则表示对象已经被锁定其他线程必须等待锁的释放。

如果是就说明当前线程已经拥有了这个对象的锁那就可以直接进入同步块继续执行。

如果不是说明多个线程竞争锁进入自旋若自旋结束时仍未获得锁轻量级锁就要膨胀为重量级锁锁标志的状态值变为“10”MarkWord中存储的就是指向重量级锁互斥量的指针当前线程以及后面等待锁的线程也要进入阻塞状态。

当锁升级为轻量级锁之后如果依然有新线程过来竞争锁首先新线程会自旋尝试获取锁尝试到一定次数默认10次依然没有拿到锁就会升级成重量级锁。

一般来说同步代码块内的代码应该很快就执行结束这时候线程B自旋一段时间是很容易拿到锁的但是如果不巧没拿到自旋其实就是死循环很耗CPU的因此就直接转成重量级锁咯这样就不用了线程一直自旋了。

自旋锁

自旋锁不是一种锁状态而是一种策略。

线程的阻塞和唤醒需要CPU从用户态转为核心态频繁的阻塞和唤醒对CPU来说是一件负担很重的工作。

引入自旋锁当一个线程尝试获取某个锁时如果该锁已被其他线程占用就一直循环检测锁是否被释放而不是进入线程挂起或睡眠状态。

自旋等待不能替代阻塞虽然它可以避免线程切换带来的开销但是它占用了CPU处理器的时间。

自旋锁适用于锁保护的临界区很小的情况临界区很小的话锁占用的时间就很短。

如果持有锁的线程很快就释放了锁那么自旋的效率就非常好。

自旋的次数必须要有一个限度如果自旋超过了定义的限度仍然没有获取到锁就应该被挂起。

但是这个限度不能固定程序锁的状况是不可预估的所以JDK1.6引入自适应的自旋锁线程如果自旋成功了那么下次自旋的次数会更加多因为虚拟机认为既然上次成功了那么此次自旋也很有可能会再次成功那么它就会允许自旋等待持续的次数更多。

如果对于某个锁很少有自旋能够成功那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程以免浪费处理器资源。

通过–XX:UseSpinning参数来开启自旋JDK1.6之前默认关闭自旋。

通过–XX:PreBlockSpin修改自旋次数默认值是10次。

重量级锁

当一个线程在等锁时会不停的自旋底层就是一个while循环当自旋的线程达到CPU核数的1/2时就会升级为重量级锁。

将锁标志为置为10将MarkWord中指针指向重量级的monitor阻塞所有没有获取到锁的线程。

Synchronized是通过对象内部的监视器锁Monitor来实现的监视器锁本质又是依赖于底层的操作系统的MutexLock来实现的操作系统实现线程之间的切换这就需要从用户态转换到核心态状态之间的转换需要比较长的时间这就是为什么Synchronized效率低的原因这种依赖于操作系统MutexLock所实现的锁我们称之为“重量级锁”。

举个例子假设有ABC三个线程依次进入synchronized区并且A已经膨胀成重量级锁。

如果有一个线程

先进入

synchronizedb还在synchronized中执行c线程又进来了。

此时

wait_set

重量级锁撤销之后是无锁状态撤销锁之后会清除创建的monitor对象并修改markword这个过程需要一段时间。

Monitor对象是通过GC来清除的。

GC清除掉monitor对象之后就会撤销为无锁状态。