文章目录
悲观锁是什么？
悲观锁它总是假设最坏的情况，它会认为共享资源在每次被访问的时候就会出现线程安全问题，所以每次在获取资源的时候都会上锁，以避免线程安全问题发生。
也就是说，共享资源每次只给一个线程使用，而其他的线程则会阻塞住，当占据锁的线程用完后才会把共享资源释放掉，让给其它线程来进行竞争。
这样就会导致在高并发的场景下容易造成死锁、以及线程阻塞等，增加系统的开销。
乐观锁是什么？
乐观锁总是假设最好的情况，它认为共享资源每次被访问的时不会出现线程问题，所以也就不用加锁去保证线程安全，因此线程可以不停地执行，只有当提交修改的时候去验证对应的共享资源是否被其它线程修改。
高并发的场景下，乐观锁不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。
但是，如果写操作的冲突频繁发生，会频繁失败和重试，这样同样会非常影响性能。
如何实现乐观锁？
什么是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);
}
@Override
public Integer getBalance() {
return balance.get();
}
@Override
public 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) {
// 比如拿到了旧值 1000
int prev = balance.get();
// 在这个基础上 1000-10 = 990
int 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元（状态变为B：150元），然后又立即取出了50元（状态再次回到A：100元）。尽管最终余额回到了初始查看的数值，但实际上账户经历了存取的变化（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 AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);
public static void main(String[] args) throws InterruptedException {
log.debug("main start...");
// 获取值 A
String prev = ref.getReference();
// 获取版本号
int stamp = ref.getStamp();
log.debug("版本 {}", stamp);
// 如果中间有其它线程干扰，发生了 ABA 现象
other();
TimeUnit.MILLISECONDS.sleep(1); // 使用TimeUnit使代码更具可读性
// 尝试改为 C
log.debug("change A->C {}", ref.compareAndSet(prev, "C", stamp, stamp + 1));
}
private static void other() {
new Thread(() -> { // 更新如果成功，版本号加1
log.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;
}
@Override
public 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 可以看作一个标记，表示垃圾袋是否已满
AtomicMarkableReference<GarbageBag> 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的来龙去脉！（通俗易懂）