乐观锁和悲观锁

 

https://zhuanlan.zhihu.com/p/40211594

悲观锁（用前都上锁）

老是假设最坏的状况，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁，表锁等，读锁，写锁等，都是在作操做以前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

 

乐观锁（更新时判断数据是否是新的）（cas 版本号 时间戳 mysql mvcc（行的建立时间，删除时间））

老是假设最好的状况，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库提供的相似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

 

两种锁的使用场景

从上面对两种锁的介绍，咱们知道两种锁各有优缺点，不可认为一种好于另外一种，像乐观锁适用于写比较少的状况下（多读场景），即冲突真的不多发生的时候，这样能够省去了锁的开销，加大了系统的整个吞吐量。但若是是多写的状况，通常会常常产生冲突，这就会致使上层应用会不断的进行retry，这样反却是下降了性能，因此通常多写的场景下用悲观锁就比较合适。

CAS与synchronized的使用情景

简单的来讲CAS适用于写比较少的状况下（多读场景，冲突通常较少），synchronized适用于写比较多的状况下（多写场景，冲突通常较多）

1. 对于资源竞争较少（线程冲突较轻）的状况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操做额外浪费消耗cpu资源；而CAS基于硬件实现，不须要进入内核，不须要切换线程，操做自旋概率较少，所以能够得到更高的性能。
2. 对于资源竞争严重（线程冲突严重）的状况，CAS自旋的几率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

 

cas 比较和替换是一个原子操做，通常失败后就自旋操做，不断重试

　　（aba问题）

　　（只能保证一个共享变量的原子操做）