数据库的乐观锁和悲观锁

   一、悲观锁

        悲观锁是一种思想，对数据被其他事务修改持保守态度，会通过数据库自身的锁机制来实现，从而保证数据操作的排它性。

        悲观锁总是假设最坏的情况，每次请求取数据的时候都认为请求会修改数据，所以在每次取数据时都会上锁，这样别的请求想要取数据就会发生阻塞的情况，一直到他拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程），比如行锁，表锁，写锁等，都是在操作之前先上锁，当其他线程想要访问数据时，都需要阻塞挂起，Java中synchronized和ReentrantLock等独占锁就是悲观锁的实现。

        select ...for update是MySQL中的悲观锁。该语句在执行过程中所有的扫描行都会被锁上，因此在MySQL中用悲观锁必须确定使用了索引，而不是全表扫描，否则会把整个表锁住。

        悲观锁适用的场景较少，悲观锁大多数情况下都是依靠数据库的锁机制来实现的，以保证程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是长事务而言，这样的开销往往无法承受，这时就需要乐观锁。

二、乐观锁

        乐观锁认为对同一数据的并发操作不会总发生，属于小概率事件，不用每次都对数据上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，也就是不使用数据库自身的锁机制，而是通过程序来实现的。在程序上，我们可以采用版本号机制或者CAS机制来实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量。在Java中java.util.concurrent.atomic包下的原子变量类就是使用了乐观锁的一种实现方式--CAS实现的。

2.1  版本号机制

        在表中设计一个版本字段version，第一次读的时候，会获取version字段的取值。然后对数据进行更新或删除操作时，会执行UPDATE...SET version = version + 1 Where version = version。此时，如果已经有事务对这条数据进行了修改，修改就不会被成功。

        这种方式类似于SVN版本管理系统，当我们修改了代码进行提交时，首先会检查当前版本号与服务器上的版本号是否一致，如果一致就可以直接提交，如果不一致就需要更新服务器上的代码，然后再进行提交。

2.2  乐观锁的时间戳机制

        时间戳和版本号机制一样，也是在更新提交的时候，将当前数据的时间戳和更新之前的时间戳进行比较 ，如果两者一致则更新成功，否则就是版本冲突。

乐观锁适合读操作多的场景，先谷底来说写的操作比较少。它的优点在于程序实现，不存在死锁的问题，不过使用场景也相对乐观，因为它阻止不了除了程序以外的数据库操作。

悲观锁适合写操作比较多的场景，因为写的操作具有排他性