乐观锁的实现机制--CAS(Compare And Set)

本文深入探讨了乐观锁和悲观锁的概念,通过对比synchronized和CAS机制,详细解析了两者在并发控制中的应用及优缺点。并通过实例展示了原子操作类在实现线程安全中的作用。

众所周知锁有两种:乐观锁与悲观锁。

         独占锁是一种悲观锁,而 synchronized 就是一种独占锁,synchronized 会导致其它所有未持有锁的线程阻塞,而等待持有锁的线程释放锁。 

         所谓乐观锁就是,每次不加锁而是假设没有冲突而去完成某项操作,如果因为冲突失败就重试,直到成功为止。而乐观锁用到的机制就是CAS。

 下面以一组漫画来全面讲解CAS,转载来自于微信公众号:“程序员小灰”

 

 

 

—————  第二天  —————

 

 

 

 

 

 

 

 

 

 

————————————

 

 

 

 

 

示例程序:启动两个线程,每个线程中让静态变量count循环累加100次。

 

最终输出的count结果是什么呢?一定会是200吗?

 

 

 

 

 

加了同步锁之后,count自增的操作变成了原子性操作,所以最终的输出一定是count=200,代码实现了线程安全。

 

 

 

为什么这么说呢?关键在于性能问题。

      Synchronized关键字会让没有得到锁资源的线程进入BLOCKED状态,而后在争夺到锁资源后恢复为RUNNABLE状态,这个过程中涉及到操作系统用户模式内核模式的转换,代价比较高。

     尽管Java1.6为Synchronized做了优化,增加了从偏向锁轻量级锁再到重量级锁的过度,但是在最终转变为重量级锁之后,性能仍然较低。

 

jdk1.6以后 对synchronized锁做了哪些优化

1.适应自旋锁

   自旋锁:为了减少线程状态改变带来的消耗 不停地执行当前线程 

2.锁消除:

  不可能存在共享数据竞争的锁进行消除

3.锁粗化:

  将连续的加锁 精简到只加一次锁

4.轻量级锁:

 无竞争条件下 通过CAS消除同步互斥

5.偏向锁:

无竞争条件下 消除整个同步互斥,连CAS都不操作。

 

 

 

 

所谓原子操作类,指的是java.util.concurrent.atomic包下,一系列以Atomic开头的包装类。例如AtomicBooleanAtomicIntegerAtomicLong。它们分别用于Boolean,Integer,Long类型的原子性操作。

现在我们尝试在代码中引入AtomicInteger类:


 使用AtomicInteger之后,最终的输出结果同样可以保证是200。并且在某些情况下,代码的性能会比Synchronized更好。

 

 

 

 

 

什么是CAS?

CAS是英文单词Compare And Swap的缩写,翻译过来就是比较并替换。

CAS机制当中使用了3个基本操作数:内存地址V,旧的预期值A,要修改的新值B。

更新一个变量的时候,只有当变量的预期值A和内存地址V当中的实际值相同时,才会将内存地址V对应的值修改为B。

这样说或许有些抽象,我们来看一个例子:

1.在内存地址V当中,存储着值为10的变量。

 

2.此时线程1想要把变量的值增加1。对线程1来说,旧的预期值A=10,要修改的新值B=11。

 

3.在线程1要提交更新之前,另一个线程2抢先一步,把内存地址V中的变量值率先更新成了11。

 

4.线程1开始提交更新,首先进行A和地址V的实际值比较(Compare),发现A不等于V的实际值,提交失败。

 

5.线程1重新获取内存地址V的当前值,并重新计算想要修改的新值。此时对线程1来说,A=11,B=12。这个重新尝试的过程被称为自旋

 

6.这一次比较幸运,没有其他线程改变地址V的值。线程1进行Compare,发现A和地址V的实际值是相等的。

 

 

7.线程1进行SWAP,把地址V的值替换为B,也就是12。

 

 

       从思想上来说,Synchronized属于悲观锁,悲观地认为程序中的并发情况严重,所以严防死守。CAS属于乐观锁,乐观地认为程序中的并发情况不那么严重,所以让线程不断去尝试更新。

 

 

 

 

 

 

 

 

CAS的缺点:

1.CPU开销较大

在并发量比较高的情况下,如果许多线程反复尝试更新某一个变量,却又一直更新不成功,循环往复,会给CPU带来很大的压力。

2.不能保证代码块的原子性

CAS机制所保证的只是一个变量的原子性操作,而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新,就不得不使用Synchronized了。

     因为它本身就只是一个锁住总线的原子交换操作啊。两个CAS操作之间并不能保证没有重入现象。

3.ABA问题

