乐观锁与悲观锁：
乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。
乐观锁：乐观锁在操作数据时非常乐观，认为别人不会同时修改数据。
因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。
悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。
因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。
实现方式：
悲观锁的实现方式是加锁，加锁既可以是对代码块加锁（如Java的synchronized关键字），也可以是对数据加锁（如MySQL中的排它锁）。
乐观锁的实现方式主要有两种：CAS机制和版本号机制
代码中悲观锁和乐观锁实现：
悲观锁：synchronize
乐观锁：CAS机制（原子性操作，原子类）
CAS操作包括了3个操作数：
需要读写的内存位置(V)
进行比较的预期值(A)
拟写入的新值(B)
CAS是由CPU支持的原子操作，其原子性是在硬件层面进行保证的。
下面以Java中的自增操作(i++)为例，看一下悲观锁和CAS分别是如何保证线程安全的。
我们知道，在Java中自增操作不是原子操作，它实际上包含三个独立的操作：
读取i值；
加1；
将新值写回i
因此，如果并发执行自增操作，可能导致计算结果的不准确。
在下面的代码示例中：value1没有进行任何线程安全方面的保护，value2使用了乐观锁(CAS)，value3使用了悲观锁(synchronized)。
运行程序，使用1000个线程同时对value1、value2和value3进行自增操作，可以发现：value2和value3的值总是等于1000，而value1的值常常小于1000。
publicclassTest{
//value1：线程不安全
privatestaticintvalue1 =0;
//value2：使用乐观锁
privatestaticAtomicInteger value2 =newAtomicInteger(0);
//value3：使用悲观锁
privatestaticintvalue3 =0;
privatestaticsynchronizedvoidincreaseValue3(){
value3++;
}
publicstaticvoidmain(String[] args) throws Exception{
//开启1000个线程，并执行自增操作
for(inti =0; i <1000; ++i){
newThread(newRunnable() {
@Override
publicvoidrun()
{
try{
Thread.sleep(100);
}catch(InterruptedException e) {
e.printStackTrace();
}
value1++;
value2.getAndIncrement();
increaseValue3();
}
}).start();
}
//打印结果
Thread.sleep(1000);
System.out.println("线程不安全："+ value1);
System.out.println("乐观锁(AtomicInteger)："+ value2);
System.out.println("悲观锁(synchronized)："+ value3);
}
}
首先来介绍AtomicInteger。
AtomicInteger是java.util.concurrent.atomic包提供的原子类，利用CPU提供的CAS操作来保证原子性；
除了AtomicInteger外，还有AtomicBoolean、AtomicLong、AtomicReference等众多原子类。
下面看一下AtomicInteger的源码，了解下它的自增操作getAndIncrement()是如何实现的（源码以Java7为例，Java8有所不同，但思想类似）。
publicclassAtomicIntegerextendsNumberimplementsjava.io.Serializable{
//存储整数值，volatile保证可视性
privatevolatileintvalue;
//Unsafe用于实现对底层资源的访问
privatestaticfinalUnsafe unsafe = Unsafe.getUnsafe();
//valueOffset是value在内存中的偏移量
privatestaticfinallongvalueOffset;
//通过Unsafe获得valueOffset
static{
try{
valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));
}catch(Exception ex) {thrownewError(ex); }
}
publicfinalbooleancompareAndSet(intexpect,intupdate){
returnunsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
publicfinalintgetAndIncrement(){
for(;;) {
intcurrent = get();
intnext = current +1;
if(compareAndSet(current, next))
returncurrent;
}
}
}
源码分析说明如下：
1.getAndIncrement()实现的自增操作是自旋CAS操作：在循环中进行compareAndSet，如果执行成功则退出，否则一直执行。
2.其中compareAndSet是CAS操作的核心，它是利用Unsafe对象实现的。
3.Unsafe又是何许人也呢？
Unsafe是用来帮助Java访问操作系统底层资源的类（如可以分配内存、释放内存），通过Unsafe，Java具有了底层操作能力，可以提升运行效率；
强大的底层资源操作能力也带来了安全隐患(类的名字Unsafe也在提醒我们这一点)，因此正常情况下用户无法使用。
AtomicInteger在这里使用了Unsafe提供的CAS功能。
4.valueOffset可以理解为value在内存中的偏移量，对应了CAS三个操作数(V/A/B)中的V；偏移量的获得也是通过Unsafe实现的。
5.value域的volatile修饰符：Java并发编程要保证线程安全，需要保证原子性、可视性和有序性；
CAS操作可以保证原子性，而volatile可以保证可视性和一定程度的有序性；
在AtomicInteger中，volatile和CAS一起保证了线程安全性。
数据库操作中的悲观锁和乐观锁实现：
悲观锁：for update
乐观锁：版本号方式
@Transactional
publicvoidupdateCoins(Integer playerId){
//根据player_id查询玩家信息
Player player = query("select coins, level from player where player_id = {0}", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数
update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}
为了避免这个问题，悲观锁通过加锁解决这个问题，代码如下所示。在查询玩家信息时，使用select …… for update进行查询；
该查询语句会为该玩家数据加上排它锁，直到事务提交或回滚时才会释放排它锁；
在此期间，如果其他线程试图更新该玩家信息或者执行select for update，会被阻塞。
@Transactional
publicvoidupdateCoins(Integer playerId){
//根据player_id查询玩家信息（加排它锁）
Player player = queryForUpdate("select coins, level from player where player_id = {0} for update", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数
update("update player set coins = {0} where player_id = {1}", newCoins, playerId);
}
版本号机制则是另一种思路，它为玩家信息增加一个字段：version。在初次查询玩家信息时，同时查询出version信息；
在执行update操作时，校验version是否发生了变化，如果version变化，则不进行更新。
@Transactional
publicvoidupdateCoins(Integer playerId){
//根据player_id查询玩家信息，包含version信息
Player player = query("select coins, level, version from player where player_id = {0}", playerId);
//根据玩家当前信息及其他信息，计算新的金币数
Long newCoins = ……;
//更新金币数，条件中增加对version的校验
update("update player set coins = {0},version=version+1 where player_id = {1} and version = {2}", newCoins, playerId, player.version);
}
三、优缺点和适用场景
乐观锁和悲观锁并没有优劣之分，它们有各自适合的场景；下面从两个方面进行说明。
1、功能限制
与悲观锁相比，乐观锁适用的场景受到了更多的限制，无论是CAS还是版本号机制。
例如，CAS只能保证单个变量操作的原子性，当涉及到多个变量时，CAS是无能为力的，而synchronized则可以通过对整个代码块加锁来处理。
再比如版本号机制，如果query的时候是针对表1，而update的时候是针对表2，也很难通过简单的版本号来实现乐观锁。
2、竞争激烈程度
如果悲观锁和乐观锁都可以使用，那么选择就要考虑竞争的激烈程度：
当竞争不激烈 (出现并发冲突的概率小)时，乐观锁更有优势，因为悲观锁会锁住代码块或数据，其他线程无法同时访问，影响并发，而且加锁和释放锁都需要消耗额外的资源。
当竞争激烈(出现并发冲突的概率大)时，悲观锁更有优势，因为乐观锁在执行更新时频繁失败，需要不断重试，浪费CPU资源。
四、面试官追问：乐观锁加锁吗？
笔者在面试时，曾遇到面试官如此追问。下面是我对这个问题的理解：
1.乐观锁本身是不加锁的，只是在更新时判断一下数据是否被其他线程更新了；AtomicInteger便是一个例子。
2.有时乐观锁可能与加锁操作合作，例如，在前述updateCoins()的例子中，MySQL在执行update时会加排它锁。
但这只是乐观锁与加锁操作合作的例子，不能改变“乐观锁本身不加锁”这一事实。
五、面试官追问：CAS有哪些缺点？
面试到这里，面试官可能已经中意你了。
不过面试官准备对你发起最后的进攻：你知道CAS这种实现方式有什么缺点吗？
下面是CAS一些不那么完美的地方：
1、ABA问题
假设有两个线程——线程1和线程2，两个线程按照顺序进行以下操作：
(1)线程1读取内存中数据为A；
(2)线程2将该数据修改为B；
(3)线程2将该数据修改为A；
(4)线程1对数据进行CAS操作
在第(4)步中，由于内存中数据仍然为A，因此CAS操作成功，但实际上该数据已经被线程2修改过了。这就是ABA问题。
在AtomicInteger的例子中，ABA似乎没有什么危害。
但是在某些场景下，ABA却会带来隐患，例如栈顶问题：一个栈的栈顶经过两次(或多次)变化又恢复了原值，但是栈可能已发生了变化。
对于ABA问题，比较有效的方案是引入版本号，内存中的值每发生一次变化，版本号都+1；
在进行CAS操作时，不仅比较内存中的值，也会比较版本号，只有当二者都没有变化时，CAS才能执行成功。
Java中的AtomicStampedReference类便是使用版本号来解决ABA问题的。
2、高竞争下的开销问题
在并发冲突概率大的高竞争环境下，如果CAS一直失败，会一直重试，CPU开销较大。
针对这个问题的一个思路是引入退出机制，如重试次数超过一定阈值后失败退出。
当然，更重要的是避免在高竞争环境下使用乐观锁。
3、功能限制
CAS的功能是比较受限的，例如CAS只能保证单个变量（或者说单个内存值）操作的原子性，这意味着：
(1)原子性不一定能保证线程安全，例如在Java中需要与volatile配合来保证线程安全；
(2)当涉及到多个变量(内存值)时，CAS也无能为力。
除此之外，CAS的实现需要硬件层面处理器的支持，在Java中普通用户无法直接使用，只能借助atomic包下的原子类使用，灵活性受到限制。
