像之前我们说的 synchronized 这种独占锁属于悲观锁。什么是悲观锁呢？简单来说，它是在悲观的认为加锁的这个地方一定会发生冲突。除了悲观锁之后，还有乐观锁，乐观锁的含义就是我乐观的认为这个的地方不会发生冲突，如果没有发生冲突我就正常执行，如果发生了冲突，我就重试。
CAS(compare and swap) 就属于乐观锁。
CAS 基本原理
CAS(compare and swap) 比较并替换，就是将内存值更新为需要的值，但是有个条件，内存值必须与期望值相同。举个例子，期望值 E、内存值M、更新值U，当E == M的时候将M更新为U。
举个例子
为了方便理解 CAS，我们说个典型的例子。假设多个线程执行这个方法increment，势必会发生线程安全问题。因为 i++不是原子性操作(i++是典型的非原子性的操作，它不仅仅是在原始数据的基础上+1那么简单，他首先要获取到i的值，然后对其进行+1运算，然后再将计算后的结果压入i对象中。这么复杂的运算怎么会是原子性的呢？)，而且 increment方法没有加锁。
public class CASDemo {
int i = 0;
public void increment() {
i++;
}
}
解决方法有两种，第一个肯定是刚才我们说的通过 synchronized 来加锁。
// 共享变量i
int i = 0;
public synchronized void increment() {
i++;
}
这里就是通过synchronized关键字对 casDemo进行加锁。由于synchronized关键字可以保证原子性，所以i++这个原本不是原子性的操作，从某种层面上来说由于所在的方法被synchronized方法修饰了而变成原子性的了。因为这个时候由于加锁机制，导致没有其他线程能够打断他的运算过程了。
第二个办法就是将 i++变成原子性操作，如何做到呢 java.util.concurrent.atomic包中带有大量原子性的对象，比如 AtomicInteger。
// 共享变量i
AtomicInteger i = new AtomicInteger(0);
public void increment() {
i.incrementAndGet();
}
由于 increment 方法只有一行命令，而且这个方法还是原子性的，那么这个方法自然不存在线程安全问题。
看到这里，很多兄弟就会问了，你这标题不是在说CAS吗? 你怎么都在扯这些东西啊？别着急啊，前面都是铺垫，我这不是正要说了嘛。
其实 AtomicInteger类的incrementAndGet方法 就是一个 CAS 操作。CAS 的全称是 compare and set ，比较并替换。CAS的思想很简单：三个参数，一个当前内存值V、旧的预期值A、即将更新的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做，并返回false。其业务逻辑原理如图所示：
CAS的优缺点
优点
非阻塞的轻量级的乐观锁，通过CPU指令实现，在资源竞争不激烈的情况下性能高，相比synchronized重量锁，synchronized会进行比较复杂的加锁，解锁和唤醒操作。
缺点
- ABA问题：CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。这就是CAS的ABA问题。 常见的解决思路是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么
A-B-A就会变成1A-2B-3A。 目前在JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。 - 循环时间长开销大：上面我们说过如果CAS不成功，则会原地自旋，如果长时间自旋会给CPU带来非常大的执行开销。
CAS总结
CAS不仅是乐观锁，是种思想，我们也可以在日常项目中通过类似CAS的操作保证数据安全，但并不是所有场合都适合，曾看过帖子说，能用synchronized就不要用CAS，除非遇到性能瓶颈，因为CAS会让代码可读性变差，这句话看大家怎么理解了。