悲观锁和乐观锁

面试被问到了这两个锁，又一次被烤糊了。那回来查查，网上说这两个锁的还是挺多的。如下定义：

悲观锁：指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

乐观锁：乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。相对悲观锁而言，乐观锁更倾向于开发运用。（上面Copy自百科）

 

然而奇怪的是，我翻了翻数据库的书，都没有提到悲观锁和乐观锁；只是提到了读写锁，也叫读锁和写锁；也就是共享锁和排他锁。读锁是共享锁，写锁是排他锁。读锁是共享的，多个用户可以读取同一数据，互不影响；写锁是排他的，写锁会阻塞其他的读锁和写锁。如此确保在给定的时间里，只有一个用户写入；并防止其他用户读取到不一致的数据。

锁还有一个锁粒度；表锁：锁定整张表。行级锁：最大限度的支持了并发处理，锁定到行数据。

 

我们知道多个事务的隔离性需要保证（就是每个事务更新数据互不影响），提出了基于锁的协议。要求对数据的访问以互斥的方式进行；也就是说当一个事务访问某一项数据时，其他的事务都不能访问该数据项。实现方式就是对这个数据项加锁。而我们说的锁和并发有关系，那这两个锁是怎么一回事呢？从网上好多的例子中可以发现，讲述悲观锁和乐观锁，都是在写入或者更新数据的时候；那对应到数据库中，就应该是写锁；然而数据库中的写锁，是悲观锁。是不是？

而在现在的高并发电商场景中最常见的超卖行为，为了对写锁，也就是悲观锁进行优化，而提出了乐观锁；也就是省去了一部分加锁的开销，提高了吞吐量。这部分乐观锁，也是通过Version判断的方式，来决定是否要更新数据；开发人员代码来校验的。所以说这个悲观锁和乐观锁，并不是数据库中的锁；只能说这是在高并发情况下，产生的一种程序设计方法；通过加锁来防止超买超卖的产生。

找了个乐观锁的例子：

下单操作包括3步骤：

1.查询出商品信息

select (num,status,version) from t_goods where id=#{id}

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

3.修改商品status为2,num=num+1

update t_goods 

set status=2,version=version+1,num=num+1

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