数据库事务与锁详解＼何谓悲观锁与乐观锁

逃离我推掉我的手 2022-05-21 11:43 224阅读 0赞

https://blog.csdn.net/aluomaidi/article/details/52460844

# 什么是事务（Transaction）？ #

是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的一个逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

举个例子加深一下理解：同一个银行转账，A转1000块钱给B，这里存在两个操作，一个是A账户扣款1000元，两一个操作是B账户增加1000元，两者就构成了转账这个事务。

*  两个操作都成功，A账户扣款1000元，B账户增加1000元，事务成功
 *  两个操作都失败，A账户和B账户金额都没变，事务失败

最后思考一下，怎么样会出现A账户扣款1000元，B账户金额不变？如果你是把两个操作放在一个事务里面，并且是数据库提供的内在事务支持，那就不会有问题，但是开发人员把两个操作放在两个事务里面，而第二个事务失败就会出现中间状态。现实中自己实现的分布式事务处理不当也会出现中间状态，这并不是事务的错，事务本身就是规定不会出现中间状态，是事务实现者做出来的方案有问题。

# 事务的4个特性 #

*  **原子性(Atomic)**：事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。
 *  **一致性(Consistency)**：事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。
 *  **隔离性(Isolation)**：由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，到底是另一个事务执行之前的状态还是中间某个状态，相互之间存在什么影响，是可以通过隔离级别的设置来控制的。
 *  **持久性(Durability)**：事务结束后，事务处理的结果必须能够得到固化，即写入数据库文件中即使机器宕机数据也不会丢失，它对于系统的影响是永久性的。

# 事务并发控制 #

我们从另外一个方向来说说，如果不对事务进行并发控制，我们看看数据库并发操作是会有那些异常情形，有些使我们可以接受的，有些是不能接受的，注意这里的异常就是特定语境下的，并不一定就是错误什么的。假设有一个order表，有个字段叫count，作为计数用，当前值为100

*  **第一类丢失更新（Update Lost）**：此种更新丢失是因为回滚的原因，所以也叫回滚丢失。此时两个事务同时更新count，两个事务都读取到100，事务一更新成功并提交，count=100+1=101，事务二出于某种原因更新失败了，然后回滚，事务二就把count还原为它一开始读到的100，此时事务一的更新就这样丢失了。
 *  **脏读（Dirty Read）**：此种异常时因为一个事务读取了另一个事务修改了但是未提交的数据。举个例子，事务一更新了count=101，但是没有提交，事务二此时读取count，值为101而不是100，然后事务一出于某种原因回滚了，然后第二个事务读取的这个值就是噩梦的开始。
 *  **不可重复读（Not Repeatable Read）**：此种异常是一个事务对同一行数据执行了两次或更多次查询，但是却得到了不同的结果，也就是在一个事务里面你不能重复（即多次）读取一行数据，如果你这么做了，不能保证每次读取的结果是一样的，有可能一样有可能不一样。造成这个结果是在两次查询之间有别的事务对该行数据做了更新操作。举个例子，事务一先查询了count，值为100，此时事务二更新了count=101，事务一再次读取count,值就会变成101，两次读取结果不一样。
 *  **第二类丢失更新（Second Update Lost）**：此种更新丢失是因为更新被其他事务给覆盖了，也可以叫覆盖丢失。举个例子，两个事务同时更新count，都读取100这个初始值，事务一先更新成功并提交，count=100+1=101，事务二后更新成功并提交，count=100+1=101,由于事务二count还是从100开始增加，事务一的更新就这样丢失了。
 *  **幻读（Phantom Read）**：幻读和不可重复读有点像，只是针对的不是数据的值而是数据的数量。此种异常是一个事务在两次查询的过程中数据的数量不同，让人以为发生幻觉，幻读大概就是这么得来的吧。举个例子，事务一查询order表有多少条记录，事务二新增了一条记录，然后事务一查了一下order表有多少记录，发现和第一次不一样，这就是幻读。

# 数据库事务隔离级别 #

看到上面提到的几种问题，你可能会想，我擦，这么多坑怎么办啊。其实上面几种情况并不是一定都要避免的，具体看你的业务要求，包括你数据库的负载都会影响你的决定。不知道大家发现没有，上面各种异常情况都是多个事务之间相互影响造成的，这说明两个事务之间需要某种方式将他们从某种程度上分开，降低直至避免相互影响。这时候数据库事务隔离级别就粉墨登场了，而数据库的隔离级别实现一般是通过数据库锁实现的。

