MYSQL--悲观锁与乐观锁

已于 2022-02-09 11:17:51 修改
阅读量1.5k 收藏 1
点赞数
分类专栏： 数据库 文章标签： java 开发语言 后端
于 2017-09-18 11:22:17 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/BtWangZhi/article/details/78017253
版权

1 悲观锁，排他锁，当数据上锁以后，其他线程不能去操作该数据，只能等待占用线程尽快结束占用。这种方法并发效率低。
测试代码：

@Autowired
    private DataSourceTransactionManager txManager;
    /**
     * 悲观锁
     */
    @Test
    public void testPessimisticLock(){
        //创建固定线程数为6的线程池
        ExecutorService executorService = Executors.newFixedThreadPool(6);
        executorService.submit(()->{
            DefaultTransactionDefinition def = new DefaultTransactionDefinition();
            // 事物隔离级别，开启新事务
            def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
            // 获得事务状态
            TransactionStatus status = txManager.getTransaction(def);
            logger.info("锁住id为1的用户信息");
            userDao.selectUserInfoAndLock(1);
            logger.info("开始睡眠");
            try {
                TimeUnit.SECONDS.sleep(30);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            txManager.commit(status);
            logger.info("睡眠结束,即提交请求，锁释放");
        });
        executorService.submit(()->{
            try {
                TimeUnit.SECONDS.sleep(2);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            logger.info("开始修改数据数据");
            User updateUser=new User();
            updateUser.setId(1);
            updateUser.setName("456");
            userDao.updateByPrimaryKeySelective(updateUser);
            logger.info("结束修改数据");
        });
        executorService.shutdown();
        while(true){
            if(executorService.isTerminated()){
                break;
            }
        }
        logger.info("测试完成");
    }

锁住的SQL

  <select id="selectUserInfoAndLock" parameterType="java.lang.Integer"
          resultType="com.test.model.User">
    select
    <include refid="Base_Column_List" />
    from user
    WHERE 1=1
    AND id=#{id}
    FOR UPDATE
  </select>

执行结果：

2019-06-21 18:15:42.502  INFO 18368 --- [pool-2-thread-1] com.test.service.UserServiceTest         : 锁住id为1的用户信息
2019-06-21 18:15:42.523 DEBUG 18368 --- [pool-2-thread-1] c.t.dao.UserDao.selectUserInfoAndLock    : ==>  Preparing: select id, uuid, `name`, `password` from user WHERE 1=1 AND id=? FOR UPDATE 
2019-06-21 18:15:42.637 DEBUG 18368 --- [pool-2-thread-1] c.t.dao.UserDao.selectUserInfoAndLock    : ==> Parameters: 1(Integer)
2019-06-21 18:15:42.647 DEBUG 18368 --- [pool-2-thread-1] c.t.dao.UserDao.selectUserInfoAndLock    : <==      Total: 1
2019-06-21 18:15:42.647  INFO 18368 --- [pool-2-thread-1] com.test.service.UserServiceTest         : 开始睡眠
2019-06-21 18:15:44.062  INFO 18368 --- [pool-2-thread-2] com.test.service.UserServiceTest         : 开始修改数据数据
2019-06-21 18:15:44.104 DEBUG 18368 --- [pool-2-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==>  Preparing: update `user` SET `name` = ? where id = ? 
2019-06-21 18:15:44.105 DEBUG 18368 --- [pool-2-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==> Parameters: 456(String), 1(Integer)
2019-06-21 18:16:12.648  INFO 18368 --- [pool-2-thread-1] com.test.service.UserServiceTest         : 睡眠结束,即提交请求，锁释放
2019-06-21 18:16:12.673 DEBUG 18368 --- [pool-2-thread-2] c.t.d.U.updateByPrimaryKeySelective      : <==    Updates: 1
2019-06-21 18:16:12.674  INFO 18368 --- [pool-2-thread-2] com.test.service.UserServiceTest         : 结束修改数据
2019-06-21 18:16:12.682  INFO 18368 --- [           main] com.test.service.UserServiceTest         : 测试完成

锁住的线程不添加，导致正常的修改无法执行，陷入阻塞，干扰线程执行完成，锁释放，正常的修改线程可以修改数据库信息，

扣减库存的场景

    /**
     * 悲观锁
     *
     * @param goodsId
     * @param num
     */
    @Override
    @Transactional(rollbackFor = Exception.class)
    public void buy2(int goodsId, int num) {
        //判断库存
        GoodsDO goodsDO = goodsMapper.selectByPrimaryKeyLock(goodsId);
        if (goodsDO.getStock() <= 0) {
            logger.info("已经售完,id{}", goodsId);
            return;
        }

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        //减库存
        int newStock = goodsDO.getStock() - num;
        int result = goodsMapper.updateStockById(goodsId, newStock);
        if (result > 0) {
            //提加订单
            OrderDO orderDO = new OrderDO();
            orderDO.setName(goodsDO.getName());
            orderDO.setNum(num);
            orderMapper.insertSelective(orderDO);

            logger.info("购买成功,id{}", goodsId);
        } else {
            logger.info("购买失败");
        }
    }

上锁sql

    <!-- 上锁-->
    <select id="selectByPrimaryKeyLock" parameterType="java.lang.Integer" resultMap="BaseResultMap">
        select
        <include refid="Base_Column_List" />
        from t_goods
        where id = #{id,jdbcType=INTEGER}
        for update
    </select>

更新库存

    <update id="updateStockById">
        UPDATE t_goods
        SET stock=#{newStock}
        WHERE id=#{id}
    </update>

2 乐观锁，安全性比悲观锁低，并发效率高。读的时候多的情况应该使用乐观锁。

/**
     * 乐观锁
     */
    @Test
    public void testOptimisticLock(){
        executorService.submit(()->{
            int count=0;
            while(count<10){
                count++;
                logger.info("正常线程，开始第{}次尝试修改数据",count);
                User user = userDao.selectByPrimaryKey(1);
                //模拟耗时操作
                logger.info("正常线程，开始睡眠");
                try {
                    TimeUnit.SECONDS.sleep(5);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                logger.info("正常线程，睡眠结束");
                User updateUser=new User();
                updateUser.setId(user.getId());
                updateUser.setName("456");
                logger.info("正常线程，开始尝试修改name字段");
                if(userDao.updateUserByIdAndUuid(updateUser,user.getUuid())==1){
                    logger.info("正常线程，尝试修改name字段成功--------------");
                    break;
                }else{
                    logger.info("正常线程，尝试修改name字段失败------------------");
                }
            }
        });

        executorService.submit(()->{
            int count=0;
            while(count<3){
                count++;

                User user=new User();
                user.setId(1);
                String uuid = UUID.randomUUID().toString().replaceAll("-", "");
                user.setUuid(uuid);
                logger.info("当前为搞破坏线程，第{}次修改UUID",count);
                userDao.updateByPrimaryKeySelective(user);
                try {
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            logger.info("当前为搞破坏线程，不再修改UUID");
        });
        executorService.shutdown();
        while(true){
            if(executorService.isTerminated()){
                break;
            }
        }
        logger.info("测试完成");
    }

一个线程执行修改uuid字段，起到干扰的作用，正常的线程无法修改成功，干扰线程执行完成，正常线程执行完成。
执行结果：

2019-06-21 17:38:45.455  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始第1次尝试修改数据
2019-06-21 17:38:46.083 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : ==>  Preparing: select id, uuid, `name`, `password` from `user` where id = ? 
2019-06-21 17:38:46.102 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : ==> Parameters: 1(Integer)
2019-06-21 17:38:46.110 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : <==      Total: 1
2019-06-21 17:38:46.111  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始睡眠
2019-06-21 17:38:46.163  INFO 10456 --- [pool-1-thread-2] com.test.service.UserServiceTest         : 当前为搞破坏线程，第1次修改UUID
2019-06-21 17:38:46.196 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==>  Preparing: update `user` SET uuid = ? where id = ? 
2019-06-21 17:38:46.197 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==> Parameters: 1517bfcc69d2424683f8df72e47fa073(String), 1(Integer)
2019-06-21 17:38:46.228 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : <==    Updates: 1
2019-06-21 17:38:48.228  INFO 10456 --- [pool-1-thread-2] com.test.service.UserServiceTest         : 当前为搞破坏线程，第2次修改UUID
2019-06-21 17:38:48.228 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==>  Preparing: update `user` SET uuid = ? where id = ? 
2019-06-21 17:38:48.229 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==> Parameters: 22a5ca2858a54519ab269de3b0c55006(String), 1(Integer)
2019-06-21 17:38:48.278 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : <==    Updates: 1
2019-06-21 17:38:50.279  INFO 10456 --- [pool-1-thread-2] com.test.service.UserServiceTest         : 当前为搞破坏线程，第3次修改UUID
2019-06-21 17:38:50.280 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==>  Preparing: update `user` SET uuid = ? where id = ? 
2019-06-21 17:38:50.280 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : ==> Parameters: 305369d203324cf699f630596b494687(String), 1(Integer)
2019-06-21 17:38:50.339 DEBUG 10456 --- [pool-1-thread-2] c.t.d.U.updateByPrimaryKeySelective      : <==    Updates: 1
2019-06-21 17:38:51.112  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，睡眠结束
2019-06-21 17:38:51.112  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始尝试修改name字段
2019-06-21 17:38:51.118 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : ==>  Preparing: update `user` SET `name` = ? where 1=1 AND id = ? AND uuid=? 
2019-06-21 17:38:51.124 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : ==> Parameters: 456(String), 1(Integer), 5ca0168bfd8d470190c262584732d8d0(String)
2019-06-21 17:38:51.125 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : <==    Updates: 0
2019-06-21 17:38:51.125  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，尝试修改name字段失败------------------
2019-06-21 17:38:51.125  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始第2次尝试修改数据
2019-06-21 17:38:51.125 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : ==>  Preparing: select id, uuid, `name`, `password` from `user` where id = ? 
2019-06-21 17:38:51.125 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : ==> Parameters: 1(Integer)
2019-06-21 17:38:51.126 DEBUG 10456 --- [pool-1-thread-1] com.test.dao.UserDao.selectByPrimaryKey  : <==      Total: 1
2019-06-21 17:38:51.127  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始睡眠
2019-06-21 17:38:52.339  INFO 10456 --- [pool-1-thread-2] com.test.service.UserServiceTest         : 当前为搞破坏线程，不再修改UUID
2019-06-21 17:38:56.128  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，睡眠结束
2019-06-21 17:38:56.128  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，开始尝试修改name字段
2019-06-21 17:38:56.129 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : ==>  Preparing: update `user` SET `name` = ? where 1=1 AND id = ? AND uuid=? 
2019-06-21 17:38:56.129 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : ==> Parameters: 456(String), 1(Integer), 305369d203324cf699f630596b494687(String)
2019-06-21 17:38:56.223 DEBUG 10456 --- [pool-1-thread-1] c.t.dao.UserDao.updateUserByIdAndUuid    : <==    Updates: 1
2019-06-21 17:38:56.223  INFO 10456 --- [pool-1-thread-1] com.test.service.UserServiceTest         : 正常线程，尝试修改name字段成功--------------
2019-06-21 17:38:56.224  INFO 10456 --- [           main] com.test.service.UserServiceTest         : 测试完成

扣减库存场景-外层加重试机制

    /**
     * 乐观锁
     *
     * @param goodsId
     * @param num
     * @throws Exception
     */
    @Override
    @Transactional(rollbackFor = Exception.class)
    public void buy3(int goodsId, int num) throws Exception {
        logger.info("----------------------开始测试---------------------------");
        //判断库存
        GoodsDO goodsDO = goodsMapper.selectByPrimaryKey(goodsId);
        if (goodsDO.getStock() <= 0) {
            logger.info("已经售完,id{}", goodsId);
            return;
        }

        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        //减库存
        int newStock = goodsDO.getStock() - num;
        int result = goodsMapper.updateStockByIdAndVersion(goodsId, newStock, goodsDO.getVersion(), UUIDUtils.getUUID());
        if (result > 0) {
            //提加订单
            OrderDO orderDO = new OrderDO();
            orderDO.setName(goodsDO.getName());
            orderDO.setNum(num);
            orderMapper.insertSelective(orderDO);

            logger.info("购买成功,id{}", goodsId);
        } else {
            logger.info("购买失败");
            throw new Exception("购买失败");
        }
    }

加版本号更新

    <update id="updateStockByIdAndVersion">
        UPDATE t_goods
        SET stock=#{newStock},
        version=#{newVersion}
        WHERE id=#{id}
        AND version=#{oldVersion}
    </update>

扣减库存当前读更新

    /**
     * mysql当前读
     *
     * @param goodsId
     * @param num
     */
    @Override
    @Transactional(rollbackFor = Exception.class)
    public void buy1(int goodsId, int num) {
        //判断库存
        GoodsDO goodsDO = goodsMapper.selectByPrimaryKey(goodsId);
        if (goodsDO.getStock() <= 0) {
            logger.info("已经售完,id{}", goodsId);
            return;
        }

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        //减库存
        int result = goodsMapper.reduceStockById(goodsId, num);
        if (result > 0) {
            //提加订单
            OrderDO orderDO = new OrderDO();
            orderDO.setName(goodsDO.getName());
            orderDO.setNum(num);
            orderMapper.insertSelective(orderDO);

            logger.info("购买成功,id{}", goodsId);
        } else {
            logger.info("购买失败");
        }
    }

更新，sql中对库存判断

    <update id="reduceStockById">
        UPDATE t_goods
        SET stock=stock-#{num}
        WHERE id=#{id}
        AND stock>=#{num}
    </update>

参考：https://mp.weixin.qq.com/s/ZJdfthAg2tImArzJO7bPaQ

BtWangZhi
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
mysql 悲观锁与乐观锁的理解及应用分析
09-08
在MySQL中，乐观锁通常通过版本号或时间戳来实现，每次更新数据时都会检查当前版本号或时间戳是否与读取时一致。 例如，我们可以为商品库存表添加一个`version`字段，每次更新时增加版本号： 1. 读取数据并记录...
实例讲解MySQL中乐观锁和悲观锁
09-09
在数据库管理中，为了保证数据的一致性和完整性，尤其是在并发环境下，乐观锁和悲观锁是两种常见的并发控制技术。这两种锁机制在MySQL中扮演着重要的角色，帮助事务处理潜在的数据冲突。 **悲观锁（Pessimistic ...
MySQL中的悲观锁与乐观锁
09-14
主要介绍了MySQL中悲观锁与乐观锁的相关资料，帮助大家更好的理解和学习MySQL数据库，感兴趣的朋友可以了解下
面试必备之乐观锁与悲观锁
凡是过往，皆为序章
07-03 1274
目录 何谓悲观锁与乐观锁 悲观锁 乐观锁 两种锁的使用场景 乐观锁常见的两种实现方式 1. 版本号机制 2. CAS算法 乐观锁的缺点 1 ABA 问题 2 循环时间长开销大 3 只能保证一个共享变量的原子操作 CAS与synchronized的使用情景 何谓悲观锁与乐观锁 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏...
【SQL】MySQL 的乐观锁和悲观锁
最新发布
hui_zai_的博客
07-12 1020
MySQL 的乐观锁和悲观锁
对mysql乐观锁、悲观锁、共享锁、排它锁、行锁、表锁的理解
qq_37149892的博客
09-10 170
记得在上大学那会开始，在大学的课堂上，常常会听到老师讲什么共享锁，排它锁各种锁的词汇，以前仅仅听过一次就没有管了，并没有进行深入的研究 最近，在各种群里，又看见了什么乐观锁、悲观锁什么鬼的感觉很高级的词汇，于是乎今天对这几个概念进行学习，揭开它神秘的面纱，缕缕思路记录下我对这几个概念的想法 实验环境： mysql5.6 存储引擎：innoDB 我们在操作数据库的时候，可能会由于并发问...
MySql悲观锁（行锁）和乐观锁
热门推荐
Java后端技术栈
10-19 2万+
一、悲观锁VS乐观锁 引言 为什么需要锁（并发控制） 在并发的环境中，会存在多个用户同时更新同一条数据，这时就会产生冲突。 冲突结果： 丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。 脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。 因此为了解决上述问题，引入了并发控制机制。 乐观锁(乐观并发控制)和悲观锁(悲观并发控制)是并发控制的主要手段，其实不仅关系型数据库中有乐观锁和悲观锁的概念，像redis，memcached等都有类似的概念。所以，不要把乐观.
【数据库】mysql：悲观锁与乐观锁
流星007
01-10 485
为什么会使用到数据库级别的锁？ 你可能会有这么一个疑问：现在的程序已经提供了很完善的锁机制来保证多线程的安全问题，还需要用到数据库级别的锁吗？我觉得还是需要的，为什么呢？理由很简单，我们再编程中使用的大部分锁都是单机，尤其是现在分布式集群的流行，这种单机的锁机制就保证不了线程安全了，这个时候，你可能又会想到使用redis的setNX分布式锁或者zookeeper的强一致性来保证线程安全，但是这里...
【MySql】悲观锁和乐观锁的介绍
yuxiangdeming的博客
11-28 775
当程序中可能出现并发的情况时，就需要保证在并发情况下数据的准确性，以此确保当前用户和其他用户一起操作时，所得到的结果和他单独操作时的结果是一样的。这就叫做并发控制。并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。实现并发控制的主要手段分为乐观并发控制和悲观并发控制两种。无论是悲观锁还是乐观锁，都是人们定义出来的概念，可以认为是一种思想。乐观锁比较适用于读多写少的情况（多读场景），悲观锁比较适用于写多读少的情况（多写场景）。
数据库乐观锁
hwsdau的专栏
08-08 822
乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于读多写少的应用场景，这样可以提高吞吐量。 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。 作者：FX_SKY 链接：http://www.jianshu.com/p/f
mysql乐观锁和悲观锁详解
zhangyoo
12-27 1万+
相信很多朋友在面试的时候，都会被问到乐观锁和悲观锁的问题，如果不清楚其概念和用法的情况下，相信很多朋友都会感觉很懵逼，那么面试的结果也就不言而喻了。 那么乐观锁和悲观锁到底是个什么东西，用它能来做什么呢？ 相信大家都遇到这种场景，当很多人（一两个人估计不行）同时对同一条数据做修改的时候，那么数据的最终结果是怎样的呢？ 这也就是我们说的并发情况，这样会导致以下两种结果： 更新错误，你修改之后的数据...
36谈谈MySQL支持的事务隔离级别，以及悲观锁和乐观锁的原理和应用场景？
11-25
36谈谈MySQL支持的事务隔离级别，以及悲观锁和乐观锁的原理和应用场景？
java 乐观锁与悲观锁
Technology Share
07-22 1212
悲观锁，就是不管是否发生多线程冲突，只要存在这种可能，就每次访问都加锁。 乐观锁，就是通过标记值控制，每次操作前通过标记值判断是否是最新内容，最新内容就可以操作，不是最新的就继续循环判断标记值，直到是最新类容。 在大量冲突发生时，悲观锁的锁消耗大，乐观锁的读取次数会多。
【MySQL】悲观锁与乐观锁
记录学习的点滴
04-30 1141
悲观锁和乐观锁 1、什么是悲观锁？ 悲观锁是基于一种悲观的态度来防止一切数据冲突，以一种预防的姿态在修改数据之前把数据锁住； 然后再对数据进行读写，在它释放锁之前任何人都不能对其数据进行操作 直到前面一个人把锁释放后下一个人数据加锁才可对数据进行加锁，然后才可以对数据进行操作，一般数据库本身锁的机制都是基于悲观锁的机制实现的; 悲观锁更适用于多写少读的情况。 特点： 可以完全保证数据的独占性和正确性，因为每次请求都会先对数据进行加锁， 然后进行数据操作，最后再解锁，而加锁释放锁的过程会造成消耗，所以性能不高
mysql 乐观锁和悲观锁
z_ssyy的博客
01-05 7829
2.乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳 （timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。但是如果发生有不同的业务操作对同一版本的数据进行修 改，那么，先提交的操作（图中B）会把数据version更新为2，当A在B之后提交更新时发现数据的version已经被修改了，那么A的更新操作会失 败。
Mysql里的锁（一）：悲观锁、乐观锁
weixin_40482816的博客
02-26 731
顾名思义，悲观锁是基于一种悲观的态度类来防止一切数据冲突，它是以一种预防的姿态在修改数据之前把数据锁住，然后再对数据进行读写，在它释放锁之前任何人都不能对其数据进行操作，直到前面一个人把锁释放后，下一个人才可对数据进行加锁，然后才可以对数据进行操作，一般。乐观锁是对于数据冲突保持一种乐观态度，操作数据时不会对操作的数据进行加锁（这使得多个任务可以并行的对数据进行操作），只有到数据提交的时候才通过一种机制来验证数据是否存在冲突(一般实现方式是。数据库本身锁的机制都是基于悲观锁的机制实现的;
随笔感悟：Mysql悲观锁和乐观锁
weixin_57128596的博客
09-12 1200
首先是场景：并发控制为了并发情况下，线程跟自己在单机情况一样得到相同的结果，保证数据的一致性；脏读、不可重复读、幻读乐观锁适合并发量比较小的场景（读多写少），悲观锁适合并发量比较大的场景（写多多少）；悲观锁在并发时保证线程和单机时结果一样（宏观）；当在数据库中修改某条数据时，防止同时被其他人进行修改从而造成数据不一致（微观）；有点像警察处理凶杀现场，对凶杀现场（资源对象）进行上锁，防止其他人对其现场进行修改；具有强烈的独占和排他特性。它指的是对。
mysql乐观锁总结和实践
chenzhou123520的专栏
05-08 1944
上一篇文章《MySQL悲观锁总结和实践》谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受。所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍： ...
简单理解mysql悲观锁和乐观锁
分享传递价值
04-18 831
mysql层的锁机制，常用的就是乐观锁，用于判断并发修改问题，常在update语句中体现。 乐观锁 mysql的乐观锁通俗点理解就是在查询时取出数据的唯一标识，在修改操作时用这个唯一标识去判断该数据有没有被其他人修改过。常见的我们会在表设计时候冗余一个version字段，表示版本号的概念，在select时把这个字段也一并查询出来，update时的where条件加上这个version判断。例如在...
MySQL乐观锁与悲观锁详解
"MySQL的乐观锁和悲观锁是数据库并发控制中的两种重要策略。乐观锁不是数据库内置的，需要开发者自己实现，通常通过版本号或时间戳来检查并发更新时的冲突。悲观锁则是在操作数据时预设会有冲突，因此会使用如`for ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值