用KEGG网站做KEGG富集分析,修改wordpress中附件上传大小,上海800做网站,校园网站建设系统设计文章目录 悲观锁是什么#xff1f;乐观锁是什么#xff1f;如何实现乐观锁#xff1f;什么是CAS应用局限性ABA问题是什么#xff1f; 悲观锁是什么#xff1f;
悲观锁它总是假设最坏的情况#xff0c;它会认为共享资源在每次被访问的时候就会出现线程安全问题#xff0… 文章目录 悲观锁是什么乐观锁是什么如何实现乐观锁什么是CAS应用局限性ABA问题是什么 悲观锁是什么
悲观锁它总是假设最坏的情况它会认为共享资源在每次被访问的时候就会出现线程安全问题所以每次在获取资源的时候都会上锁以避免线程安全问题发生。
也就是说共享资源每次只给一个线程使用而其他的线程则会阻塞住当占据锁的线程用完后才会把共享资源释放掉让给其它线程来进行竞争。
这样就会导致在高并发的场景下容易造成死锁、以及线程阻塞等增加系统的开销。
乐观锁是什么
乐观锁总是假设最好的情况它认为共享资源每次被访问的时不会出现线程问题所以也就不用加锁去保证线程安全因此线程可以不停地执行只有当提交修改的时候去验证对应的共享资源是否被其它线程修改。
高并发的场景下乐观锁不存在锁竞争造成线程阻塞也不会有死锁的问题在性能上往往会更胜一筹。 但是如果写操作的冲突频繁发生会频繁失败和重试这样同样会非常影响性能。
如何实现乐观锁
什么是CAS
CAS是Compare-And-Swap比较并交换的缩写是一种轻量级的同步机制主要用于实现多线程环境下的无锁算法和数据结构保证了并发安全性。它可以在不使用锁的情况下对共享数据进行线程安全的操作。
它就是用一个预期值和要更新的变量值进行比较两值相等才会进行更新。CAS 操作是一个原子操作它在执行期间不会被其他线程中断。因此它能够提供一种乐观并发控制机制避免了传统锁机制的开销和可能的线程阻塞。
它的其实主要就是两个步骤冲突检测以及数据更新。
通常包含三个参数内存位置或称为变量、期望值和新值。它的执行步骤如下 1. 读取内存位置的当前值。 2. 检查当前值是否与期望值相等。如果相等则进行步骤4如果不相等则说明其他线程已经修改了该值操作失败。 3. 如果当前值与期望值相等则将新值写入内存位置。 4. 返回操作是否成功的标志。
class AccountSafe implements Account {private AtomicInteger balance; // 原子整数类型 public AccountSafe(Integer balance) {this.balance new AtomicInteger(balance);}Overridepublic Integer getBalance() {return balance.get();}Overridepublic void withdraw(Integer amount) {while (true) {// 没同步到主存 因为是局部变量只在线程的工作内存之中int prev balance.get(); // 获取余额最新值int next prev - amount; // 修改后的余额// 真正修改if (balance.compareAndSet(prev, next)) { // 成功为true失败false,继续循环 break;}}}
}我们再来仔细看一下withdraw方法
public void withdraw(Integer amount) {// 需要不断尝试直到成功为止while (true) {// 比如拿到了旧值 1000int prev balance.get();// 在这个基础上 1000-10 990int next prev - amount;/*compareAndSet 正是做这个检查在 set 前先比较 prev 与 当前值当不一致时next 作废返回 false 表示失败比如别的线程已经做了减法当前值已经被减成了990那么本线程的这次 990 就作废了进入 while 下次循环重试直到一致以 next 设置为新值返回 true 表示成功*/if (balance.compareAndSet(prev, next)) {break;}}
}在并发环境中多个线程可以同时执行CAS操作来更新同一个内存位置的值。如果多个线程同时执行CAS操作只有一个线程的CAS操作会成功其他线程的操作将失败。在失败的情况下可以选择重试CAS操作。
应用
JVM创建对象的过程中分配内存【堆中 因为这个是共享 所以要保证安全】syn轻量级锁的时候JVM尝试使用CAS操作将对象头的Mark Word更新为指向锁记录的指针。ReentrantLock中的非公平锁也使用CAS来管理锁的状态。比如尝试获取锁时会使用CAS来检查并更新锁的状态。并发集合如ConcurrentHashMap等并发集合的实现中也大量使用了CAS操作以实现高效的线程安全访问。原子类如AtomicInteger、AtomicLong、AtomicReference等这些类提供了一组原子操作允许你在单个操作中安全地读取、写入和更新变量。这些操作背后就是通过CAS来实现的。
局限性
只能保证对单个共享变量的操作是原子性的无法保证对多行代码实现原子性高并发场景下竞争激烈CAS 失败重试会频繁发生自旋时间过长而线程又不阻塞抢占 CPU 资源导致 CPU 使用率飙升反而影响了性能 a. 指定 CAS 一共循环多少次如果超过这个次数直接失败或将线程挂起(参考 synchronized 中的自旋锁) . b. 可以通过分段的思想减少竞争使用原子累加器 LongAdder当有竞争时设置多个累加单元最后将结果汇总ABA问题
ABA问题是什么
先看例子
假设你在银行的查看账户余额。第一次查看时余额显示为100元状态A。然后打算取出50元但在操作之前出于确认目的再次检查余额发现还是100元似乎没有变化仍然是状态A。
但实际情况可能是在两次查看之间有人往你的账户存入了50元状态变为B150元然后又立即取出了50元状态再次回到A100元。尽管最终余额回到了初始查看的数值但实际上账户经历了存取的变化A-B-A。
在并发编程的上下文中这就是“ABA问题”。当你CAS操作来确保数据一致性时如果仅比较前后值是否相同都是A就可能会忽略掉中间发生的改变B状态误以为数据从未被改动过从而可能导致逻辑错误或数据不一致性
如何解决
解决ABA问题的一种常见方法是引入版本号或者时间戳每次修改变量时不仅更新其值还增加版本号或时间戳。这样即便值回到了最初的状态通过检查版本号或时间戳的不同也可以察觉到变量曾经被修改过。
AtomicStampedReference(维护版本号) AtomicStampedReference通过捆绑一个引用及其关联的stamp印记可以视为版本号或时间戳来工作以此增强传统的比较并交换CAS操作。
它允许线程在执行 CAS 操作时不仅检查引用是否发生了变化还要检查时间戳是否发生了变化。这样即使一个变量的值被修改后又改回原值由于时间戳的存在线程仍然可以检测到这中间的变化。
public class AtomicStampedReferenceDemo {private static final Logger log LoggerFactory.getLogger(AtomicStampedReferenceDemo.class);static AtomicStampedReferenceString ref new AtomicStampedReference(A, 0);public static void main(String[] args) throws InterruptedException {log.debug(main start...);// 获取值 AString prev ref.getReference();// 获取版本号int stamp ref.getStamp();log.debug(版本 {}, stamp);// 如果中间有其它线程干扰发生了 ABA 现象other();TimeUnit.MILLISECONDS.sleep(1); // 使用TimeUnit使代码更具可读性// 尝试改为 Clog.debug(change A-C {}, ref.compareAndSet(prev, C, stamp, stamp 1));}private static void other() {new Thread(() - { // 更新如果成功版本号加1log.debug(change A-B {}, ref.compareAndSet(ref.getReference(), B,ref.getStamp(), ref.getStamp() 1));log.debug(更新版本为 {}, ref.getStamp());}, t1).start();TimeUnit.MILLISECONDS.sleep(500); // 确保t1先启动new Thread(() - {log.debug(change B-A {}, ref.compareAndSet(ref.getReference(), A,ref.getStamp(), ref.getStamp() 1));log.debug(更新版本为 {}, ref.getStamp());}, t2).start();}private static void sleep(long millis) {try {Thread.sleep(millis);} catch (InterruptedException e) {Thread.currentThread().interrupt();throw new RuntimeException(e);}}
}AtomicMarkableReference(仅维护是否修改过) 与AtomicStampedReference不同它通过一个布尔标记mark来简单指示引用的对象是否曾被修改过。 这个类在执行CAS时不仅关注引用本身的比较还会检查这个伴随的标记状态。即哪怕对象的值在一段时间内经历了A-B-A由于标记的存在线程也能够感知到该对象曾经发生过变化。
// GarbageBag类定义
class GarbageBag {private String desc;public GarbageBag(String desc) {this.desc desc;}public void setDesc(String desc) {this.desc desc;}Overridepublic String toString() {return GarbageBag{ desc desc \ };}
}public class TestABAAtomicMarkableReference {private static final Logger log LoggerFactory.getLogger(TestABAAtomicMarkableReference.class);public static void main(String[] args) throws InterruptedException {GarbageBag bag new GarbageBag(装满了垃圾);// 参数2 mark 可以看作一个标记表示垃圾袋是否已满AtomicMarkableReferenceGarbageBag ref new AtomicMarkableReference(bag, true);log.debug(主线程 start...);GarbageBag prev ref.getReference();log.debug(prev.toString());new Thread(() - {log.debug(打扫卫生的线程 start...);bag.setDesc(空垃圾袋); // 假设这里清理了垃圾袋// 尝试将标记从true改为false表示垃圾袋已清空while (!ref.compareAndSet(bag, bag, true, false)) {}log.debug(bag.toString());}).start();TimeUnit.SECONDS.sleep(1); // 等待打扫卫生的线程执行log.debug(主线程想换一只新垃圾袋);boolean success ref.compareAndSet(prev, new GarbageBag(空垃圾袋), true, false);log.debug(换了么 success);log.debug(ref.getReference().toString());}
}其他文章
从底层源码剖析AQS的来龙去脉通俗易懂
