本文深度剖析多线程编程中的锁机制与CAS原理
📚技术专栏：Java并发编程
💬欢迎在讨论区交流互动
👍如果觉得有帮助不妨点赞收藏
🔗分享给正在学习编程的小伙伴们
您的支持是我持续输出的动力源泉
技术探索指南 🚀
- 学习心态
- 保持热情
- 持续精进
- 1. 主流锁机制解析
- 1.1 锁机制面试专题
- 1.1.1 读写锁的工作机制？
- 1.1.2 自旋锁的应用场景与局限性？
- 1.1.3 synchronized的可重入特性验证
- 2. 比较并交换(CAS)原理
- 2.1 CAS核心概念
- 2.2 CAS底层实现
- 2.3 CAS典型应用
- 2.3.1 原子类实现
- 2.3.2 自旋锁构建
- 2.4 CAS的ABA隐患
- 2.4.1 ABA现象解析
- 2.4.2 ABA引发的程序异常
- 2.5 CAS面试要点
学习心态
保持热情
持续精进
1. 主流锁机制解析
乐观/悲观并发控制
悲观控制策略：
始终预设最坏情况，每次数据访问都默认存在竞争，因此会预先加锁。其他线程必须等待锁释放才能继续操作。
乐观控制策略：
默认并发冲突概率较低，仅在数据更新时检测冲突。若发现冲突则通知调用方处理。
系统资源消耗级别
确保操作原子性的底层支撑：
①CPU原子指令支持
②操作系统基于硬件实现的互斥锁
③JVM构建的同步机制
重量级实现：
严重依赖操作系统提供的互斥原语。
频繁触发内核态切换，线程调度开销显著。
轻量级实现：
优先在用户空间完成同步操作。
仅在必要时才请求系统支持，减少状态切换。
等待策略对比
忙等待机制：
获取锁失败时持续重试，保持CPU活跃状态。
优势在于响应迅速，劣势是CPU占用率高。
阻塞等待机制：
获取锁失败后进入休眠状态。
节省CPU资源但响应延迟较高。
调度公平性
公平调度：
严格遵循请求顺序，先到先得。
非公平调度：
允许后来者先获取资源，提升吞吐量。
系统原生调度即为非公平模式，实现公平需额外维护队列。
重入特性
可重入实现：
允许线程重复获取已持有的锁。
Java同步机制均支持该特性。
不可重入实现：
重复加锁会导致线程死锁。
如Linux原生互斥锁即属此类。
读写分离控制
Java通过ReentrantReadWriteLock实现读写分离：
- 读锁间无竞争
- 写锁间互斥
- 读写操作互斥
适用于读多写少场景
synchronized特性分析
自适应机制：
- 根据竞争强度自动调整策略
- 初始采用乐观轻量级实现
- 竞争加剧时升级为悲观重量级
支持可重入但不保证公平性
1.1 锁机制面试专题
1.1.1 读写锁的工作机制？
实现读写操作差异化控制：
- 并发读取无阻塞
- 写入操作互斥
- 读写操作互斥
特别适合配置信息等高频读取场景
1.1.2 自旋锁的应用场景与局限性？
持续检测锁状态直至获取成功。
优势在于响应延迟低，适合短时临界区。
缺陷是长时间等待会造成CPU资源浪费。
1.1.3 synchronized的可重入特性验证
支持同一线程多次获取锁资源。
通过持有线程标识和计数器实现：
- 同线程请求时计数递增
- 计数为零时真正释放
2. 比较并交换(CAS)原理
2.1 CAS核心概念
比较并交换(Compare-And-Swap)包含三个操作：
1. 内存值比对
2. 条件满足时更新
3. 返回操作状态
属于乐观锁的典型实现方式
2.2 CAS底层实现
技术实现层次：
①Java通过Unsafe类封装
②JVM针对不同平台适配
③最终依赖CPU的原子指令
硬件支持是CAS可行性的基础
2.3 CAS典型应用
2.3.1 原子类实现
AtomicInteger的自增操作：
class AtomicInteger {
private volatile int value;
public int increment() {
int current;
do {
current = value;
} while (!compareAndSet(current, current + 1));
return current;
}
}
多线程竞争时的处理过程：
1. 各线程读取当前值
2. 成功线程完成更新
3. 失败线程重试读取
通过硬件保证比较交换的原子性
2.3.2 自旋锁构建
public class SpinLock {
private AtomicReference<Thread> owner = new AtomicReference<>();
public void lock() {
while (!owner.compareAndSet(null, Thread.currentThread())) {
// 自旋等待
}
}
public void unlock() {
owner.set(null);
}
}
2.4 CAS的ABA隐患
2.4.1 ABA现象解析
值变化轨迹：A→B→A
CAS无法感知中间状态变化
可能导致逻辑判断失误
2.4.2 ABA引发的程序异常
银行账户操作示例：
1. 线程读取余额100
2. 期间发生转账：100→50→100
3. CAS误判数据未变化
解决方案：引入版本号控制
2.5 CAS面试要点
- CAS工作原理
通过原子指令完成值比对和更新
需要硬件层面支持 - ABA问题对策
采用版本号机制： - 每次修改版本递增
- 比较值同时校验版本
- 版本不符则操作失败
本文内容告一段落，期待下次技术探讨 💡
持续关注获取更多技术干货 📖
相关文章
