在那个网站找模具做网站运营专员做什么

CAS

Java中想实现一个乐观锁，都有哪些方式？

为什么要上锁？锁的本质是什么？

​ 上锁其实是为了保证共享资源能被正确修改，为什么不上锁就不能保证共享资源被正确修改呢？因为JMM是有共享主存和每个线程私有的内存的，线程并不总是都把资源马上从私有内存同步到主存，这就有了时间差，而且也可能产生覆盖问题，此时就是我们常说的线程不安全。这时候我们用synchronized或者ReentrantLock锁住一段代码，保证同一时间只有一个线程操作这里面的资源，即使不马上同步到主存，也没关系，因为没有其它线程来竞争。而且只要出了锁的范围，就会同步到主存。

​ 上面的资源指的就是在堆中的有状态的（有成员变量）对象

可以看到synchronized和ReentrantLock锁的都是一段代码块，锁的粒度是很粗的，里面可能会有一些不存在并发安全的代码，比如说计算，真正有并发安全问题的是“对共享资源的访问和修改”，所以我们其实可以把锁的粒度放细一点，同时，并不总是一直会有“对共享资源的访问和修改”，所以我们可以基于一种乐观的思想，比较资源的现有值和预期值，如果一致，说明没被人访问过，那么我就可以修改。

预期值和现有值是什么？

​ 比如一个对象里有个字段int a，我之前读出来，读出a是2，这个2就是预期值，那么我需要把他加10，更改为12，此时要更改了，我就看他的现有的实际的值，如果还是预期值2，说明在我读出来，再做运算，再到现在打算更改这个过程中，没有其它线程来修改，那么我就可以把它改为12。如果不是2，例如变成5了，那么实际值5，就和预期值2不一样了， 说明这段时间内有其它线程对其修改了，那我就不能动他，否则就产生覆盖了，因为我的12是基于2来计算出来的

CAS，compare and swap，比较并交换，就是这种“锁”，其实已经不能说是一种锁了，它更像一种思想，但是另一方面也能说是一种锁，因为上面的“比较”并“交换”是必须是原子的，不然比较完是符合预期的，但就在你准备交换的前一刹那，其它线程来修改了，那还是不一致了，所以CAS还基于了cpu底层的一个原子指令来使其原子操作

​ cmpxchg指令：CPU执行cmpxchg指令时，处理器会自动锁定总线，防止其它CPU访问共享变量；CPU同时会自动禁止中断，同时硬件会保证对共享变量的访问是原子的

CAS存在的问题：

• ABA问题，如果我查出来是A，但其它线程先改为B，又改为A，当我再准备修改值的时候，发现确实还是A，那么我就对其修改成功，但实际上我们是不应该修改的，因为虽然还是A，但这是由其它线程修改来的A，说明在我计算期间，有其他线程动了这个值，那其实就违反了我们常说的线程安全，同一资源被不同线程操作了。

​ 解决方案是使用AtomicStampedReference，这个类会给每个值加一个版本号，比较时需要同时比较值和版本 号，都符合预期才会修改

• 长时间自旋，如果一直有线程在修改，那么极有可能出现有一个线程一直改不上值，就一直重试，这就耗费了cpu资源

​ 解决方案是考虑清楚CAS的使用场景，CAS适用读多写少的场景，如果是读少写多的场景，直接用悲观锁

• 多个变量的原子操作，CAS能保证对一个变量修改的原子操作，但如果需要同时修改多个变量，那么CAS是无法保证的

​ 解决方案是将多个变量放到一个AtomicReference中，原子地修改这个类。或者多个CAS外面套一层悲观锁， 保证多个CAS是原子的

class MultiVar {int var1;int var2;
}
AtomicReference<MultiVar> atomicRef = new AtomicReference<>(new MultiVar(0, 0));
atomicRef.compareAndSet(oldValue, newValue);

CAS与悲观锁的区别：

• 粒度不同，CAS的粒度是针对一个变量的修改， 悲观锁的粒度是一段代码块
• 思想不同，CAS是乐观的思想，失败了大不了再重试，悲观锁是悲观的思想，我就笃定会有其它线程干扰，直接上锁
• 场景不同，CAS适用读多写少，悲观锁适用读少写多
• 开销不同，CAS开销小，悲观锁开销大

有了CAS为什么还要volatile？

​ CAS只是原子修改，并不能保证可见性，修改完后，其它线程并不一定马上能看到最新值