*  **读未提交（Read Uncommitted）**：该隔离级别指即使一个事务的更新语句没有提交,但是别的事务可以读到这个改变，几种异常情况都可能出现。极易出错，没有安全性可言，基本不会使用。
 *  **读已提交（Read Committed）**：该隔离级别指一个事务只能看到其他事务的已经提交的更新，看不到未提交的更新，消除了脏读和第一类丢失更新，这是大多数数据库的默认隔离级别，如Oracle,Sqlserver。
 *  **可重复读（Repeatable Read）**：该隔离级别指一个事务中进行两次或多次同样的对于数据内容的查询，得到的结果是一样的，但不保证对于数据条数的查询是一样的，只要存在读改行数据就禁止写，消除了不可重复读和第二类更新丢失，这是Mysql数据库的默认隔离级别。
 *  **串行化（Serializable）**：意思是说这个事务执行的时候不允许别的事务并发执行.完全串行化的读，只要存在读就禁止写,但可以同时读，消除了幻读。这是事务隔离的最高级别，虽然最安全最省心，但是效率太低，一般不会用。

下面是各种隔离级别对各异常的控制能力：

<table> 
 <thead> 
  <tr> 
   <th style="vertical-align:middle;">级别\异常</th> 
   <th style="vertical-align:middle;">第一类更新丢失</th> 
   <th style="vertical-align:middle;">脏读</th> 
   <th style="vertical-align:middle;">不可重复读</th> 
   <th style="vertical-align:middle;">第二类丢失更新</th> 
   <th style="vertical-align:middle;">幻读</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="vertical-align:middle;">读未提交</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:middle;">读已提交</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
   <td style="vertical-align:middle;">Y</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:middle;">可重复读</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">Y</td> 
  </tr> 
  <tr> 
   <td style="vertical-align:middle;">串行化</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
   <td style="vertical-align:middle;">N</td> 
  </tr> 
 </tbody> 
</table>

# 数据库锁分类 #

一般可以分为两类，一个是悲观锁，一个是乐观锁，悲观锁一般就是我们通常说的数据库锁机制，乐观锁一般是指用户自己实现的一种锁机制，比如hibernate实现的乐观锁甚至编程语言也有乐观锁的思想的应用。

**悲观锁**：顾名思义，就是很悲观，它对于数据被外界修改持保守态度，认为数据随时会修改，所以整个数据处理中需要将数据加锁。悲观锁一般都是依靠关系数据库提供的锁机制，事实上关系数据库中的行锁，表锁不论是读写锁都是悲观锁。

悲观锁按照使用性质划分：

*  **共享锁（Share locks简记为S锁）**：也称读锁，事务A对对象T加s锁，其他事务也只能对T加S，多个事务可以同时读，但不能有写操作，直到A释放S锁。
 *  **排它锁（Exclusivelocks简记为X锁）**：也称写锁，事务A对对象T加X锁以后，其他事务不能对T加任何锁，只有事务A可以读写对象T直到A释放X锁。
 *  **更新锁（简记为U锁）**：用来预定要对此对象施加X锁，它允许其他事务读，但不允许再施加U锁或X锁；当被读取的对象将要被更新时，则升级为X锁，主要是用来防止死锁的。因为使用共享锁时，修改数据的操作分为两步，首先获得一个共享锁，读取数据，然后将共享锁升级为排它锁，然后再执行修改操作。这样如果同时有两个或多个事务同时对一个对象申请了共享锁，在修改数据的时候，这些事务都要将共享锁升级为排它锁。这些事务都不会释放共享锁而是一直等待对方释放，这样就造成了死锁。如果一个数据在修改前直接申请更新锁，在数据修改的时候再升级为排它锁，就可以避免死锁。

悲观锁按照作用范围划分：

*  **行锁**：锁的作用范围是行级别，数据库能够确定那些行需要锁的情况下使用行锁，如果不知道会影响哪些行的时候就会使用表锁。举个例子，一个用户表user，有主键id和用户生日birthday当你使用update … where id=?这样的语句数据库明确知道会影响哪一行，它就会使用行锁，当你使用update … where birthday=?这样的的语句的时候因为事先不知道会影响哪些行就可能会使用表锁。
 *  **表锁**：锁的作用范围是整张表。

**乐观锁**：顾名思义，就是很乐观，每次自己操作数据的时候认为没有人回来修改它，所以不去加锁，但是在更新的时候会去判断在此期间数据有没有被修改，需要用户自己去实现。既然都有数据库提供的悲观锁可以方便使用为什么要使用乐观锁呢？对于读操作远多于写操作的时候，大多数都是读取，这时候一个更新操作加锁会阻塞所有读取，降低了吞吐量。最后还要释放锁，锁是需要一些开销的，我们只要想办法解决极少量的更新操作的同步问题。换句话说，如果是读写比例差距不是非常大或者你的系统没有响应不及时，吞吐量瓶颈问题，那就不要去使用乐观锁，它增加了复杂度，也带来了额外的风险。

乐观锁实现方式：

乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。

