synchronized锁是如何升级的呢?
下文笔者讲述锁升级的原理及流程简介说明,如下所示
synchronized 锁升级原理
下文笔者将采用锁对象(当然也有锁class类的信息)
JVM在对象的对象头(Mark Word)中的threadid字段设置为线程Id(对象缺省的情况下threadId字段值为空)
-----------------------------------------------------------------------
JVM第一次访问MarkWord的threadid字段值时,此时为空,JVM将持有偏向锁,并设置threadid的值为其线程 id
如果多线程另一个线程进入获取锁时，首先检测Threadid和线程Id是否相同
如果相同,则直接使用此对象(线程可重入)
如果不相同,则升级偏向锁为轻量级锁---此时将通过自旋的方式来获取锁(自旋指定次数)
如果运行指定次数后,还未获取到锁对象时,则轻量级升级为重量级锁(JDK1.6之前的锁模式)
以上的过程就是synchronized锁升级的原理及过程
为什么有锁升级这种操作呢?
JVM采用这种锁升级的模式,可用于降低锁带来的性能损耗
锁级别从低到高
无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
锁状态对比
| 无锁 | 偏向锁 | 轻量级锁 | 重量级锁 | |
| 定义 | 没有对资源进行锁定， 所有的线程都能访问并修改同一个资源， 但同时只有一个线程能修改成功， 其他修改失败的线程会不断重试直到修改成功。 |
对象的代码一直被同一线程执行，不存在多个线程竞争， 该线程在后续的执行中自动获取锁， 降低获取锁带来的性能开销。 偏向锁，指的就是偏向第一个加锁线程， 该线程是不会主动释放偏向锁的， 只有当其他线程尝试竞争偏向锁才会被释放。 偏向锁的撤销，需要在某个时间点上没有字节码正在执行时， 先暂停拥有偏向锁的线程， 然后判断锁对象是否处于被锁定状态。 如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁； 如果线程处于活动状态，升级为轻量级锁的状态。 |
轻量级锁是指当锁是偏向锁的时候，被第二个线程 B 所访问， 此时偏向锁就会升级为轻量级锁， 线程 B 会通过自旋的形式尝试获取锁， 线程不会阻塞，从而提高性能。 当前只有一个等待线程， 则该线程将通过自旋进行等待。但是当自旋超过一定的次数时，轻量级锁便会升级为重量级锁； 当一个线程已持有锁，另一个线程在自旋，而此时又有第三个线程来访时，轻量级锁也会升级为重量级锁。 指当有一个线程获取锁之后， 其余所有等待获取该锁的线程都会处于阻塞状态。 |
重量级锁通过对象内部的监视器(monitor)实现， 而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现， 操作系统实现线程之间的切换需要从用户态切换到内核态， 切换成本非常高。 |
| 适用场景 | 无需保证线程安全的场景 | 偏向锁的撤销，需要在某个时间点上没有字节码正在执行时， 先暂停拥有偏向锁的线程， 然后判断锁对象是否处于被锁定状态。 如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁； 只有一个线程进入同步块 |
当前只有一个等待线程，则该线程将通过自旋进行等待。但是当自旋超过一定的次数时， 轻量级锁便会升级为重量级锁；当一个线程已持有锁， 另一个线程在自旋，而此时又有第三个线程来访时， 轻量级锁也会升级为重量级锁。虽然很多线程，但是没有冲突：多条线程进入同步块，但是线程进入时间错开因而并未争抢锁 |
重量级锁通过对象内部的监视器(m)）实现， 而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现， 操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。 发生锁争抢的情况： 多条线程进入同步块并争用锁 |
| 本质 | 如果线程处于活动状态，升级为轻量级锁的状态。取消同步操作 | CAS操作代替互斥同步 | 互斥同步 | |
| 优点 | 不阻塞，执行效率高 | 不阻塞，执行效率高（只有第一次获取偏向锁时需要CAS操作，后面只是比对ThreadId） | 不会阻塞 | 不会空耗CPU |
| 缺点 | 线程不安全 | 适用场景太局限。若竞争产生，会有额外的偏向锁撤销的消耗 | 长时间获取不到锁空耗CPU | 阻塞，上下文切换，重量级操作，消耗操作系统资源 |
版权声明
本文仅代表作者观点，不代表本站立场。
本文系作者授权发表，未经许可，不得转载。
