悲观锁与乐观锁（数据库）

悲观锁与乐观锁

面对可能出现的并发问题的事务，不用事务隔离机制来调整，使用由SQL语句级别的操作来控制资源的上锁，排斥其他并发事务

悲观锁（Pessimistic Lock）

定义

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度。因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）
之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁

目的

当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制，在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（悲观锁），悲观锁是设计给出现并发问题极高的语句，要肯定的上锁，不让其他人访问正在进行操作的数据

使用方法

1.在对记录进行修改前，先尝试为该记录加上悲观锁
2.如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定
3.如果成功加锁，那么就可以对记录做修改，事务提交完成后就会解锁了
4.期间如果有其他对该记录做修改操作，都会抛出异常等待解锁

//以Mysql为例,要使用悲观锁，我们必须关闭MySQL数据库的自动提交属性。
//因为MySQL默认使用autocommit模式，也就是说，当我们执行一个更新操作后，MySQL会立刻将结果进行提交（sql语句：set autocommit=0）

select * from student for upadate;
//for update会把数据给锁住

弊端

悲观锁在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会，另外还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据

乐观锁（ Optimistic Locking ）

定义

乐观锁是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则返回给用户错误的信息，让用户决定如何去做
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是创建一个新的字段记录数据特征

目的

乐观锁机制采取了更加宽松的加锁机制。乐观锁是相对悲观锁而言，也是为了避免数据库幻读、业务处理时间过长等原因引起数据处理错误的一种机制，但乐观锁不会刻意使用数据库本身的锁机制，而是依据数据本身来保证数据的正确性。设计给出现并发问题不高的语句，语句频率不高，但是占用的资源很多，或者是语句频率极高，但是并发问题出现的不多的语句

使用方法

乐观锁每次在执行数据的修改操作时，都会带上一个字段标记保存数据特征==（序列号，版本号，时间戳，随机码）==
事务在进行删除，修改操作时再次检测这个标记，如果标记没有被改变说明没有DML（增删改）操作


上述操作使用序列号实现了乐观锁处理
乐观锁事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁

总结

乐观锁并未真正加锁，效率高。一旦锁掌握不好，更新失败的概率就会比较高，容易失败

悲观锁依赖数据库锁，效率低。更新失败的概率比较低