乐观锁是相对于悲观锁而言。悲观锁认为，这个线程，发生并发的可能性极大，线程冲突几率大，比较悲观。一般用synchronized实现，保证每次操作数据不会冲突。乐观锁认为，线程冲突可能性小，比较乐观，直接去操作数据，如果发现数据已经被更改（通过版本号控制），则不更新数据，再次去重复 所需操作，知道没有冲突（使用递归算法）。
因为乐观锁使用递归+版本号控制 实现，所以，如果线程冲突几率大，使用乐观锁会重复很多次操作（包括查询数据库），尤其是递归部分逻辑复杂，耗时和耗性能，是低效不合适的，应考虑使用悲观锁。
乐观锁悲观锁的选择：
乐观锁：并发冲突几率小，对应模块递归操作简单 时使用 悲观锁：并发几率大，对应模块操作复杂 时使用
下面给出一个乐观锁实例：
/** * 自动派单 * 只查出一条 返回list只是为了和查询接口统一 * 视频审核订单不派送 * @param paramMap * @return */public List automaticAssign(Map paramMap){ //派送规则 String changeSortSet = RedisCacheUtil.getValue(CACHE_TYPE.APP, "changeSortSet"); if (StringUtils.isBlank(changeSortSet)) { changeSortSet = customerManager.getDictionaryByCode("changeSortSet"); if (StringUtils.isNotBlank(changeSortSet)) { RedisCacheUtil.addValue(CACHE_TYPE.APP, "changeSortSet", changeSortSet,30,TimeUnit.DAYS); } else { changeSortSet = ConstantsUtil.AssignRule.FIFO; // 默认先进先审 } } AutomaticAssignDto automaticAssignDto = new AutomaticAssignDto(); automaticAssignDto.setChangeSortSet(changeSortSet); automaticAssignDto.setUserTeam(CommonUtils.getValue(paramMap, "userTeam")); List waitCheckList = automaticAssignMybatisDao.automaticAssignOrder(automaticAssignDto); if(waitCheckList != null && waitCheckList.size()>0){ automaticAssignDto = waitCheckList.get(0); automaticAssignDto.setSendStatus(ConstantsUtil.SendStatus.SEND); automaticAssignDto.setBindTime(new Date()); automaticAssignDto.setUserId(Long.parseLong(paramMap.get("userId").toString()) ); int sum = automaticAssignMybatisDao.bindAutomaticAssignInfo(automaticAssignDto); if(sum == 1){ return waitCheckList; }else{ //已被更新 则再次获取 return automaticAssign(paramMap); } }else{ return null; }}
对应更新的sql：
UPDATE t_automatic_assign SET SEND_STATUS = #{sendStatus} , BIND_TIME = SYSDATE() , LOCKED_FINISHTIME = SYSDATE(), USER_ID = #{userId} , VERSION = VERSION + 1, UPDATE_DATE = SYSDATE() WHERE SLT_ACCOUNT_ID = #{sltAccountId} AND VERSION = #{version}
简要说明:表设计时，需要往表里加一个version字段。每次查询时，查出带有version的数据记录，更新数据时，判断数据库里对应id的记录的version是否和查出的version相同。若相同，则更新数据并把版本号+1；若不同，则说明，该数据发送并发，被别的线程使用了，进行递归操作，再次执行递归方法，知道成功更新数据为止。