通常实现是这样的：在表中的数据进行操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，如果相等，则说明这段期间，没有其他程序对其进行操作，则可以执行更新，将version字段的值加1；如果更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其他程序对其进行操作了，则不进行更新操作。

举例：

下单操作包括3步骤：

1.查询出商品信息

select (status,status,version) from t\_goods where id=\#\{id\}

2.根据商品信息生成订单

3.修改商品status为2

update t\_goods

set status=2,version=version+1

where id=\#\{id\} and version=\#\{version\};

除了自己手动实现乐观锁之外，现在网上许多框架已经封装好了乐观锁的实现，如hibernate，需要时，可能自行搜索"hiberate 乐观锁"试试看。

*  **版本号（记为version）**：就是给数据增加一个版本标识，在数据库上就是表中增加一个version字段，每次更新把这个字段加1，读取数据的时候把version读出来，更新的时候比较version，如果还是开始读取的version就可以更新了，如果现在的version比老的version大，说明有其他事务更新了该数据，并增加了版本号，这时候得到一个无法更新的通知，用户自行根据这个通知来决定怎么处理，比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行，否则在你判断可以更新以后正式更新之前有别的事务修改了version，这个时候你再去更新就可能会覆盖前一个事务做的更新，造成第二类丢失更新，所以你可以使用update … where … and version=”old version”这样的语句，根据返回结果是0还是非0来得到通知，如果是0说明更新没有成功，因为version被改了，如果返回非0说明更新成功。
 *  **时间戳（timestamp）**：和版本号基本一样，只是通过时间戳来判断而已，注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。
 *  **待更新字段**：和版本号方式相似，只是不增加额外字段，直接使用有效数据字段做版本控制信息，因为有时候我们可能无法改变旧系统的数据库表结构。假设有个待更新字段叫count,先去读取这个count,更新的时候去比较数据库中count的值是不是我期望的值（即开始读的值），如果是就把我修改的count的值更新到该字段，否则更新失败。java的基本类型的原子类型对象如AtomicInteger就是这种思想。
 *  **所有字段**：和待更新字段类似，只是使用所有字段做版本控制信息，只有所有字段都没变化才会执行更新。
    
    乐观锁几种方式的区别：
    
    新系统设计可以使用version方式和timestamp方式，需要增加字段，应用范围是整条数据，不论那个字段修改都会更新version,也就是说两个事务更新同一条记录的两个不相关字段也是互斥的，不能同步进行。旧系统不能修改数据库表结构的时候使用数据字段作为版本控制信息，不需要新增字段，待更新字段方式只要其他事务修改的字段和当前事务修改的字段没有重叠就可以同步进行，并发性更高。

# mysql事务隔离级别实战 #

实践是检验真理的唯一标准，掌握上面的理论之后，我们在数据库上实战一番家里更好地掌握也加深理解，同时有助于解决实际问题。不同数据库很多实现可能不同，这里以mysql为例讲解各种隔离级别下的情况，测试表为user（id,name,gender,passwd,email）。

隔离级别：read-uncommitted

脏读测试流程：   
1. A设置隔离级别为read-uncommitted（注意这里未声明都是session级别，而非全局的），开启事务，查询id=1的记录   
2. B设置隔离级别为read-uncommitted,开启事务，修改id=1的记录，但不提交   
3. A再次查询id=1的记录，和第一次查询的比较一下   
4. B事务回滚，A事务回滚。

![这里写图片描述][20160908174428502]

B：

![这里写图片描述][20160908174443940]

结论：A读到了B没有提交的内容，隔离级别为read-uncommitted的时候出现脏读。

第一类更新丢失测试流程：   
1. A设置隔离级别为read-uncommitted，开启事务，查询id=1的记录   
2. B设置隔离级别为read-uncommitted，开启事务,查询id=1的记录   
3. A修改id=1的记录   
4. B修改id=1的记录   
5. A提交   
6. B回滚   
7. A在查询一次id=1的记录，看看自己的修改是否成功

结论：结果不如我所想的，A的更新成功了，为什么呢？A执行update语句的时候对该条记录加锁了，B这时候根本无法修改直至超时，也就是至少在mysql中在read-uncommitted隔离级别下验证第一类丢失更新，据了解有的数据库好像可以设置不加锁，如果能够不加锁的话则可以实现，也贴一下图吧。

A：

![这里写图片描述][20160920181141520]

B：

![这里写图片描述][20160920181155270]

不可重复读测试流程（省略）：

结论：流程和测试脏读一样，其实在第一次测试脏读的时候就可以发现会出现不可重复读，A两次读取id=1的数据内容不同。

第二类丢失更新流程：   
1. A开启事务，查询order\_id=1的记录   
2. B开启事务，查询order\_id=1的记录   
3. A把查出来的count加1后更新   
4. B把查出来的count加1更新   
5. A提交，B也提交

