Java锁的策略

White graces：个人主页

🙉专栏推荐: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块呢

执行流程:

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

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

美图分享

---

✨🎆谢谢你的阅读和耐心！祝愿你在编程的道路上取得更多的成功与喜悦！"🎆✨🎄

⭐️点赞收藏加关注，学习知识不迷路⭐️

🎉✔️💪🎉✔️💪🎉✔️💪🎉✔️💪🎉

👍😏⛳️点赞☀️收藏⭐️关注😏👍

👍😏⛳️点赞☀️收藏⭐️关注😏👍

👍😏⛳️点赞☀️收藏⭐️关注😏👍

🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️🙆‍♂️