先说些题外话，昨天有人跟我说，好久没看你写东西了，我想了下。是啊，过了个节不能把今年的计划忘了，感谢你提醒我。我会继续提供优质文章大家一起成长共同进步吧。
进入正题：
AtomicInteger说到这个类相信大家都使用过，但是内部原理相信很多人都没有深究过。
一.先说两个概念 悲观锁，乐观锁
悲观锁：java里面的synchronized就是悲观锁，它是一种独占锁，先假设了一种最坏的情况“资源是被占用的”并且在占用期间会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。
乐观锁：他的核心思路就是，每次不加锁而是假设没有冲突而去完成某项操作，假如监测到冲突就失败重试，直到成功为止。
悲观锁的缺点：
由于在进程挂起和恢复执行过程中存在着很大的开销，假设一个线程需要某个资源，但是这个资源的占用时间很短，当线程第一次抢占这个资源时，可能这个资源被占用，如果此时挂起这个线程，可能立刻就发现资源可用，然后又需要花费很长的时间重新抢占锁，时间代价就会非常的高。所以当数据争用不严重时，乐观锁效果更好。
二. java中CAS的实现
CAS就是Compare and Swap的意思，比较并操作。很多的cpu直接支持CAS指令。CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。在 java.util.concurrent.atomic 包下面的所有的原子变量类型都实现了这项技术。
三.ABA问题
所谓ABA问题就是指在更新前的值是A，但在操作过程中被其他线程更新为B，又更新为 A，这时当前线程认为是可以执行的，其实是发生了不一致现象，如果这种不一致对程序有影响(真正有这种影响的场景很少，除非是在变量操作过程中以此变量为标识位做一些其他的事，比如初始化配置)，在这种情况下就要替修改加上版本号来做唯一的标示，采用初始值+版本号的联合比较法来判断，以此来避免ABA问题。
规避ABA问题可以使用AtomicStampedReference和AtomicMarkableReference这两个类。它们支持在两个变量上执行原子的条件更新。AtomicStampedReference更新一个“对象-引用”二元组，通过在引用上加上“版本号”规避。AtomicMarkableReference则更新一个“对象引用-布尔值”的二元组。
四:源码深入
private volatile int value;
public final int get() {
return value;
}
public final int incrementAndGet() {
for (;;) {
int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
public final boolean compareAndSet(int expect, int update) {
return unsafe.compareAndSwapInt(this, valueOffset, expect, update); }
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
通过声明一个volatile value(内存锁定，同一时刻只有一个线程可以修改内存值)类型的变量，再加上unsafe.compareAndSwapInt的方法，来保证实现线程同步的。
compareAndSet 传入的是执行方法时获取到的 value 属性值，next 为加 1 后的值，compareAndSet所做的为调用 Sun 的 UnSafe 的 compareAndSwapInt 方法来完成，此方法为 native 方法，compareAndSwapInt 基于的是CPU 的 CAS指令来实现的。所以基于 CAS 的操作可认为是无阻塞的，一个线程的失败或挂起不会引起其它线程也失败或挂起。并且由于 CAS 操作是 CPU 原语，所以性能比较好。
五.融会贯通
CAS这种技术固然很好，但是在复杂的情况下不推荐使用，会带来ABA问题，也可能会因为大量线程的反复重试引起不必要的资源消耗，这样就有点得不偿失了。CAS这项技术适合在一些较为简单的，线程更新不频繁的场景中使用。在简单场景中，作为synchronized的替代品来保护某个变量的原子操作，是个不错的选择。
网友评论