数据库的乐观锁和悲观锁

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作，假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。【数据锁定：数据将暂时不会得到修改】

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让用户返回错误的信息。让用户决定如何去做。

 

1.乐观锁是一种思想，实际实现中，表中有一个版本字段，首先要先获取到要更新的行的版本字段，当需要对某行或某几行更新时，查看该字段与第一次获取的是否相等，一样则更新，否则拒绝更新

之所以叫乐观，因为这个模式没有数据库加锁

乐观锁的优点是程序实现，不会存在死锁问题，阻止不了除了程序之外的数据库操作

2.悲观锁是读取的时候为后面的更新加锁，之后再来的读操作会等待，是数据库锁。

悲观锁是数据库实现，能够组织一切数据库操作

总的来说：乐观锁就是，如果你对数据库进行更新，别人在这期间进行了更新，则版本号变了，你的更新会进行检查版本号是否一致，显然这时候不一致，所以更新被拒绝，可以进行重新操作；

悲观锁则会等待前一个更新完成，才允许你更新。这些都是在并发访问的情况下会出现的情况

实现

• 悲观锁
  • 排他锁，类似于互斥锁，当事务在操作数据时把这部分数据进行锁定，直到操作完成后在解锁，其他事务才可以操作该部分数据，MySQL中需要用到InnoDB（这个引擎支持行级锁），这将防止其他进程读取或者修改表中的数据
  • 依靠数据库的锁机制实现
  • 一般使用select...for update 对所选的数据进行加锁，可能是一行或多行数据，在本次事务提交前（提交时才会释放锁），外界都无法修改这些数据。
• 乐观锁
  • 如果有人在你之前更新了，导致你前后两次获取到的版本字段不一致，所以你的更新应该时被拒绝的，需要进行重新操作
  • 基于数据版本字段实现

具体可通过给表加一个版本号或时间戳字段实现，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断当前版本信息与第一次取出来的版本值大小，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，拒绝更新，让用户重新操作。

总结

悲观锁相对比较谨慎，设想现实情况应该很容易就发生冲突，所以我还是独占数据资源吧。    

乐观锁就想得开而且非常聪明，应该是不会有什么冲突的，我对表使用一个时间戳或者版本号，每次读、更新操作都对这个字段进行比对，如果在我之前已经有人对数据进行更新了，那就让它更新，大不了我再读一次或者再更新一次。    

乐观锁的管理跟SVN管理代码版本的原理很像，如果在我提交代码之前用本地代码的版本号与服务器做对比，如果本地版本号小于服务器上最新版本号，则提交失败，产生冲突代码，让用户决定选择哪个版本继续使用。    

在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法        

另外，Mysql在处理并发访问数据上，还有添加读锁（共享锁）、写锁（排它锁），控制锁粒度【表锁（table lock）、行级锁（row lock）】等实现