背景
乐观锁普通用在OLTP系统中就解决高并发问题，乐观锁如果用的不好出现错位的时候，定位时间一般都比较久（通常你要你列出所有更新线程进行分析）。
这篇文章进行如下阐述：
1.对乐观锁的概念进行大致阐述。
2.乐观锁在实践中的已经用
3.乐观锁使用规范
什么是乐观锁
悲观锁和乐观锁，其概念名称来自于其数据被外界改变所抱有的代码。
悲观锁对外部系统的改变抱有保守的态度及不允许外界修改我刚读取的数据，在整个数据处理过程中数据处于锁定的状态。
而乐观锁是觉得数据被外界改变是一个无所谓的心态。
悲观锁一般是通过数据库的 select * from table where id = '$(id)' for update /或者for update nowait来实现，hibernate 可以在应用层使用悲观锁但是你如果查看其运行时SQL语句，它也是通过for update来实现的。
现在我们进行具体的场景分析，假设有数据data1, 线程1:thread1,线程2：thread2，乐观锁其具体场景如下：
当thread1查询到data1的时候并不占为己有，thread1不担心或者不care这条数据是否被别的线程修改，只有thread1需要操作data1的时候才去锁住data1且更新。
其具体伪代码如下：
语句Q：Object data1 = dao.queryById;
...done something...// 这里一定不要做更新data1的操作
语句U：dao.update(data1) // 更新语句的SQL一般是这样写的，update dataTable set amount = newAmount version = version+1 where version = $(version) and id = $(id)
实际线上可能出现以下的执行序列：
thread1: 语句Q
thread2：语句Q
thread1：语句U
thread2：语句U //
在这样场景下，“thread2：语句U”执行会失败，且语句Q与语句U之间执行时间越短（性能提升），乐观锁冲突的几率越小。
乐观锁在实践中的应用
当使用乐观锁时单个线程不会独占数据资源（真正更新时才锁），这样整个系统并发处理效率就提升了。
下面对一次更新场景和多次更新场景进行分别阐述：
a).同业务类型的意思是更新表的操作都是同类型的业务，比如金融系统中前台通知和后台通知，通知可能调用多次但是只要有一次调用成功把订单状态更新成功就可以了。
b).不同业务类型场景来说，业务1和业务1都需要更新record，如果两个都更新成功最好。如果出现其中一个业务失败，那么需要额外的不就措施，比如重试或者把失败的存下来通过定时任务来执行。
不同业务类型场景
我们在实际中应该根据具体的场景来合理的使用乐观锁，比如在金融系统中，由于网络的不确定性银行/支付宝/微信有时会批量发送一样的后台通知，在此场景下我们如何更新订单状态和金额呢？
我们会进行查询订单和更新订单的动作,
//语句Q1 ：查询 非成功的订单，进行状态更新操作;一下语句Q1是查询动作，语句U1是更新动作
select * from charge where charge_id = ${chargeId} and status=${status}
//语句U1：更新
update charge set status = ${success/failed} ,version= version +1 where charge_id = ${chargeId} and version = ${version}
为什么语句Q1中查询需要带上status=${status}参数呢？请看如下执行序列：
thread1：语句Q1
thread1：语句U1
thread2：语句Q1
thread2：语句U1
如果这两个thread都是由于银行后台通知出发，那么chargeId这条数据会被更新两次，而我们需要的场景是只对 “非最终状态，success/fail”进行更新。
当然你也可以把全部数据查询出来判断状态对不对然后在更新。
同业务类型场景
下面我们谈一谈一次只有一次调用乐观锁更新失败的场景，其场景如下：
table1：有字段amount,status,version字段。
table2：有字段totalAmount,version字段。
如果执行语句1：select * from table1 where id=${id}, update table1 set amount=${amount} , staus=${success} 成功，但是执行语句2 ：select * from table2 where id=${id},update table2 set totalAmount+=${amount} ，version =version+1 where version=${version}失败时如何处理？
我们有以下几个办法：
1.同步重试语句2，但是如果一直失败会导致一直重试。
2.另起一个定时任务，通过一个标识扫描table1未更新到table2的记录，执行定时更新。
3.table2很类似金融系统中的账户表，在金融系统中table2中可能存在热点账户的问题。而热点账户的问题其实就是通过把update语句转换成insert 表中插入到 table2_hotTable表中，把更新都table2/account1变成insert table2_hottable/account1操作，就不会存在行锁锁住table2/account1的问题。
其具体表现如下：
a)table2的数据
account1 50￥ ......
account2 100￥
2).table2_hotTable 的数据
account1 2￥ notCaculated
account1 3￥ notCaculated
account1 5￥ notCaculated
这样当凌晨空闲的时候，我们通过定时任务把table2_hotTable表中的数据修正到table2中。
当然在计算查询account1 账户余额的时候，要把table2和table2_hotTable两个表的数据全部计算进来。
乐观锁的使用规范
上面我们说到在同一个线程中 语句Q和语句U之间不要有其他更新动作，不然会导致version不对更新错误。
对于有version字段的表，我们应该对更新操作规范起来，让其只有一个入口被调用。
乐观锁相对于悲观锁性能提升但是代码上相对维护难度比较大，比较好的办法是把Query和Update操作绑定作为一个整体，或者明显提示后来代码维护者不要再其中间插入其他更新该表的代码。
另外只有一个入口的话，我们可以通过集中的日志查看其version和数据的变化情况。对于开放的设计必须在其他渠道给与监管，在这里想到了共享单车是很开放可以随意停放但是也会造成随意占用公共空间的问题。
乐观锁在其它场景下的应用
乐观锁不仅仅用于用户库中，而且用于缓存、ElasticSearch、JDK集合框架比如LOCK锁的实现。
说在后面的话
讨论技术问题一定是先大体描述其场景，然后对其场景进行分析。当面对含糊的场景时，一定是你偷懒不想一个个场景进行阐述。
多用语言描述写下来，把你的想法写下来。语言不一定能够全部表达你的思维，但是能够反作用你的想法，使你的思维更清晰。
