乐观锁是相对于悲观锁而言。悲观锁认为，这个线程，发生并发的可能性极大，线程冲突几率大，比较悲观。一般用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;
  }
 }

Synchronized显然是一个悲观锁，因为它的并发策略是悲观的：不管是否会产生竞争，任何的数据操作都必须要加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等操作。

随着硬件指令集的发展，我们可以使用基于冲突检测的乐观并发策略。先进行操作，如果没有其他线程征用数据，那操作就成功了；如果共享数据有征用，产生了冲突，那就再进行其他的补偿措施。这种乐观的并发策略的许多实现不需要线程挂起，所以被称为非阻塞同步。

乐观锁的核心算法是CAS（CompareandSwap，比较并交换），它涉及到三个操作数：内存值、预期值、新值。当且仅当预期值和内存值相等时才将内存值修改为新值。这样处理的逻辑是，首先检查某块内存的值是否跟之前我读取时的一样，如不一样则表示期间此内存值已经被别的线程更改过，舍弃本次操作，否则说明期间没有其他线程对此内存值操作，可以把新值设置给此块内存。

CAS具有原子性，它的原子性由CPU硬件指令实现保证，即使用JNI调用Native方法调用由C++编写的硬件级别指令，JDK中提供了Unsafe类执行这些操作。

悲观锁，虽然synchronized包含偏向锁、轻量级锁、重量级锁，但它们都属于悲观锁，这些锁虽然有的用到了cas,但这只是获得锁的方式不一样。

悲观锁与乐观锁的区别在于是否锁定资源，乐观锁通过cas,版本号的方式替代直接锁定资源的方式，并不是严格意义的锁。

使用版本标识来确定读到的数据与提交时的数据是否一致，提交后修改版本标识，不一致时可以采取丢弃和再次尝试的策略。

java 中的 Compare and Swap 即 CAS ,当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其他线程都失败，失败的线程并不会挂起，而被告知这次的竞争你这次失败了，并可以再次尝试。CAS 操作中包含三个操作数 —— 需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置 V 的值与预期的原值 A 相匹配，那么处理器会自动将该位置值更新为新值 B 。否则，处理器啥也不干，不做任何操作。

Synchronized是悲观锁机制，独占锁。

悲观锁，锁如其名，他对世界是悲观的，他认为别人访问正在改变的数据的概率是很高的，所以从数据开始更改时就将数据锁住，知道更改完成才释放。

乐观锁，他对世界比较乐观，认为别人访问正在改变的数据的概率是很低的，所以直到修改完成准备提交所做的的修改到数据库的时候才会将数据锁住。完成更改后释放。

悲观锁会造成访问数据库时间较长，并发性不好，特别是长事务。乐观锁在现实中使用得较多，厂商较多采用。

乐观锁实现原理：在高并发下，经常需要处理SELECT之后，在业务层处理逻辑，再执行UPDATE的情况。若两个连接并发查询同一条数据，然后在执行一些逻辑判断或业务操作后，执行UPDATE，可能出现与预期不相符的结果。在不使用悲观锁与复杂SQL的前提下，可以使用乐观锁处理该问题，同时兼顾性能。