java乐观锁原理与实现案例分析

本文实例讲述了java乐观锁原理与实现。分享给大家供大家参考,具体如下:

简单说说乐观锁。乐观锁是相对于悲观锁而言。悲观锁认为,这个线程,发生并发的可能性极大,线程冲突几率大,比较悲观。一般用synchronized实现,保证每次操作数据不会冲突。乐观锁认为,线程冲突可能性小,比较乐观,直接去操作数据,如果发现数据已经被更改(通过版本号控制),则不更新数据,再次去重复 所需操作,知道没有冲突(使用递归算法)。

因为乐观锁使用递归+版本号控制  实现,所以,如果线程冲突几率大,使用乐观锁会重复很多次操作(包括查询数据库),尤其是递归部分逻辑复杂,耗时和耗性能,是低效不合适的,应考虑使用悲观锁。

乐观锁悲观锁的选择:

  • 乐观锁:并发冲突几率小,对应模块递归操作简单    时使用
  • 悲观锁:并发几率大,对应模块操作复杂 时使用

下面给出一个乐观锁实例:

/**
 * 自动派单
 * 只查出一条  返回list只是为了和查询接口统一
 * 视频审核订单不派送
 * @param paramMap
 * @return
 */
public List<AutomaticAssignDto> automaticAssign(Map<String, Object> 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<AutomaticAssignDto> 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 id="bindAutomaticAssignInfo" parameterType="com.star.manager.dto.apply.AutomaticAssignDto">
  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}
</update>

简要说明:表设计时,需要往表里加一个version字段。每次查询时,查出带有version的数据记录,更新数据时,判断数据库里对应id的记录的version是否和查出的version相同。若相同,则更新数据并把版本号+1;若不同,则说明,该数据发送并发,被别的线程使用了,进行递归操作,再次执行递归方法,知道成功更新数据为止。

上述automaticAssign方法即实现了一个乐观锁,作用是冲数据库里更新一条数据病返回前端。如果并发率大,一次请求可能则会重复执行很多次automaticAssign,则性能低。如果并发很乐观,用户请求少,则不需要用synchronized,多线程时性能高。

在此只是简单说说,详细概念等需另行查阅相关资料。

更多java相关内容感兴趣的读者可查看本站专题:《Java面向对象程序设计入门与进阶教程》、《Java数据结构与算法教程》、《Java操作DOM节点技巧总结》、《Java文件与目录操作技巧汇总》和《Java缓存操作技巧汇总》

希望本文所述对大家java程序设计有所帮助。

(0)

