引言

为什么需要锁（并发控制）？

在多用户环境中，在同一时间可能会有多个用户更新相同的记录，这会产生冲突。这就是著名的并发性问题。

典型的冲突有：

丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：用户A把值从6改为2，用户B把值从2改为6，则用户A丢失了他的更新。

脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：用户A,B看到的值都是6，用户B把值改为2，用户A读到的值仍为6。

为了解决这些并发带来的问题。 我们需要引入并发控制机制。

并发控制机制

悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作。悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的，因此在悲观锁的环境中，在你开始改变此对象之前就将该对象锁住，并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁，加锁的时间可能会很长，这样可能会长时间的锁定一个对象，限制其他用户的访问，也就是说悲观锁的并发访问性不好。

悲观锁大多数情况下依 靠数据库的锁机制实现，以保证操作最大程度的独占性。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。 乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的，因此乐观锁直到你准备提交所作的更改时才将对象锁住，当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短，乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象，那么当他完成了自己的更改进行提交时，数据库就会发现该对象已经变化了，这样，第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中，会增加并发用户读取对象的次数。

乐观锁，大多是基于数据版本 Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于(数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

所谓粒度，即细化的程度。锁的粒度越大，则并发性越低且开销大；锁的粒度越小，则并发性高且开销小。

锁的粒度主要有以下几种类型：

（1）行锁，行锁是粒度中最小的资源。行锁就是指事务在操作数据的过程中，锁定一行或多行的数据，其他事务不能同时处理这些行的数据。行级锁占用的数据资源最小，所以在事务的处理过程中，允许其它事务操作同一表的其他数据。

（2）页锁，一次锁定一页。25个行锁可升级为一个页锁。

（3）表锁，锁定整个表。当整个数据表被锁定后，其他事务就不能够使用此表中的其他数据。使用表锁可以使事务处理的数据量大，并且使用较少的系统资源。但是在使用表锁时，会延迟其他事务的等待时间，降低系统并发性。

（4）数据库锁，防止任何事务和用户对此数据库进行访问。可控制整个数据库的操作。

原文链接：https://www.cnblogs.com/chenwolong/p/Lock.html （这个作者写的很好）

参考：：https://blog.csdn.net/u011421608/article/details/39966727

推荐一个好案例（通用mapper）：https://github.com/abel533/Mapper/wiki/