深入理解JAVA多线程---对synchronized的锁优化

最新推荐文章于 2024-07-13 19:47:09 发布

莫秃

最新推荐文章于 2024-07-13 19:47:09 发布

阅读量186

点赞数

分类专栏：多线程 JAVA 文章标签： java 多线程

本文链接：https://blog.csdn.net/weixin_45758058/article/details/112688528

版权

JAVA 同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

多线程

5 篇文章 0 订阅

订阅专栏

Synchronized优化

前言

前言

在多线程并发编程中Synchronized一直是元老级的角色,很多人都称呼它为重量级锁.但是随着JDK1.6对Synchronized进行了各种优化之后,有些情况下它并不呢么重了,那么接下来我们就学习一下究竟进行了那些优化.

JDK1.6之前

在JDK1.6之前Synchronized被称为悲观锁是重量级锁,它始终认为锁住的资源有很多的线程去竞争,然后对没有获得锁的线程就会直接进入阻塞状态.但是大多情况下资源并没有呢么多线程同时去竞争,因此Synchronized显得十分笨重,对系统的资源消耗很大.但是JDK1.6之后对Synchronized进行了各种优化,使得它在一些场景下效率甚至比LOCK锁还要高.

JDK1.6之后

JDK1.6只后为了减少获得锁和释放锁带来的性能消耗,引入了"偏向锁"和"轻量级锁",在JDK1.6中有四种锁状态级别依次到高为:

无锁状态
偏向锁状态
轻量级锁状态
重量级锁状态
这几个状态会随着线程的竞争逐渐升级.

一.锁升级

偏向锁

为什么引入偏向锁

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

偏向锁的升级

当一个线程访问同步块并获取锁时，会在对象头和栈帧的锁记录里存储偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需测试Mark Word里线程ID是否为当前线程。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要判断偏向锁的标识。如果标识被设置为0（表示当前是无锁状态），则使用CAS竞争锁；如果标识设置成1（表示当前是偏向锁状态），则尝试使用CAS将对象头的偏向锁指向当前线程，触发偏向锁的撤销。

偏向锁的撤销

偏向锁只有在竞争出现才会释放锁。当其他线程尝试竞争偏向锁时，程序到达全局安全点后（没有正在执行的代码），它会查看Java对象头中记录的线程是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程，撤销偏向锁，升级为轻量级锁，如果线程1不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

偏向锁的取消

偏向锁是默认开启的，而且开始时间一般是比应用程序启动慢几秒，如果不想有这个延迟，那么可以使用-XX:BiasedLockingStartUpDelay=0；

如果不想要偏向锁，那么可以通过-XX:-UseBiasedLocking = false来设置,那么程序就会默认进入轻量级锁状态.

轻量级锁

为什么引入轻量级锁

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

轻量级锁加锁

线程1获取轻量级锁时会先把锁对象的对象头MarkWord复制一份到线程1的栈帧中创建的用于存储锁记录的空间（称为DisplacedMarkWord），然后使用CAS把对象头中的内容替换为线程1存储的锁记录（DisplacedMarkWord）的地址；
如果在线程1复制对象头的同时（在线程1CAS之前），线程2也准备获取锁，复制了对象头到线程2的锁记录空间中，但是在线程2CAS的时候，发现线程1已经把对象头换了，线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。

轻量级锁解锁和膨胀

但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，比如10次或者100次，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

几种锁的对比

在这里插入图片描述

二.锁粗化

按理来说，同步块的作用范围应该尽可能小，仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，缩短阻塞时间，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。但是加锁解锁也需要消耗资源，如果存在一系列的连续加锁解锁操作(例如在for循环里加锁),可能会导致不必要的性能损耗.JVM在编译过程中就会进行锁粗化将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁，避免频繁的加锁解锁操作。