莫那·鲁道

惯于闲看花飞花落, 心念天际云卷云舒.

Coder, 欢迎留言 😆.


GitHub

并发编程之-锁的优化有哪些

前言

在 JDK 1.6 之前,synchronized 性能令人担忧,但是 1.6 之后,JVM 团队针对 synchronized 做了很多的优化,让 synchroized 在性能层面相比较 ReentrantLock 不相上下。那么,JVM 团队做了哪些优化呢?

首先说,怎么才能优化?我们知道,“锁” 其实是互斥同步的具体实现,而互斥同步对性能最大的影响是阻塞的实现,挂起线程和恢复线程的操作都需要用户态转到内核态来完成。这些操作给系统的并发性能带来了很大的压力。

所以,优化的方向就是减少线程的阻塞,因为挂起线程和恢复线程需要切换到操作系统的内核状态。

Java 1.6 为了减少获得锁和释放锁带来的性能损耗,引入了 “偏向锁“ 和 ”轻量级锁“ ,在 Java SE 1.6 中,锁一共有4个状态,从低到高依次是:无锁状态,偏向锁状态,轻量级锁状态,重量级锁状态。这几个状态会随着竞争情况逐渐升级(即膨胀)。注意:锁升级之后不能降级(具体原因后面讲)。

  1. 偏向锁
  2. 轻量级锁
  3. 重量级锁
  4. 锁消除
  5. 锁粗化
  6. 除了虚拟机,程序员自己如何优化锁

1. 偏向锁

虚拟机的团队根据经验发现,大多数情况下,锁不仅不存在多线程竞争,而且总是有同一线程多次获得,为了让线程获得锁的代价更低而引入了偏向锁。

当一个线程访问同步块并获取锁时,会在对象头和栈帧中的锁记录里存储锁偏向的线程ID,以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁,只需简单的测试一下对象头的 “Mark Word” 里是否存储着指向当前线程的偏向锁。

如果测试成功,表示线程已经获得了锁。如果测试失败,则需要再测试一下 Mark Word 中偏向锁的标识是否设置了1(表示当前还是偏向锁):如果没有设置,则使用CAS 竞争锁;如果设置了,则尝试使用CAS 将对象头的偏向锁指向当前线程。

可以说,偏向锁的 “偏”,就是偏心的 “偏”,他的意思就是这个锁会偏向于第一个获得他的线程,如果在接下来的执行过程中,该锁没有被其他的线程获取,则持有偏向锁的线程将永远不需要同步

当有另外要给线程去尝试获取这个锁时,偏向模式宣告结束,后续的操作将升级为轻量级锁。

注意:偏向锁可以提高有同步但无竞争的程序性能,他同样有缺陷:如果程序中大多数的锁总是被多个不同的线程访问,那偏向模式就是多余的。1.6之后的虚拟机默认启用偏向锁,可以使用JVM参数来关闭:-XX:-UseBiasedLocking=false;程序将默认进入轻量级锁状态。

可以看到,Mark Word 是实现偏向锁的关键。而后面的轻量级锁也是通过这个实现的。

2. 轻量级锁

什么是轻量级锁呢? “轻量级” 是相对于使用操作系统互斥量来实现的传统锁而言的,因此传统的锁机制称为 “重量级” 锁。 首先需要强调一点,轻量级锁并不是用来代替重量级锁的,他的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能损耗。

线程在执行同步块之前,JVM 会先在当前线程的栈帧中创建用于存储锁记录的空间,并将对象头的 Mark Word 复制到锁记录中,官方称为 Displaced Mark Word. 然后线程尝试使用CAS 将对象头中的 Mark Word 替换为指向锁记录的指针。

如果成功,当前线程获得锁,如果失败,表示其他线程竞争锁,当前线程便会尝试使用自旋来获取锁,注意:这里线程并没有挂起自己,而是通过一定次数的自旋(默认10次,可以使用 -XX:PreBlockSpin 修改),防止切换到内核态导致的开销。

如果有2个以上的线程争用同一把锁,那么轻量级锁将会失效,升级到重量级锁。

那么为什么升级到重量级锁之后不能降级呢?假设一下:如果锁升级到重量级之后,拿到锁的某个线程被阻塞了,等待了很久,那么轻量级线程将会一直自旋等待,消耗CPU性能。所以,在升级到重量级锁后,就不能降级了,防止轻量级锁自旋消耗CPU。

可以看到偏向锁和轻量级锁的差别,偏向锁在第一个线程拿到锁之后,将把线程ID 存储在对象头中,后面的所有操作都不是同步的,相当于无锁。而轻量级锁,每次获取锁的时候还是需要使用CAS来修改对象头的记录,在没有线程竞争的情况下,这个操作是很轻量的,不需要使用操作系统的互斥机制。

3. 重量级锁