这是CAS机制最大的问题所在。

 什么是ABA问题?怎么解决?我们下一期来详细介绍。

<think>好的,用户想了解乐观锁在数据库并发控制中的实现机制。首先,我需要明确乐观锁的基本概念和适用场景。乐观锁假设事务之间的竞争不激烈,所以不会在操作时立即加锁,而是在提交时检查数据是否被修改过。这和悲观锁不同,悲观锁会一开始就加锁,比如使用SELECT FOR UPDATE。 接下来,用户可能想知道具体的实现方式。常见的两种方法:版本号机制CASCompare-And-Swap)。版本号的话,就是在数据表中加一个版本字段,每次更新时检查版本是否一致。例如,更新语句会是UPDATE table SET data = new_data, version = version + 1 WHERE id = some_id AND version = old_version。如果受影响的行数为0,说明版本不对,需要回滚或重试。 CAS方法则是直接比较数据本身的值,比如库存扣减时,检查当前库存是否等于之前读取的值。如果相等才更新,否则失败。这可能在ABA问题,但数据库环境下可能影响不大,特别是如果操作有事务日志的话。 然后需要考虑乐观锁的适用场景。高并发但冲突少的情况,比如评论系统、文章编辑。这里用户可能想知道哪些场景适合用,哪些不适合。比如秒杀可能冲突太多,导致重试次数多,效率低,这时候可能更适合悲观锁或其他方法。 另外,用户可能关心实现时的注意事项,比如重试机制的设计、版本号的更新策略、性能影响等。需要解释这些点,帮助用户全面理解。 可能用户的问题还涉及到如何在实际项目中应用乐观锁,或者与分布式系统的结合。但根据当前问题,主要集中在数据库层面的并发控制,所以应保持重点在那里。 最后,生成相关问题时,要考虑用户可能进一步想了解的内容,比如与悲观锁的比较、具体实现中的ABA问题、性能优化方法,以及实际应用案例。这些问题能帮助用户深入理解和应用乐观锁。</think>### 乐观锁实现机制 乐观锁是一种基于冲突检测的并发控制方法,假设事务之间冲突概率较低,通过“提交时验证”机制保证数据一致性。其核心实现包含以下三个关键步骤: 1. **数据读取阶段** 事务读取目标数据并记录当前版本号或数据指纹,例如: ```sql SELECT quantity, version FROM inventory WHERE product_id = 1001; ``` 此时获得的版本号(如$version=5$)将作为后续验证依据[^1]。 2. **数据修改阶段** 在内存中完成数据修改后,通过原子操作验证数据版本是否变更: ```sql UPDATE inventory SET quantity = new_quantity, version = version + 1 WHERE product_id = 1001 AND version = 5; ``` 数学表达式可表示为: $$ \text{UPDATE成功} \iff version_{current} = version_{initial} $$ 3. **冲突处理阶段** 若受影响行数为0,说明发生数据冲突,系统可通过以下方式处理: - 自动重试(推荐3次以内) - 抛出异常由上层处理 - 返回错误提示 #### 两种具体实现方式 | 实现方式 | 原理 | 数学描述 | 适用场景 | |----------------|--------------------------|--------------------------|------------------| | 版本号机制 | 每次更新递增版本号 | $v_{new} = v_{old} + 1$ | 通用数据更新场景 | | CAS值比较 | 直接比较数据指纹 | $data_{current} = data_{snapshot}$ | 简单字段更新场景 | #### 性能优化策略 1. **指数退避重试**:每次重试间隔时间按$t_n = t_0 \times 2^n$增长 2. **热点数据分离**:对高频更新数据采用分段锁,例如将库存$Q$拆分为$Q_1, Q_2,...,Q_n$ 3. **熔断机制**:当失败率超过阈值$\alpha$(如$\alpha=0.7$)时自动切换为悲观锁 ### 应用场景对比 ```mermaid graph LR A[高并发场景] -->|低冲突率| B[乐观锁] A -->|高冲突率| C[悲观锁] B --> D[文章编辑系统] B --> E[商品评价系统] C --> F[库存秒杀系统] C --> G[银行转账系统] ``` ### 典型代码实现(Java示例) ```java public boolean updateWithOptimisticLock(Inventory inventory) { int retry = 0; while(retry < MAX_RETRY) { Inventory current = dao.get(inventory.getId()); if(current.getVersion() != inventory.getVersion()) { throw new OptimisticLockException(); } current.setQuantity(inventory.getQuantity()); int affectedRows = dao.update(current); if(affectedRows > 0) { return true; } retry++; Thread.sleep(100 * (long)Math.pow(2, retry)); } return false; } ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值