网络上看到的一个情景展示：

银行两操作员同时操作同一账户就是典型的例子。

比如A、B操作员同时读取一余额为1000元的账户，A操作员为该账户增加100元，B操作员同时为该账户扣除50元，A先提交，B后提交。最后实际账户余额为1000-50=950元，但本该为1000+100-50=1050。这就是典型的并发问题。

乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本(Version)记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段(balance)为1000元。假设操作员A先更新完，操作员B后更新。

a、操作员A此时将其读出(version=1)，并从其帐户余额中增加100(1000+100=1100)。

b、在操作员A操作的过程中，操作员B也读入此用户信息(version=1)，并从其帐户余额中扣除50(1000-50=950)。

c、操作员A完成了修改工作，将数据版本号加一(version=2)，连同帐户增加后余额(balance=1100)，提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。

d、操作员B完成了操作，也将版本号加一(version=2)试图向数据库提交数据(balance=950)，但此时比对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满足 “提交版本必须大于记录当前版本才能执行更新 “的乐观锁策略，因此，操作员B的提交被驳回。

这样，就避免了操作员B用基于version=1的旧数据修改的结果覆盖操作员A的操作结果的可能。

实现：

数据层使用的是mybatis ， 并且集成了mybatis generator，这里的乐观锁实现用到了一个第三方插件：

com.chrhc.mybatis.locker.interceptor.OptimisticLocker

1. 使用方式：在mybatis配置文件中加入如下配置，就完成了。

 <plugins>    
     <plugin interceptor="com.chrhc.mybatis.locker.interceptor.OptimisticLocker"/> 
 </plugins>

2. 对插件配置的说明： 上面对插件的配置默认数据库的乐观锁列对应的Java属性为version。这里可以自定义属性名，例如：

 <plugins>     
  <plugin interceptor="com.chrhc.mybatis.locker.interceptor.OptimisticLocker">         
    <property name="versionColumn" value="xxx"/><!--数据库的列名-->         
    <property name="versionField" value="xxx"/> <!--java字段名-->     
  </plugin> 
</plugins> 

3. 效果：

之前：

update user set name = ?, password = ? where id = ? 

之后：

update user set name = ?, password = ?, version = version+1 where id = ? and version = ? 

4. 对version的值的说明：

     1、当PreparedStatement获取到version值之后，插件内部会自动自增1。

     2、乐观锁的整个控制过程对用户而言是透明的，这和Hibernate的乐观锁很相似，用户不需要关心乐观锁的值。

5.插件原理描述： 插件通过拦截mybatis执行的update语句，在原有sql语句基础之上增加乐观锁标记。

    比如，原始sql为： update user set name = ?, password = ? where id = ?， 那么用户不需要修改sql语句，在插件的帮助之下，会自动将上面的sql语句改写成为： update user set name = ?, password = ?, version = version + 1 where id = ? and version = ?， 形式，用户也不用关心version前后值的问题，所有的动作对用户来说是透明的，由插件自己完成这些功能。

6.默认约定：

    1、插件拦截的update语句的Statement都是PreparedStatement，仅针对这种方式的sql有效；

    2、mapper.xml的<update>标签必须要与接口Mapper的方法对应上，也就是使用mybatis推荐的方式，但是多个接口可以对应一个mapper.xml的<update>标签；

    3、本插件不会对sql的结果做任何操作，sql本身应该返回什么就是什么；

    4、插件默认拦截所有update语句，如果用户对某个update不希望有乐观锁控制，那么在对应的mapper接口方法上面增加@VersionLocker(false)或者@VersionLocker(value = false),这样插件就不会对这个update做任何操作，等同于没有本插件；

     5、本插件目前暂时不支持批量更新的乐观锁，原因是由于批量更新在实际开发中应用场景不多，另外批量更新乐观锁开发难度比较大；

    6、Mapper接口的参数类型必须和传入的实际类型保持一致，这是由于在JDK版本在JDK8以下没有任何方法能获取接口的参数列表名称，因此，插件内部是使用参数类型和参数作为映射来匹配方法签名的；

7、插件github地址：