JavaEE:多线程进阶(常见的锁策略)

常见的锁策略

锁是一个非常广义的问题.
synchronized只是市面上五花八门的锁的一种典型的实现.它是Java内置的,推荐使用的锁.

各种锁的概念

下面这些概念,一般面试的时候,不会直接问你,但是可能会在某某问题中,引出这样的术语.

1. 乐观锁 vs 悲观锁

   • 乐观锁: 加锁的时候,假设出现锁冲突的概率不大,接下来要围绕加锁做的工作,就会更少.
   • 悲观锁: 加锁的时候,假设出现锁冲突的概率很大,接下来围绕加锁要做的工作,就会更多

   synchronized这把锁算是自适应的.
   synchronized初始情况下是乐观的,同时它会在背后偷偷统计锁冲突了多少次.如果发现锁冲突的次数达到一定程度了,就会变为悲观的.

2. 重量级锁 vs 轻量级锁

   • 重量级锁: 加锁的开销比较大,要做更多的工作.(往往悲观的时候,会做的重)
   • 轻量级锁: 加锁的开销比较小,要做的工作相对更少.(往往乐观的时候,会做的轻)

   但是不能就认为是100%等价.
   乐观悲观,是站在"预估锁冲突"的角度.
   重量轻量,则是站在"加锁开销"的角度

3. 挂起等待锁 vs 自旋锁

   • 挂起等待锁: 属于是悲观锁/重量级锁的一种典型实现.当线程无法获取锁时，会选择主动让出CPU,并进入等待队列（通常是被操作系统挂起）,直到 锁被释放并收到通知后才重新参与CPU调度 。
   • 自旋锁: 属于乐观锁/轻量级锁的一种典型实现.当线程无法获取锁时，会不停的检测锁是否被释放,一旦锁释放了,就立即有机会能够获取到锁

   轻量级锁,就是基于"自旋"的方式实现的(JVM内部,用户态代码实现的)
   重量级锁,就是基于"挂起等待锁"的方式实现的(调用操作系统api,在内核中实现的)

4. 公平锁 vs 非公平锁

   • 公平锁: 其他线程按照先来后到的顺序来获取锁.
   • 非公平锁: 其他线程按照"概率均等"的方式来竞争锁.(概率不一定是数学上的严格均等)

   synchronized属于非公平锁.

5. 可重入锁 vs 不可重入锁

   • 可重入锁: 一个线程,针对同一把锁,可以连续加锁两次以上.
   • 不可重入锁: 一个线程,针对同一把锁,不能连续加锁两次以上,否则会出现死锁问题.

   可重入锁的实现逻辑:

   1. 记录当前是哪个线程持有了这把锁.
   2. 在加锁的时候判定,当前申请锁的线程,是否是锁的持有者线程.
   3. 通过计数器,记录加锁的次数,从而确定何时真正释放锁.

6. 读写锁
   读写锁把加锁操作分成两种情况:读加锁和写加锁.

   • 如果,多个线程,同时读一个变量,此时没有线程安全问题.
   • 但是,一个线程读/一个线程写 或者 两个线程都写 就会产生问题.

   读写锁提供了两种加锁的api:加读锁和加写锁.

   • 如果两个线程,都是按照读方式加锁,此时不会产生锁冲突.
   • 如果两个线程,都是加写锁,此时会产生锁冲突.
   • 如果一个线程是读锁,一个线程是写锁,也会产生锁冲突.

   虽然两种加锁的api不同,但是解锁的api是一样的.

   Java标准库提供了ReentrantReadWriteLock类,实现了读写锁.

   • ReentrantReadWriteLock.ReadLock类表示一个读锁,这个对象提供了lock/unlock方法进行加锁解锁.
   • ReentrantReadWriteLock.WriteLock类表示一个写锁,这个对象也提供了lock/unlock方法进行加锁解锁.

   其中:
   读加锁和读加锁之间,不互斥.
   写加锁和写加锁之间,互斥.
   读加锁和写加锁之间,互斥.
   synchronized不是读写锁.

synchronized

特点

synchronized有以下特点:

1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.
2. 开始是轻量级锁实现, 如果锁被持有的时间较长,就转换成重量级锁.
3. 自旋 or 挂起等待,自适应.
4. 是非公平锁.
5. 是可重入锁.
6. 不是读写锁.

加锁过程

刚开始使用synchronized加锁,首先锁会处于"偏向锁"状态.
当遇到线程之间的锁竞争时,会升级到"轻量级锁".
进一步的统计出现的频次,次数达到一定程度后,会升级到"重量级锁".

上述锁升级的过程,主要是为了能够让synchronized适应不同的场景,降低程序员的使用负担~

上述锁升级的过程不可逆!

理解一下偏向锁:
偏向锁,不是真的加锁,而只是做一个标记.(标记的过程非常的轻量高效)

锁消除(编译器的优化策略)

编译器会对你写的synchronized代码,做出判定,判定这个地方是否需要加锁.
如果这里没有必要加锁,编译器就能够自动把synchronized给干掉.

虽然存在锁消除,但是咱们在写代码的时候,不能完全指望这个,最好不要无脑加锁.

锁粗化(编译器的优化策略)

要讲锁粗化,那就不得不提到锁的粒度.

在一个锁内,代码越多,粒度就越粗;代码越少,粒度就越细.
注意了,这里的"代码多",指的是执行过程中实际运行的代码行数.

锁粗化,就是把多个"细粒度"的锁,合并成"粗粒度"的锁.

锁粗化可以减少获取和释放锁的次数，从而降低锁带来的开销。
需要注意的是，锁粗化并不是适用于所有情况的优化策略。在某些情况下，锁粒度较细可能是必要的，以保证程序的正确性和性能。

本文到这里就结束啦~