CAS 其实是我们面试中的常客，因为它是原子类的底层原理，同时也是乐观锁的原理，它的英文全称是 Compare-And-Swap，中文叫做 “比较并交换”，它是一种思想、一种算法。
在多线程的情况下，各个代码的执行顺序是不能确定的，所以为了保证并发安全，我们可以使用互斥锁。
而 CAS 的特点是避免使用互斥锁，当多个线程同时使用 CAS 更新同一个变量时，只有其中一个线程能够操作成功，而其他线程都会更新失败。
不过和同步互斥锁不同的是，更新失败的线程并不会被阻塞，而是被告知这次由于竞争而导致的操作失败，但还可以再次尝试。
CAS 被广泛应用在并发编程领域中，以实现那些不会被打断的数据交换操作，从而就实现了无锁的线程安全。该技术既能保证安全性，又不需要使用互斥锁，能大大提升工具类的性能。
ConcurrentHashMap 对于 CAS 的应用是比较广泛的。
CAS 有什么缺点？
首先，CAS 最大的缺点就是 ABA 问题。
某个值假设从 A 变成了 B，再由 B 变回了 A，此时，我们不仅认为它发生了变化，并且会认为它变化了两次。
在这种场景下，我们使用 CAS，就看不到这两次的变化，因为仅判断 “当前的值和预期的值是否一致” 就是不够的了。
所以 CAS 会认为变量的值在此期间没有发生过变化。所以，CAS 并不能检测出在此期间值是不是被修改过，它只能检查出现在的值和最初的值是不是一样。
那么如何解决这个问题呢？添加一个版本号就可以解决。
我们在变量值自身之外，再添加一个版本号，那么这个值的变化路径就从 A→B→A 变成了 1A→2B→3A，这样一来，就可以通过对比版本号来判断值是否变化过，这比我们直接去对比两个值是否一致要更靠谱，所以通过这样的思路就可以解决 ABA 的问题了。
CAS 的第二个缺点就是自旋时间过长。
由于单次 CAS 不一定能执行成功，所以 CAS 往往是配合着循环来实现的，有的时候甚至是死循环，不停地进行重试，直到线程竞争不激烈的时候，才能修改成功。可是如果我们的应用场景本身就是高并发的场景，就有可能导致 CAS 一直都操作不成功，这样的话，循环时间就会越来越长。而且在此期间，CPU 资源也是一直在被消耗的，这会对性能产生很大的影响。所以这就要求我们，要根据实际情况来选择是否使用 CAS，在高并发的场景下，通常 CAS 的效率是不高的。
