JAVA中的CAS

全套高级java架构师资料链接：https://pan.baidu.com/s/1sJyGASM2U3iZXECdVhpOPw 密码：dw4u
还请大家辛苦下了~

在JAVA中，CAS是compare-and-swap（比较与替换）的缩写，CAS是乐观锁的一种操作，下面具体讲解下锁。

一、悲观锁（Pessimistic Locking）

理解：即很悲观，每次拿数据的时候都认为数据会被人更改，所以每次拿数据的时候会上锁，这样别人想操作数据就会阻塞到，一直到你的锁释放。

场景：传统数据库里面就用到了很多这种机制，比如 行锁，表锁，读锁，写锁….等，都是在操作之前先上锁。

代码：比如java中的同步关键字 synchronized 的实现也是悲观锁（独占锁），volatile是不错的机制，但volatile不能保证原子性，因此同步最终还是要回到锁的机制上来。

1.同步关键字 synchronized用例：
private volatile static long VIEW = 100000;

@Override
public synchronized void run() {

    while (VIEW-- > 0) {

.......

Java在JDK1.5之前都是靠 synchronized关键字保证同步的，这种通过使用一致的锁定协议来协调对共享状态的访问，可以确保无论哪个线程持有共享变量的锁，都采用独占的方式来访问这些变量。这就是一种独占锁，独占锁其实就是一种悲观锁，所以可以说 synchronized 是悲观锁。

2.典型依赖数据库的悲观锁调用：

SELECT * FROM user_info WHERE name='zhangsan' FOR UPDATE

这条SQL语句锁定了用户表中所有符合检索条件（name=‘zhangsan’）的记录，本次事物提交之前（事物提交时会释放事物过程中的锁），外界无法修改这些数据。

也就是我们在查询 zhangsan 这条数据的时候，先用 FOR UPDATE 把这条数据锁住，然后更改完这条数据再提交，这样别的线程就没法操作这条数据，也就保证数据的一致性（不被更新丢失）。

3.hibernate的悲观锁，也是基于数据库的锁机制实现的，下面代码是对查询记录的加锁：

   String hqlStr ="from TUser as user where user.name='Erica'";

   Query query = session.createQuery(hqlStr);

   query.setLockMode("user",LockMode.UPGRADE); // 加锁

   List userList = query.list();// 执行查询，获取数据

   query.setLockMode;
      //对查询语句中，特定别名所对应的记录进行加锁（我们为 TUser 类指定了一个别名 “user” ），这里也就是对返回的所有 user 记录进行加锁。

观察运行期Hibernate生成的SQL语句：

select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
      as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
 from t_user tuser0_ where (tuser0_.name='Erica' ) for update

这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。

Hibernate的加锁模式有：
Ø LockMode.NONE ： 无锁机制。
Ø LockMode.WRITE ：Hibernate在Insert和Update记录的时候会自动获取。
Ø LockMode.READ ： Hibernate在读取记录的时候会自动获取。

以上这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
Ø LockMode.UPGRADE ：利用数据库的for update子句加锁。
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode
Query.setLockMode
Session.lock

注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。

悲观锁机制存在以下问题：
1. 在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。
2. 一个线程持有锁会导致其它所有需要此锁的线程挂起。
3. 如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

对比于悲观锁的这些问题，另一个更加有效的锁就是乐观锁。其实乐观锁就是：每次不加锁而是假设没有并发冲突而去完成某项操作，如果因为并发冲突失败就重试，直到成功为止。

二、乐观锁（Optimistic Locking）

** 理解：即很乐观，总认为不会产生并发问题，查询数据的时候总认为数据不会被其它线程更改，所以不会上锁。但是在更新的时候会判断一下在此期间别人有没有去更新这条数据，可以使用版本号机制或CAS操作实现，**主要就是两个步骤：冲突检测和数据更新。其实现方式有一种比较典型的就是 Compare and Swap ( CAS )。

场景：乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制。

代码：在java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

version方式：

一般是在数据表中加上一个数据库版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取的同时也会读取version值，在提交更新时，若刚才读到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};  

CAS操作方式：

即compare-and-swap或者compare-and-set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

乐观锁是一种思想，CAS是这种思想的一种实现方式，在JDK1.5中新增java.util.concurrent (J.U.C)就是建立在CAS之上的。相对于对于 synchronized 这种阻塞算法，CAS是非阻塞算法的一种常见实现。所以J.U.C在性能上有了很大的提升。

以 java.util.concurrent 中的 AtomicInteger 为例，看一下在不使用锁的情况下是如何保证线程安全的。主要理解 getAndIncrement 方法，该方法的作用相当于 ++i 操作。

案例见： 并发工具类之 – Atomic

原文链接：桃园小编