浅谈java中的悲观锁，乐观锁以及CAS操作

了解volatile的同学一定知道，volatile 可以保证可见性，但是它无法保证原子性。

所谓原子性，就是一个（一系列）操作，要么全都执行，要么全都不执行，不能执行到中间某种状态就结束，同时对于外界（其它）来看，要么就是看到执行前的结果，要么就是执行后的结果，不能看到中间状态。
举一个经典的例子：多线程对于全局volatile 变量的累加，(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )代码如下：

 1 public class Main {
 2     static volatile int count = 0;
 3     static final int TOTAL = 10000;
 4
 5     public static void main(String[] args) throws InterruptedException {
 6         Runnable r = () -> {
 7             for (int i = 0; i < TOTAL; i++) {
 8                 count++;
 9             }
10         };
11
12         Thread t1 = new Thread(r);
13         Thread t2 = new Thread(r);
14         t1.start();
15         t2.start();
16
17         t1.join();
18         t2.join();
19
20         System.out.println("echo :" + count);
21     }
22 }

这个代码的执行结果如下，多次执行也基本不会达到目标值20000

1 Connected to the target VM, address: '127.0.0.1:54088', transport: 'socket'
2 echo :13533
3 Disconnected from the target VM, address: '127.0.0.1:54088', transport: 'socket'

产生这个问题的原因是，我们在处理自增操作时，它不是原子性的。

虽然两个线程对于这个变量的操作变化都是实时感知的，读的都是是实时值，但是计算和回写时可能就会出问题了。
详细说下
A 线程 将变量x自增为1
B线程读取1 ，B线程计算+1时，得到结果是2（注意此时2存在临时变量中），在计算+1时，A线程已经继续自增变量x到2甚至3，4，5，6...
B线程回写临时结果到变量x ，此时覆盖了A的操作，x 又变为了2。
此时B线程的操作就是中间状态执行期间，被其它线程并发操作了。导致回写失败。
那怎么解决呢？最常规的办法就是加并发锁，将并发的片段同步成一个整体，(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )执行期间，不允许其它线程同步操作。
这种常规的办法就是加锁，这种锁通常是指无论并发是否发生，我先加锁，保证我在执行期间肯定不受到干扰。我们将这种时刻防护并发保护数据安全的锁称之为悲观锁。
这就像是游客进入地铁闸机，不管有没有其他游客准备并行进入。闸机通道，每次只限一个人操作。

闸机的旋转门旋转 （加锁）

进入人 （数据操作）
离开闸机，进入景区 （解锁）
像传统的 synchronized ReentrantLock 等锁，都是悲观锁。都有典型的加锁解锁操作。

悲观锁锁常用于竞争激烈的并发场景下。

除了加并发锁还有啥办法呢？
还可以通过状态的变化来控制。就以我们这个例子来说。
因为出现问题的本质时因为发生了并发，我们只要判断并发有没有发生就可以。
如果并发没发生，我直接操作有没有锁无所谓，如果并发发生了，我看下对我的影响，如果对我有影响，我就认为这次操作失败了，重新操作试下。
我们观察有没有发生并发有两个点，开始和结束点，
<1>如果在开始点观察：其它线程有没有也同步读取数据。细想就发现这太难了，(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )首先你要并发的观察所有cpu核的线程有没有读数据，这个挑战太大。而且别人可能只是简单的读取一下不操作，或者即使你能观察到，别的线程也可能先于你观察就已经读到数据了。
这显然不可行的。
<2>其次就是观察结束点，数据有没有改变。别人怎么读无所谓。这种显然是可以的。我们只要监控变量的值发生变法了没有即可判断是否发生了并发，从而判断是否可以继续写。

如果线程读取的是1，操作回写的结果是2（新值），它就可以在回写时，判断下回写要覆盖的值是不是1（旧值）。如果是则覆盖写入，如果不是，则认为并发失败，重新尝试写入（或进行其它失败策略）。
这种通过判断并发是否发生才进行操作的方式，我们称之为乐观锁。
乐观并发控制一般分为三个步骤：
（1）读取 read
（2）修改 modify （计算出目标值）
（3）校验并提交/写入 （Validate & Commit）

乐观锁常常用于低并发的场景中。因为它避免了悲观锁的状态切换，因此它的性能在低并发时更高，高并发下由于冲突较多，会导致比较次数较多，从而导致性能下降。

我们业务中最常见的乐观锁，一般是在数据库层面通过where 语句来实现，
比如下边这个语句

update status = '待支付'
from order
where status = '已下单'

当用户下单后，校验身份

订单状态从初始-->（check用户身份）-->已下单-->（锁定库存）-->待支付
每次订单状态机发生正常业务状态跳转时，都check状态是否是预定状态，但是此时用户又可以并发的去操作订单，如取消订单，这时状态机的正常业务状态跳转就要发现被并发修改了，进而失败退出。
这就是乐观锁的一种典型应用场景。
像例子中这种比较变量当前值是否是预期值，如果是，就将变量值赋为心值（预期值交换为新值），如果不是则不做操作的行为
我们称之为compare and swap 比较并交换，也就是大家常说的CAS.
CAS 是一种思路，也是乐观锁的一种实现方式，除此之外，还可以通过数据库主键控制，数据库版本号等方式来实现，但是本质都差不多，就是在写入时进行原子级别的比较并写入
java中已经通过unsafe类结合c++代码实现了CAS的能力，但是操作不太方便，因此JUC中atomic包下提供了各种原子类，如：
AtomicBoolean、AtomicInteger、AtomicReference 等。(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )这些类可以直接用于业务代码的各种类型的原子操作类。（Atomic原子类/unsafe类的实现和使用，我会在后边的文章中专门讲解）
但是CAS操作本身是无法直接的解决ABA问题的。
什么是ABA问题，就是指CAS 在比较预期值时，虽然值等于预期值，但是可能已经发生并发了，
比如线程1发现变量值为A，
线程1准备将A调整为C，
此时发生了并发，其它线程将变量值调整为了B，因为某种原因调整回A
线程1CAS 写入变量时，A仍然等于预期值，但是已经不是原来的A了，此时再发生写入，可能会有异常或场景遗漏。
这种情况往往发生在变量值可以发生循环变化时，对于不会循环时，这个问题就不会产生。
常规的解决办法就是加入一个新的变量，如版本号，版本号和每次的变量值时一一映射关系。这样即使变量值循环回去，但是版本号只会递增不会循环。
一般的数值操作，即使有ABA场景的发生也不用担心，大部分由于最终一致性的情况，并不会对业务有什么冲击。只有很少的场景需要结合业务或者是对象内部变化，才会引发新的问题。

最后再说下很多人提到的CAS是无锁么？(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )并不是，CAS也是乐观锁的一种实现，也是锁，虽然我们没有显示的使用，但是内部在真正实现原子操作的那个时间段内还是需要通过各种状态、指令来控制住了并发。
比如通过数据库实现的CAS 乐观锁，那么在update时，一般会有行锁或者表锁。
通过atomic包下的原子类进行cas，虽然没有直接使用锁，但是在底层调用C++进而调用cpu指令cmpxchg时，还是通过lock 指令来锁定内存指令或者缓存行来保证控制并发。

因此CAS 肯定是用到了锁，但是对于应用层面的业务来说，感知不到锁。