常见的锁策略

乐观锁 vs 悲观锁

乐观锁：乐观锁假设认为数据一般情况下不会产生并发冲突，所以在数据进行提交更新的时候，才会正式对数据是否产生并发冲突进行检测，如果发现并发冲突了，则返回用户错误的信息，让用户决定如何去做。
悲观锁的问题：总是需要竞争锁，进而导致发生线程切换，挂起其他线程；所以性能不高。

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。
乐观锁的问题：并不总是能处理所有问题，所以会引入一定的系统复杂度。

读写锁

多线程之间，数据的读取方之间不会产生线程安全问题，但数据的写入方互相之间以及和读者之间都需要进行互斥。如果两种场景下都用同一个锁，就会产生极大的性能损耗。所以读写锁因此而产生。
读写锁（readers-writer lock），看英文可以顾名思义，在执行加锁操作时需要额外表明读写意图，复数读者之间并不互斥，而写者则要求与任何人互斥。

自旋锁（Spin Lock）

在线程在抢锁失败后会进入阻塞状态，放弃 CPU，需要过很久才能再次被调度。但经过测算，实际的生活中，大部分情况下，虽然当前抢锁失败，但过不了很久，锁就会被释放。基于这个事实，自旋锁诞生了。
你可以简单的认为自旋锁就是下面的代码只要没抢到锁，就死等，不断地进行申请锁。

自旋锁的缺点：缺点其实非常明显，就是如果之前的假设（锁很快会被释放）没有满足，则线程其实是光在消耗 CPU 资源，长期在做无用功的。

可重入锁

可重入锁的字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。
Java里只要以Reentrant开头命名的锁都是可重入锁，而且JDK提供的所有现成的Lock实现类，包括synchronized关键字锁都是可重入的。

什么是 CAS

CAS: 全称Compare and swap，字面意思:”比较并交换“， CAS 其实是一个乐观锁。一个 CAS 涉及到以下操作：
我们假设内存中的原数据V，旧的预期值A，需要修改的新值B。

1. 比较 A 与 V 是否相等。（比较）
2. 如比较相等，将 B 写入 V。（交换）
3. 返回操作是否成功。

当多个线程同时对某个资源进行CAS操作，只能有一个线程操作成功，但是并不会阻塞其他线程,其他线程只会收到操作失败的信号。即第二步返回的为false，然后就进入自旋状态，将当前内存的值赋值给A（预期值），在从重复执行上面的步骤。

CAS 是怎么实现的

针对不同的操作系统，JVM 用到了不同的 CAS 实现原理，简单来讲：
java 的 CAS 利用的的是 unsafe 这个类（本地类）提供的 CAS 操作；unsafe 的 CAS 依赖了的是 jvm 针对不同的操作系统实现的 Atomic::cmpxchg（原子指令）；Atomic::cmpxchg 的实现使用了汇编的 CAS 操作，并使用 cpu 硬件提供的 lock 机制保证其原子性。java中atomic*相关的类都是依靠CAS实现的。比如atomicInteger类atomicLong等。
简而言之，是因为硬件予以了支持，软件层面才能做到。

ABA 问题（乐观锁导致的）

在上面的CAS中，原数据V的值从C变成了D又变成了C，而这个期间我们不清楚这个过程，误认为这个值没有改变。在进行写入的时候，期望值A与原数据V的值相同，就直接进行了写入，返回操作成功。但这是不正确的，举个例子：

比如你的银行卡里有1000块钱，你个朋友要借500，这时你在转账的时候不下心点了两次。二者期间恰好有人给你转了500块。我们用CAS来分析一下这个示例。原数V(1000),旧的预期值A(1000),需要修改的新值B(500),当你操作后你的卡里就只有500了，而第二次误按的就不会操作成功（因为这时的V为500不等于A1000）。而恰好别人给你转账500后你的卡里就又是1000了，而你不小心多按的一次就也会执行成功了。这就是一个ABA问题了。

解决方法：加入版本信息，例如携带 AtomicStampedReference 之类的时间戳作为版本信息，保证不会出现老的值。每次修改的时候判断预期的旧值和版本号，每次成功修改之后更改版本号，这样即使预期的值和V值相等，但因为版本号不同，所以也不能进行改，从而解决了ABA 的问题。AtomicStampedReference类就通过版本号解决了ABA问题。

synchronized 锁

JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况，进行依次升级。

无锁

没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功，其他修改失败的线程会不断重试直到修改成功。

偏向锁

对象的代码一直被同一线程执行，不存在多个线程竞争，该线程在后续的执行中自动获取锁，降低获取锁带来的性能开销。偏向锁，指的就是偏向第一个加锁线程，该线程是不会主动释放偏向锁的，只有当其他线程尝试竞争偏向锁才会被释放。偏向锁的撤销，需要在某个时间点上没有字节码正在执行时，先暂停拥有偏向锁的线程，然后判断锁对象是否处于被锁定状态。如果线程不处于活动状态，则将对象头设置成无锁状态，并撤销偏向锁；如果线程处于活动状态，升级为轻量级锁的状态。

轻量级锁

轻量级锁是指当锁是偏向锁的时候，被第二个线程 B 所访问，此时偏向锁就会升级为轻量级锁，线程 B会通过自旋的形式尝试获取锁，线程不会阻塞，从而提高性能。当前只有一个等待线程，则该线程将通过自旋进行等待。但是当自旋超过一定的次数时，轻量级锁便会升级为重量级锁；当一个线程已持有锁，另一个线程在自旋，而此时又有第三个线程来访时，轻量级锁也会升级为重量级锁。

重量级锁

指当有一个线程获取锁之后，其余所有等待获取该锁的线程都会处于阻塞状态。重量级锁通过对象内部的监视器（monitor）实现，而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock实现，操作系统实现线程之间的切换需要从用户态切换到内核态，切换成本非常高。

synchronized锁的变化流程图