了解乐观锁以及悲观锁，结合场景分析

    在jsvase这种或者单个jvm的程序中，遇到并发问题的时候，可以使用synchronized进行访问控制，或者使用volatile、reentrantlock等方法。。但是在分布式环境中，就不管用了。

    如果我们业务上遇到并发，可以通过数据库锁，缓存数据库redis共享、zookeeper分布式锁等解决这里，我们为了学习数据库锁机制，简单了解依稀乐观锁和悲观锁！

一、乐观锁

    定义：数据库认为数据的更新操作在大多数情况下是不会产生冲突的，只在数据库更新操作提交的时候才会对数据做冲突检测。。如果检测结果与预期不一致，则返回失败信息。

    实现：

    1、为数据库表增加一个字段：version。即版本号，每次更新操作完毕，则version+1。。

每次更新操作开始时，先获取version值，更新提交的时候比较获取到的version值与当前version值比较，如果不相等则说明version值发生变化，也就是有其他更新操作改变了version的值，则本次执行失败，否则，执行成功。

    如：update table set columnA = 1,version = version +1 where id = #{id} 

        and version = #{oldVersion}

    2、借助更新时间戳，依旧为数据库表添加一个字段：create_at。。然后，每次更新操作时，先获取记录当前的更新时间，在提交更新操作时，检测当前更新时间是否钰刚刚获取到的时间相等，相等则执行成功，否则，执行失败。

    3、前面2种方式都是提交的时候检测版本有没有改变，只要有变化都会失败。。

    而有一类场景当字段只需要满足一个区间范围并不关心是否有数据更新冲突，且本身进行更新并且作为判断条件时，可不借助其他字段，对字段本身作判断即可。

    例如一个较常见的场景：库存的扣减，只要扣减后的值大于等于零即可。例如：update product set rest = rest– #{deduct} where name = ‘abc’ and rest >= #{deduct}

优点与缺点分析：

    优点比较明显，由于在检测数据冲突时并不依赖数据库本身的锁机制，不会影响请求的性能，当产生并发且并发量较小的时候只有少部分请求会失败。

    缺点则是，一需要对表的设计增加额外的字段，增加了数据库的冗余，另外，当应用并发量高的时候，version值在频繁变化，则会导致大量请求失败，影响系统的可用性。我们通过上述sql语句还可以看到，数据库锁都是作用于同一行数据记录上，这就导致一个明显的缺点，在一些特殊场景，如大促、秒杀等活动开展的时候，大量的请求同时请求同一条记录的行锁，会对数据库产生很大的写压力。所以综合数据库乐观锁的优缺点，乐观锁比较适合并发量不高，并且写操作不频繁的场景。

二、悲观锁

    定义：数据库认为更新数据时，产生冲突的可能性很大，所以便会将所操作的谁加锁，然后再进行操作。

    实现：通过数据库锁机制，，查询语句+for update关键字。

    如下sql语句：

     select * from table where id = 1 for update 

    当一个请求A开启事务并执行此sql同时未提交事务时，另一个线程B发起请求，此时B将阻塞在加了锁的查询语句上，直到A请求的事务提交或者回滚，B才会继续执行，保证了访问的隔离性。

悲观锁优缺点分析：

    优点是每一次行数据的访问都是独占的，只有当正在访问该行数据的请求事务提交以后，其他请求才能依次访问该数据，否则将阻塞等待锁的获取。悲观锁可以严格保证数据访问的安全，但是缺点也明显，即每次请求都会额外产生加锁的开销且未获取到锁的请求将会阻塞等待锁的获取，在高并发环境下，容易造成大量请求阻塞，影响系统可用性。另外，悲观锁使用不当还可能产生死锁的情况。

    我们来看如下情况，以商品表、用户商品列表为例：

    系统出现了2个业务操作，操作A先查询商品表并加锁，根据查询的结果作更新用户商品列表状态字段的操作，sql为 select * from product where id = 10 for update;update user_product set status = 2  where user_id = 10001;。业务操作B先查询用户商品表并加锁，根据查询结果更新商品表剩余数量的操作,sql为select * from user_product where user_id = 10001 for update；update product set rest = rest - 1 where id = 10。

    我们看一下产生死锁的过程：A业务操作开启事务，获取product表id=10的行锁，B业务操作接着开启事务并获取user_product表user_id为10001记录的行锁，A继续执行更新操作，需要等待获取user_product表user_id为10001的行锁进入阻塞状态，B继续执行更新操作需要等待获取product表id=10的行锁。此时我们可以发现数据库的状态为A等待的锁被B占住，而B等待的锁被A所占住，双方事务都未提交都在等待对方释放锁，进入一个死循环状态。

    数据库检测到产生了死锁，自动回滚了B操作的事务，释放了锁。虽然常见数据库如oracle或者mysql都有死锁检测机制，出现死锁数据库会自动回滚一个事务，但是也会造成系统的可用性和稳定性受到影响，我们应该避免在实际应用场景中出现死锁的情况，如上例所示，可以考虑把一个操作改为乐观锁实现或者改变锁的获取顺序使得2个操作都是先获取同一个锁再获取另外一个锁，以此避免死锁的发生。综合数据库悲观锁的特点，在并发量较小、又需要独占读取结果并依赖读取的结果进行判断的业务场景比较适合使用悲观锁。

借鉴：https://www.jianshu.com/p/39d8b7437b0b