严格锁和乐观锁

2024-06-15 11:28
文章标签 乐观 严格

本文主要是介绍严格锁和乐观锁,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

严格锁和乐观锁

严格锁

含义

  • 当一个开发者正在编辑某个文件时,其他开发者将无法同时对该文件进行编辑。确保在某一时刻只有一个开发者能够访问和修改该文件
  • 严格锁机制通常用于那些需要高度一致性和准确性的场景,例如配置文件、数据库脚本等

示例

假设我在同一段时间内后台只允许一次将数据提交给数据库,那么可以在redis配置一个10秒后自动过期的值,如果请求访问时redis值存在,则返回False并报错状态码,反之存入数据并设置redis锁

乐观锁

含义

  • 严格锁不同,它基于一个假定:大多数时候,并发修改不会引起冲突。因此,它允许多个开发者同时修改同一文件
  • 当一个开发者尝试提交修改时,Git会检查该文件是否自上次获取后已被其他开发者修改。如果该文件在此期间未被其他开发者修改,则提交成功;否则,会提示冲突并需要开发者手动解决

示例

依旧是一个数据库,存储数据时需要提交版本号,每次提交版本号都+1然后返回给前端,如果两个相同版本号的数据同时提交到数据库那么只能有一个提交成功

区别

他和严格锁的区别本身并不在于锁,而是在于上锁的方式,严格锁相当于在那10秒内门都是不会打开的,但是乐观锁只要你携带的参数正确那么就可以开门

这篇关于严格锁和乐观锁的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1063315

相关文章

矩阵中严格递增的单元格数

题目链接:leetcode:矩阵中严格递增的单元格数 描述 给你一个下标从 1 开始、大小为 m x n 的整数矩阵 mat,你可以选择任一单元格作为 起始单元格 。 从起始单元格出发,你可以移动到 同一行或同一列 中的任何其他单元格,但前提是目标单元格的值 严格大于 当前单元格的值。 你可以多次重复这一过程,从一个单元格移动到另一个单元格,直到无法再进行任何移动。 请你找出从某个单元开始访问

【过度的乐观和自信,得治】为什么数据类项目交付失败的不少?

引言:数据类项目包含数据治理和数据分析类项目,这些是数字化转型中数据能力打造,是基础性的工作。这类项目通常涉及Iaas、Paas和Saas层产品和服务,越靠近业务客户的Saas层交付服务客户满意度低,项目失败的不少,付款和后续二期项目将更难。于是一些产品公司,参考之前失败的经验,于是改变策略,更倾向于卖产品,然后将交付转给渠道去做,转嫁风险。 那为什么项目交付失败的不少呢?笔者结合这么多年的

2713. 矩阵中严格递增的单元格数

题目 给定一个 m x n 的整数矩阵 mat,我们需要找出从某个单元格出发可以访问的最大单元格数量。移动规则是可以从当前单元格移动到同一行或同一列的任何其他单元格,但目标单元格的值必须严格大于当前单元格的值。需要返回最大可访问的单元格数量。 示例 示例 1: 输入:mat = [[3,1],[3,4]] 输出:2 解释:从第 1 行、第 2 列的单元格开始,可以访问 2 个单元格

转载:如何设置一个严格30分钟过期的Session

好文章自然要转过来哦! 今天在我的微博(Laruence)上发出一个问题: 我在面试的时候, 经常会问一个问题: “如何设置一个30分钟过期的Session?”, 大家不要觉得看似简单, 这里面包含的知识挺多, 特别适合考察基本功是否扎实, 谁来回答试试? 呵呵 为什么问这个问题呢? 1. 我在Twitter上看到了有人讨论这个问题, 2 想起来我经常问这个问题, 所以~~

高并发-乐观锁

例子:抢购商品 逻辑:cas。首先保存一个商品信息的就职,然后处理其他业务,比如计算金额等。在准备减少商品记录时,先做一个对比,看还是不是有那么多件,是就更新,不是则更新失败。重新再执行。会出现ABA问题。 ABA问题举例: 1.你去机场坐飞机,带了一个黑色箱子,突然来了一个美女,你停下看美女,结果美女也拿了一个黑色箱子,并偷偷替换了你的箱子,这时候你看完美女了,一看箱子还是黑色,就直接

通过模拟银行账户取钱操作,彻底了解Java多线程中的乐观锁和悲观锁!

悲观锁 总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程)。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思

JS 严格模式和正常模式的区别

严格模式使用"use strict"; 作用: 消除 Javascript 语法的一些不合理、不严谨之处,减少一些怪异行为;消除代码运行的一些不安全之处,保证代码运行的安全;提高编译器效率,增加运行速度;为未来新版本的 Javascript 做好铺垫。 表现: 严格模式下, delete 运算符后跟随非法标识符(即 delete 不存在的标识符),会抛出语法错误; 非严格模式下,会静默失败

Java并发编程---乐观锁悲观锁原子类

悲观锁与乐观锁 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展,悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。 乐观锁 总是认为不会产生并发问题,每次去取数据的时候总认为不会有其他线程对数据进行修改,因此不会上锁,但是在更新时会判断其他线程在这之前有没有对数据进行修改,一般会使用版本号机制或CAS操作实现。 version方式:一般是在数据表中加上一个数据版本号ve

面试题:谈谈你对乐观锁和悲观锁的理解?

乐观锁(Optimistic Locking)和悲观锁(Pessimistic Locking)是两种不同的并发控制策略,在数据库管理系统和多线程编程中广泛用于处理并发访问共享资源时的数据一致性问题。 悲观锁: 原理:悲观锁正如其名,对并发持悲观态度,认为在并发环境下数据被其他事务修改的概率较高,所以在进行任何数据操作前都会先获取锁,确保在事务执行过程中不会有其他事务对该数据进行修改。 操

Go微服务: 乐观锁

概述 乐观锁(Optimistic Lock)是一种并发控制策略,与悲观锁相对,它基于一种“乐观”的假设,即在大多数情况下,数据访问不会产生并发冲突乐观锁尽量减少锁的使用,从而提高了系统的并发性能,尤其适用于读多写少的场景乐观锁并不在数据访问前进行加锁,而是在数据更新时才检查数据是否被其他事务修改过这种机制假设读操作远多于写操作,而且在大部分情况下,数据在读取和更新之间的这段时间内不会被其他事务