Java锁的策略

🙉专栏推荐:Java入门知识🙉

🙉 内容推荐:<多线程案例(线程池)>🙉

🐹今日诗词:"你我推心置腹, 岂能相负"🐹

锁的策略

乐观锁和悲观锁

轻量级锁和重量级锁

自旋锁和挂起等待锁

自适应锁(synchronized)

普通互斥锁和读写锁

公平锁和非公平锁

可重入锁和不可重入锁

synchronized是哪种类型的锁

mutex是哪种类型的锁

synchronized内部工作原理

1. 偏向锁阶段

2. 轻量级锁阶段

3.重量级锁阶段

锁消除

锁粗化

小结

CAS

原子类

CAS的ABA问题

美图分享

⛳️点赞 ☀️收藏⭐️关注💬卑微小博主🙏

锁的策略

锁策略有很多种,大致分为:

1. 乐观锁和悲观锁

2. 轻量级锁和重量级锁

3. 自旋锁和挂起等待锁

4. 自适应锁

5. 普通互斥锁和读写锁

6. 公平锁和非公平锁

乐观锁和悲观锁

乐观锁: 在加锁之前进行预估, 如果预估锁冲突的概率很小, 加锁时就不会进行太多操作

悲观锁: 预估锁冲突概率很大, 加锁的操作就会很复杂,防止代码出错

乐观锁加锁过程做的操作较少,因此加锁速度可能比较快,但是可能容易出现错误

悲观锁加锁操作比较多, 加锁速度较慢,但是不容易出错

轻量级锁和重量级锁

和乐观锁和悲观锁不同的是: 轻量级和重量级是对加锁之后,对加锁结果的评价

轻量级锁: 加锁速度快,开销小就是轻量级锁, 一般也叫乐观锁

重量级锁: 加锁速度慢,开销大就是重量级锁, 一般也叫悲观锁

自旋锁和挂起等待锁

自旋锁和挂起等待锁就是轻量级锁和重量级锁的典型实现

自旋锁: 加锁的时候搭配一个循环,循环执行的过程就是自旋, ,自旋检测到其他线程释放锁时,第一时间就会加上锁,没有就进行下一次循环. 如果一直循环,就会长时间占用CPU资源, 因此自旋锁比较适用于锁冲突较少的情景, 是一种乐观锁

挂起等待锁: 当加锁线程特别多时, 如果使用自旋锁, 长时间循环,会浪费CPU资源, 如果此时让他挂起等待, 把CPU资源让出来, 因此挂起等待锁是一个悲观锁, 适用于锁冲突比较激烈的情景, 当挂起等待时,内核调度器会介入,这里的操作会比较多,真正获取到锁花的时间也会更多

自适应锁(synchronized)

synchronized可以对锁冲突进行评估,选择最合适的锁策略, 因此也叫做自适应锁

普通互斥锁和读写锁

普通互斥锁: 就是synchronized的加锁,解锁

读写锁: 分成加读锁和加写锁

加读锁: 一个线程加锁和读锁时, 另一个线程只能读锁, 不能写锁

加写锁: 一个线程加锁和写锁时, 另一个线程既不能读锁, 也不能写锁

公平锁和非公平锁

公平锁: 遵循先来后到, 排在最前面的线程最先获取加锁资格

非公平锁: 线程加锁顺序是随机的, 为非公平锁

下面这个图很形象

可重入锁和不可重入锁

概念: 对同一个线程加锁两次不会死锁, 反之则是不可重入锁

synchronized是哪种类型的锁

1. 乐观锁/悲观锁自适应

2. 轻量级锁/重量级锁自适应

3. 自旋锁/挂起等待锁自适应

4. 不是读写锁

5. 非公平锁

6. 可重入锁看

mutex是哪种类型的锁

mutex是Linux中的锁

1. 悲观锁

2. 重量级锁

3. 挂起等待锁

4. 不是读写锁

5. 非公平锁

6. 不可重入锁

synchronized内部工作原理

当对象执行到synchronized时, 如果对象处于未加锁的状态时,会分成三个阶段执行