![这里写图片描述][20160908225746594]

![这里写图片描述][20160908225809188]

结论：A的更新丢失，我们希望的结果是3，而实际结果是2，跟java的多线程很像对不对，read-uncommitted隔离模式下会出现第二类丢失更新。

幻读测试流程：   
1. A开启事务，查询user表所有数据   
2. B开启事务，新增一条记录   
3. A再次查询user表所有记录，和第一次作比对   
4. A回滚，B回滚

![这里写图片描述][20160908184536389]

![这里写图片描述][20160908184547579]

结论：A两次查询全表数据结果不同，read-uncommitted隔离模式下会出现幻读。

注：因为后面对这几种异常情况的测试流程基本和上面一样，个别有些差别读者自己注意，另外注意更改隔离级别即可，就能看到对应结果，后面的我只给出进一步能解决的异常测试截图,结论可以参照前面的对照表。

隔离级别：read-committed

脏读测试截图

![这里写图片描述][20160908231058914]   
B：

![这里写图片描述][20160908231121539]

结论：A没有读到B没有提交的内容，隔离级别为read-committed的时候不会出现脏读。

隔离级别：repeatable-read

不可重复读测试截图

![这里写图片描述][20160908233613781]

B：

![这里写图片描述][20160908233628156]

结论：A两次读取id=1的数据内容相同，repeatable-read隔离模式下不会出现不可重复读。

隔离级别：Serializable

幻读测试截图

![这里写图片描述][20160908235618573]

B：

![这里写图片描述][20160909000404537]

结论：因为A事务未提交之前，B事务插入操作无法获得锁而超时，Serializable隔离模式下不会出现幻读。

# **何谓悲观锁与乐观锁** #

> 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。

**悲观锁**

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

**乐观锁**

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

**两种锁的使用场景**

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像**乐观锁适用于写比较少的情况下（多读场景）**，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以**一般多写的场景下用悲观锁就比较合适。**

乐观锁常见的两种实现方式

> **乐观锁一般会使用版本号机制或CAS算法实现。**

**1. 版本号机制**

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

**举一个简单的例子：** 假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1.  操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
2.  在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
3.  操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
4.  操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须大于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

**2. CAS算法**

即**compare and swap（比较与交换）**，是一种有名的**无锁算法**。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。**CAS算法**涉及到三个操作数

*  需要读写的内存值 V
 *  进行比较的值 A
 *  拟写入的新值 B

当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个**自旋操作**，即**不断的重试**。

# **乐观锁的缺点** #

> ABA 问题是乐观锁一个常见的问题

**1 ABA 问题**

如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 **"ABA"问题。**

JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

**2 循环时间长开销大**

**自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。** 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。

**3 只能保证一个共享变量的原子操作**

CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。

**CAS与synchronized的使用情景**

> **简单的来说CAS适用于写比较少的情况下（多读场景，冲突一般较少），synchronized适用于写比较多的情况下（多写场景，冲突一般较多）**

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

补充： Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 **“重量级锁”** 。但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的 **偏向锁** 和 **轻量级锁** 以及其它**各种优化**之后变得在某些情况下并不是那么重了。synchronized的底层实现主要依靠 **Lock-Free** 的队列，基本思路是 **自旋后阻塞**，**竞争切换后继续竞争锁**，**稍微牺牲了公平性，但获得了高吞吐量**。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

[20160908174428502]: /images/20220521/b471423e621d45ddbabb621d7fdce530.png
[20160908174443940]: /images/20220521/d541f28041d74dda9458251438c1627a.png
[20160920181141520]: /images/20220521/bc6d3e52db89461484ed3685dca9713e.png
[20160920181155270]: /images/20220521/6e86d577ada9407690dfcb14238e133d.png
[20160908225746594]: /images/20220521/1e695c3738b641b99727f527109e8df3.png
[20160908225809188]: /images/20220521/c622166590984e4d940754af6c481cf5.png
[20160908184536389]: /images/20220521/8602a9bf8242449ead473110e6f808d8.png
[20160908184547579]: /images/20220521/8cf95a8b2ede4f56a9a91ae3103cb6bd.png
[20160908231058914]: /images/20220521/c7721f72ee0c49c5ad7a98c4038850a9.png
[20160908231121539]: /images/20220521/ac0887cce21b40498b3ab70a98a72c6b.png
[20160908233613781]: /images/20220521/8b7eb374f96d48e3888ad7f92300cd08.png
[20160908233628156]: /images/20220521/4d970ec5736843e2ac41a5f88337b4ac.png
[20160908235618573]: /images/20220521/e022963c696a498ca1b151db0e353e02.png
[20160909000404537]: /images/20220521/ea6ccd63943043128566b5b4e194da22.png