相关推荐

  • Java防锁屏小程序代码实例

    为防止系统桌面自动锁屏,只需打成jar包,写个批处理程序start.bat,双击执行保持dos窗口执行即可,无其他影响. 程序设计为每30秒动一次鼠标,可根据需要调整. 附代码: package main; import java.awt.AWTException; import java.awt.Dimension; import java.awt.MouseInfo; import java.awt.Point; import java.awt.PointerInfo; import jav

  • Java模拟死锁发生之演绎哲学家进餐问题案例详解

    本文实例讲述了Java模拟死锁发生之演绎哲学家进餐问题.分享给大家供大家参考,具体如下: 一 点睛 常见的死锁形式:当线程1已经占据资源R1,并持有资源R1上的锁,而且还在等待资源R2的锁:而线程2已经占据资源R2,并且持有资源R2上的锁,却正在等待资源R1上的锁.如果两个线程不释放自己占据的资源锁,而且还申请对方资源上的锁,申请不到时只能等待,而且它们只能永远的等待下去. 二 实战 1 代码 public class DeadLockDemo { /** knife锁 */ private s

  • 使用JAVA实现高并发无锁数据库操作步骤分享

    1. 并发中如何无锁.一个很简单的思路,把并发转化成为单线程.Java的Disruptor就是一个很好的例子.如果用java的concurrentCollection类去做,原理就是启动一个线程,跑一个Queue,并发的时候,任务压入Queue,线程轮训读取这个Queue,然后一个个顺序执行. 在这个设计模式下,任何并发都会变成了单线程操作,而且速度非常快.现在的node.js, 或者比较普通的ARPG服务端都是这个设计,"大循环"架构.这样,我们原来的系统就有了2个环境:并发环境 +

  • Java 多线程死锁的产生以及如何避免死锁

    一.死锁的定义 多线程以及多进程改善了系统资源的利用率并提高了系统 的处理能力.然而,并发执行也带来了新的问题--死锁.所谓死锁是指多个线程因竞争资源而造成的一种僵局(互相等待),若无外力作用,这些进程都将无法向前推进. 下面我们通过一些实例来说明死锁现象. 先看生活中的一个实例,2个人一起吃饭但是只有一双筷子,2人轮流吃(同时拥有2只筷子才能吃).某一个时候,一个拿了左筷子,一人拿了右筷子,2个人都同时占用一个资源,等待另一个资源,这个时候甲在等待乙吃完并释放它占有的筷子,同理,乙也在等待甲吃

  • Java 多线程同步 锁机制与synchronized深入解析

    打个比方:一个object就像一个大房子,大门永远打开.房子里有很多房间(也就是方法).这些房间有上锁的(synchronized方法), 和不上锁之分(普通方法).房门口放着一把钥匙(key),这把钥匙可以打开所有上锁的房间.另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人.所有的东西就这么多了,下面我们看看这些东西之间如何作用的. 在此我们先来明确一下我们的前提条件.该对象至少有一个synchronized方法,否则这个key还有啥意义.当然也就不会有我们的这个主题了. 一

  • Java锁之自旋锁详解

    锁作为并发共享数据,保证一致性的工具,在JAVA平台有多种实现(如 synchronized 和 ReentrantLock等等 ) .这些已经写好提供的锁为我们开发提供了便利,但是锁的具体性质以及类型却很少被提及.本系列文章将分析JAVA下常见的锁名称以及特性,为大家答疑解惑. 1.自旋锁 自旋锁是采用让当前线程不停地的在循环体内执行实现的,当循环的条件被其他线程改变时 才能进入临界区.如下 复制代码 代码如下: public class SpinLock { private AtomicRe

  • Java多线程之死锁的出现和解决方法

    什么是死锁? 死锁是这样一种情形:多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放.由于线程被无限期地阻塞,因此程序不能正常运行.形象的说就是:一个宝藏需要两把钥匙来打开,同时间正好来了两个人,他们一人一把钥匙,但是双方都再等着对方能交出钥匙来打开宝藏,谁都没释放自己的那把钥匙.就这样这俩人一直僵持下去,直到开发人员发现这个局面. 导致死锁的根源在于不适当地运用"synchronized"关键词来管理线程对特定对象的访问."synchronized"关

  • Java并发问题之乐观锁与悲观锁

    首先介绍一些乐观锁与悲观锁: 悲观锁:总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁.再比如Java里面的同步原语synchronized关键字的实现也是悲观锁. 乐观锁:顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版

  • Java多线程 ReentrantLock互斥锁详解

    加锁和解锁 我们来看下ReentrantLock的基本用法 ThreadDomain35类 public class ThreadDomain35 { private Lock lock = new ReentrantLock(); public void testMethod() { try { lock.lock(); for (int i = 0; i < 2; i++) { System.out.println("ThreadName = " + Thread.curre

  • redis中使用java脚本实现分布式锁

    redis被大量用在分布式的环境中,自然而然分布式环境下的锁如何解决,立马成为一个问题.例如我们当前的手游项目,服务器端是按业务模块划分服务器的,有应用服,战斗服等,但是这两个vm都有可能同时改变玩家的属性,这如果在同一个vm下面,就很容易加锁,但如果在分布式环境下就没那么容易了,当然利用redis现有的功能也有解决办法,比如redis的脚本. redis在2.6以后的版本中增加了Lua脚本的功能,可以通过eval命令,直接在RedisServer环境中执行Lua脚本,并且可以在Lua脚本中调用

随机推荐