相比较轻量级锁是通过自旋来获取锁的,重量级锁则是通过操作系统将线程切换到内核态并阻塞来实现的。代价十分高昂。

下面看看各个锁的优缺点对比:

优点 缺点 适用场景
偏向锁 加锁和解锁不需要额外的消耗,和执行非同步方法相比仅存在纳秒级的差距 如果线程间存在锁竞争,会带来额外的锁撤销的消耗 适用于只有一个线程访问同步块场景
轻量级锁 竞争的线程不会阻塞,提高了程序的响应速度 如果始终得不到锁竞争的线程,使用自旋会消耗CPU 追求响应时间,同步块执行速度非常快
重量级锁 线程竞争不使用自旋,不会消耗CPU 线程阻塞,响应时间缓慢 追求吞吐量,同步块执行时间较长

什么时候使用什么锁,大家可以看看。

4. 锁消除

什么是锁消除呢?指的是 JIT 编译器在运行时,对一些没有必要同步的代码却同步了的锁进行消除。可以说时一种彻底的锁优化。通过锁消除,可以节省毫无意义的请求锁时间。

那么你们一定会问,谁会这么傻,不需要同步还去同步啊?

请看下面的代码:

  public String[] createStrings(String[] args) {
    Vector<String> v = new Vector<>();
    for (int i = 0; i < 100; i++) {
      v.add(Integer.toString(i));
    }
    return v.toArray(new String[]{});
  }

注意:v 变量只在这一个方法中使用,只是一个单纯的局部变量,分配在栈中,也就没有线程安全的说法,任何同步都是没有必要的,而Vector 的add 操作都是同步的。所以虚拟机检测到这个情况,会将锁去除。

锁消除涉及一个技术:逃逸分析。所谓逃逸分析就是观察某一个变量十分会逃出某一个作用域。在本例中,变量v没有逃出函数外,如果函数返回的不是 string 数组,而是 v 本身,那么就任务 v 逃逸出了当前函数。也就是说 v 可能被其他线程访问。如果是这样,虚拟机就不能消除 v 的锁操作。

5. 锁粗化

原则上,我们在编写代码的时候,总是推荐将同步块尽可能的小。这样是为了使得需要同步的操作数量小,如果存在锁竞争,那等待锁的线程也能尽快拿到锁。

大部分情况下,这个原则是正确的。如果如果一系列连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中的,那即使没有线程竞争,频繁的同步操作也会导致不必要的性能损耗。

如果虚拟机探测到很多零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部。即加大了同步块。

6. 除了虚拟机,程序员自己如何优化锁

  1. 减小锁的持有时间。
  2. 减小锁的粒度。
  3. 使用读写锁替换独占锁
  4. 锁分离

  5. 减小锁的持有时间。

其实这个很简单,你的锁持有的时间长,后面的线程等待的时间就长,一个线程等待1秒,10000个线程就多等待了10000秒,因此,只在必要时进行同步,这样就能明显减少线程持有锁的时间。提高系统的吞吐量。

  1. 减小锁的粒度。

这个和我们上面说的虚拟机帮助我们粗化时反的。但是,我们说,大部分情况下,减小锁的粒度也削弱多线程竞争的有效手段,比如 ConcurrentHashMap,他只锁住了 Hash 桶中的某一个桶,不像HashTable 一样锁住整个对象。

  1. 使用读写锁替换独占锁

我们之前在说 Java 世界的三把锁的时候说哪三把锁,内置锁,重入锁,读写锁,就是我们现在说的读写锁 ReadWriteLock,使用读写锁来替代独占锁是减小锁粒度的一种特殊情况,在读多写少的场合,读写锁对系统性能是有好处的。可以有效提高系统的并发能力。因为读操作不会影响数据的完整性和一致性,就像 ConcurrentHashMap 的 get 方法一样,根本不需要加锁,这个时候又要说说 HashTable ,该容器连 get 方法都加锁。你可以想象一下。

  1. 锁分离

如果将读写锁进一步延伸,就是锁分离,读写锁根据读写操作功能的不同,进行了有效的分离。而 JDK 的 LinkedBlockingQueue 则是锁分离的最佳实践。在进行 take 操作和 put 操作使用了两把不同的锁。因为他们之间根本没有竞争关系,或者说,使用队列的数据结构,将原本耦合的业务分离了。

7. 总结

今天我们总结了一些锁的优化,有虚拟机的优化,比如偏向锁,轻量级锁,自旋锁,锁粗化,锁消除, 也有我们自己的优化策略,需要平时写代码的时候注意,比如减少锁的持有时间,减小锁的粒度,在读多写少的场合使用读写锁,尽量通过合理的设计分离锁。

总之,并发是门艺术。如何提高并发的性能是每个高级程序员的追求。

good luck !!!