1. 偏向锁阶段

2. 轻量级锁阶段

3. 重量级锁阶段

1. 偏向锁阶段

核心思想: 懒汉模式, 能不加锁就不加锁, 能晚加锁就晚一点加锁

偏向锁并没有加锁, 只是做了一个标记, 如果没有其他线程来竞争这个锁, 不加锁可以大幅度提高代码执行效率, 如果有其他线程想加锁, 就会提前抢在这个线程之前加锁, 总的来说就是非必要不加锁.

注意: 对象首次加锁先进入偏向锁, 如果没有锁竞争, 下次加锁还是先进入偏向锁,

如果出现锁竞争了, 就会进入轻量级锁, 并且下次加锁时跳过偏向锁阶段, 直接进入轻量级锁阶段

2. 轻量级锁阶段

synchronized内部会统计有多少个线程参与对这个锁对象的竞争, 根据这个进一步区分轻量级锁和重量级锁

轻量级锁阶段就是: 线程之间有竞争, 但是不多, 轻量级锁一般通过自旋锁实现

优势: 其他线程释放锁, 自旋锁能够第一时间获取到锁

坏处: 内部一直循环比较消耗CPU

对于自旋锁来说, 如果同一个锁对象竞争者很多, 大量线程都在自旋, 这时候CPU开销就会非常大, 需要考虑升级为自旋锁

3.重量级锁阶段

重量级锁, 不会让线程自旋了, 而是阻塞等待, 把CPU资源让出来, 当线程释放锁时, 系统就会随机唤醒一个线程进行加锁

锁消除

也是synchronized内部一种优化方式, 代码编译过程中, 如果发现不需要加锁, 编译器就会直接把锁给干掉

锁粗化

编译器会把一些细粒度的锁合并成一个粗粒度的锁

细粒度: synchronized () { }, 一般情况下, 大括号里的代码越少, 细粒度越高.

细粒度高的好处: 由于代码少执行速度较快, 加锁解锁的速度也快, 有利于线程并发执行

细粒度高的坏处: 频繁的加锁解锁可能会造成线程阻塞

有些情况下还是希望锁粗粒度更好, 比如职场工作中, 你做完一个任务就去打电话给领导汇报一下成果, 又做完一个任务再去打电话给领导汇报成果,反复如此, 领导就会烦, 并且你汇报的过程, 其他员工也可能在汇报成果(此时你就阻塞了), 因此你可以把多个成果合并在一起给领导进行汇报

小结

synchronized内部优化策略大致有这些

1. 锁升级: 偏向锁 -> 轻量级锁 -> 重量级锁

2. 锁消除: 自动干掉不必要的锁

3. 锁粗化: 将细粒度的锁合并成粗粒度的锁

CAS

compare and swap ,这是一条CPU指令, 和Java关系不大, 但是面试要考

表示比较和交换, 这是一条原子指令, 安全性杠杠的,不会出现线程安全问题

原子类

Java中一些类对CAS指令进行了封装, 构成了原子类, 封装在
import java.util.concurrent.atomic这个包下面
这些类可以保证参数进行操作的原子性

最常用的莫过于AtomicInterger类了

它保证了关于int类型的数据加或者减都是原子操作

CAS的ABA问题

CAS指令是比较, 如果相等就交换, 但是根据唐妞不等式相等 != 没改变过直接秒了

比如: A -> B -> A 还是相等, 但是A已经发生过改变

CAS在大多数情况下是安全的

极端情况下可能会出一些问题: 比如银行取款, 取款按钮用户可能会多按几下,

这是系统就会有很多扣款请求

这种情况其实挺常见的,比如电梯按钮,很多人就会狂按

具体执行流程如下:

但是扣款过程中有人向账户里转入500块呢

执行流程:

这种情况非常苛刻, 用户连续点击多次,取钱的时正好有人转入, 并且转入金额和取出金额相同

账户余额只是一个数字可加可减, 我们引入一个只能加不能减的版本号, 通过判断版本号来选择执行操