首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏Diuut

    乐观&悲观

    需要使用的场景 满足多个线程共同操作同一共享文件的时候可能发生线程安全问题 目录 悲观 (Pessimistic Lock) 排它/读:FOR UPDATE 共享/写:LOCK IN SHARE MODE 乐观 (Optimistic Lock) 悲观 (Pessimistic Lock) 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁 Java synchronized 就属于悲观的一种实现,每次线程要修改数据时都先获得,保证同一时刻只有一个线程能操作数据,其他线程则会被block。 排它/读:FOR UPDATE 只允许一个线程进行操作,多个线程同时操作时阻塞 共享/写:LOCK IN SHARE MODE 允许多个线程进行读取操作, 但其他操作会阻塞 //悲观示例:更新库存 public boolean updateStock(Long productId){ //先锁定商品库存记录 ProductStock product =

    57410编辑于 2022-11-22
  • 来自专栏shysh95

    悲观

    Hi~朋友,点点关注不迷路 有人乐观,必有人悲观的世界也不例外,乐观悲观的悲欢各不相同。 摘要 什么是悲观 悲观的实现 Monitor Object模式 synchronized的实现原理 优化 1. 什么是悲观 悲观和乐观完全不同,悲观是实实在在对代码块进行加锁,被锁住的代码块,同一时刻只允许一个或几个线程同时进入,避免了多线程写坏共享数据问题。 2. 悲观的实现 Java中的悲观主要有以下几个实现: synchronized 基于AQS实现的各种Lock 3. 本期的Java悲观介绍到这,我是shysh95,我们下期再见!!!

    46920发布于 2021-05-11
  • 来自专栏架构之路

    悲观&乐观

    最近意外发现之前对悲观乐观的理解有误,所以重新学习了一下。 1.悲观 悲观介绍(百科): 悲观,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。 悲观的实现,往往依靠数据库提供的机制(也只有数据库层提供的机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。 2使用悲观来实现: 在上面的场景中,商品信息从查询出来到修改,中间有一个处理订单的过程,使用悲观的原理就是,当我们在查询出goods信息后就把当前的数据锁定,直到我们修改完毕后再解锁。 乐观 乐观( Optimistic Locking ) 相对悲观而言,乐观假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让返回用户错误的信息

    1.5K51发布于 2018-03-19
  • 来自专栏Java架构师必看

    java 悲观

    今天说一说java 悲观[Java怎样解决高并发],希望能够帮助大家进步!!! 首先介绍一些乐观悲观:   悲观:总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到。 传统的关系型数据库里边就用到了很多这种机制,比如行,表等,读,写等,都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观。    这就是一种独占,独占其实就是一种悲观,所以可以说 synchronized 是悲观悲观机制存在以下问题:   1. 如果一个优先级高的线程等待一个优先级低的线程释放会导致优先级倒置,引起性能风险。     对比于悲观的这些问题,另一个更加有效的就是乐观

    59230编辑于 2022-02-19
  • 来自专栏王也

    乐观悲观

    乐观悲观 Q 为什么需要(并发控制) A 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,会产生冲突,这就是著名的并发问题 典型的冲突: -- 丢失更新:一个事务的更新覆盖了其它事务的更新结果 为了解决这些并发带来的问题,需要引入并发控制机制 并发控制机制 -- 悲观:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。 悲观 -- 需要使用数据库的机制,根据的作为范围不同,可以划分为:页面(表级)、行级、。 如MySQL中,不同的数据引擎使用的是不同的,例如InnoDB行是通过给索引上的索引项加锁来实现的,InnoDB这种行实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级,否则,InnoDB 将使用表

    54820编辑于 2022-10-26
  • 来自专栏IT架构圈

    悲观与乐观

    乐观 介绍:认为数据在使用过程中,不会被其他程序修改、所以只有在数据提交时才检测数据是否已经被修改 实现方法 1.使用版本号:给数据所在表加个字段,记录数据版本号。 悲观 介绍:悲观的认为数据提交时会发生并发冲突,屏蔽一切可能违反数据完整性的操作 使用方法:在准备修改某数据时,给该数据加锁,加锁失败说明有人正在占用,成功则修改数据提交,事务完成释放。 使用场景:数据争用激烈的环境,以及发生并发冲突时使用保护数据的成本要低于回滚事务的成本的环境中。 注意项:MySQL InnoDB中使用悲观一定要关闭自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当你执行一个更新操作后,MySQL会立刻将结果进行提交。

    74450发布于 2018-05-31
  • 来自专栏灰子学技术

    乐观悲观

    因此乐观不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据; 适用场景: 当竞争不激烈 (出现并发冲突的概率小)时,乐观更有优势, 因为悲观会锁住代码块或数据,其他线程无法同时访问 悲观(Pessimistic Concurrency Control,缩写“PCC”),又叫悲观并发控制,参考维基百科-悲观并发控制: https://zh.wikipedia.org/wiki/%E6% 82%B2%E8%A7%82%E5%B9%B6%E5%8F%91%E6%8E%A7%E5%88%B6 悲观锁在操作数据时比较悲观,认为别人会同时修改数据。 适用场景: 悲观并发控制主要用于数据竞争激烈的环境, 以及发生并发冲突时使用保护数据的成本要低于回滚事务的成本的环境中。 因为乐观锁在执行更新时频繁失败,需要不断重试,浪费CPU资源。 备注:对于悲观来说,使用比较简单,只需要在使用的时候,加锁和解锁即可,这里不做详细介绍,Go里面的sync便是悲观的典型代表。

    75521发布于 2020-09-14
  • 来自专栏代码宇宙

    乐观&悲观&自旋

    作者:wolf鬼刀 前言 文章目录 乐观&悲观&自旋 一、悲观 二、乐观 1.乐观常见的两种实现方式 2. 版本号机制 3. CAS算法 4. CAS缺点 四、乐观悲观的使用场景 五、自选 1.自选的原理 2.自选的缺陷 3.自旋的使用场景 一、悲观 总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁 类就提供了此种能力,其中的 compareAndSet 方法就是 首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值 四、乐观悲观的使用场景 这其实就是乐观的实现全过程。如果此时使用的是悲观,那么意味着所有程序员都必须一个一个等待操作提交完,才能访问文件,这是难以接受的。 2.什么时候使用悲观? 一旦通过悲观锁定一个资源,那么其他需要操作该资源的使用方,只能等待直到被释放,好处在于可以减少并发,但是当并发量非常大的时候,由于消耗资源,并且可能锁定时间过长,容易导致系统性能下降,资源消耗严重

    1.4K40编辑于 2023-02-16
  • 来自专栏java大数据

    自制悲观

    i)自制悲观: 例 2.2.1.1 package com; public class Ticket_Pess_MarkToWin { private int number=4; public MulThreMarkToWin(Ticket_Pess_MarkToWin ticPes_MarkToWin) { System.out.println("没拿到

    68500发布于 2021-10-10
  • 来自专栏友儿

    乐观悲观

    悲观(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到。 注:要使用悲观,我们必须关闭mysql数据库的自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当你执行一个更新操作后,MySQL会立刻将结果进行提交。 update items set status=2,version=version+1 where id=#{id} and version=#{version}; 为了使用乐观, 我们需要首先修改items表,增加一个version字段,数据默认version可设为1; 其实我们周围的很多产品都有乐观的使用,比如我们经常使用的分布式存储引擎XXX,XXX中存储的每个数据都有版本号 ,版本号在每次更新后都会递增,相应的,在XXX put接口中也有此version参数,这个参数是为了解决并发更新同一个数据而设置的,这其实就是乐观

    43510编辑于 2022-09-11
  • 来自专栏博客园迁移

    乐观悲观

    乐观悲观 http://www.cnblogs.com/qjjazry/p/6581568.html 简单抢购 乐观悲观的实现 http://blog.csdn.net/evankaka/article /details/70570200 http://blog.csdn.net/evankaka/article/details/70568951 乐观(思想) CAS(compare and set)

    57430发布于 2018-08-27
  • 来自专栏学习与分享

    乐观悲观

    二、悲观 悲观是一种悲观机制,它假设并发冲突会频繁发生,因此在数据处理过程中会直接锁定数据,防止其他用户修改数据。在锁定期间,其他用户无法访问被锁定的数据。 三、总结 乐观悲观都有各自的优缺点。乐观避免了失败回滚的情况,但是在高并发的情况下可能会引起较多的冲突;悲观避免了冲突的发生,但是可能会引起死锁和长时间锁定数据的问题。 例如,在读取数据时使用乐观,在更新数据时使用悲观;或者在更新数据时使用乐观悲观锁相结合的方式。这样可以充分发挥各种机制的优势,提高系统的性能和可用性。 乐观悲观是两种常见的数据库并发控制策略,它们在处理并发访问时有不同的思想和实现方式。本文将分别介绍乐观悲观,并对它们的优缺点进行比较。 1. 悲观 悲观的核心思想是假设并发访问的事务之间会互相影响,因此在读取数据时就对其加锁,防止其他事务对数据进行修改。悲观主要通过数据库的机制来实现。

    59410编辑于 2024-02-20
  • 来自专栏微观技术

    乐观悲观

    悲观: 正如其名,它指对数据被外界(可能是本机的其他事务,也可能是来自其它服务器的事务处理)的修改持保守态度。在整个数据处理过程中,将数据处于锁定状态。 悲观大多数情况下依靠数据库的机制实现,以保证操作最大程度的独占性。 小结: 乐观悲观之间选择的标准是冲突的频率、严重性。如果冲突较少或者冲突的后果不是很严重,通常情况下会选择乐观,容易实现且吞吐性高,能得到更好的并发性。 如果冲突的结果对用户来说是非常严重的,可以使用悲观,适当牺牲一些性能。 针对如何解决多线程并发产生的脏数据问题,本文简单列举一些常见案例及应对措施。 - #sub_quantity# > 0 注意:如果每次访问冲突概率小于 20%,推荐使用乐观,否则使用悲观

    87830发布于 2020-08-20
  • 来自专栏学习内容

    悲观和乐观

    一、什么是悲观,什么是乐观 1、(Lock)  在介绍悲观和乐观之前,让我们看一下,在我们生活中随处可见,我们的门上有,我们存钱的保险柜上有,是用来保护我们财产安全的。 2、悲观(Pessimistic Concurrency Control):  悲观,第一眼看到它,相信每个人都会想到这是一个悲观。没错,它就是一个悲观。那这个悲观体现在什么地方呢? 悲观是我们人类一种消极的情绪,对应到悲观情绪。 不同于悲观,乐观是人为控制的。 二、怎么实现悲观,怎么实现乐观 经过上面的学习,我们知道悲观和乐观是用来控制并发下数据的顺序变动问题的。 四、乐观悲观的应用场景 悲观 因为悲观会影响系统吞吐的性能,所以适合应用在写为居多的场景下。 乐观 因为乐观就是为了避免悲观的弊端出现的,所以适合应用在读为居多的场景下。

    45120编辑于 2023-08-09
  • 来自专栏FREE SOLO

    悲观与乐观

    何谓悲观与乐观 乐观对应于生活中乐观的人总是想着事情往好的方向发展,悲观对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点,不能不以场景而定说一种人好于另外一种人。 传统的关系型数据库里边就用到了很多这种机制,比如行,表等,读,写等,都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占就是悲观思想的实现。 但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观就比较合适。 : 悲观:在读取数据时锁住那几行,其他对这几行的更新需要等到悲观结束时才能继续 。 乐观:读取数据时不,更新时检查是否数据已经被更新过,如果是则取消当前更新 一般在悲观的等待时间过长而不能接受时我们才会选择乐观

    1K00发布于 2019-04-18
  • 来自专栏技术博文

    悲观与乐观

    悲观,每次访问资源都会加锁,执行完同步代码释放,synchronized 和 ReentrantLock 属于悲观。 乐观,不会锁定资源,所有的线程都能访问并修改同一个资源,如果没有冲突就修改成功并退出,否则就会继续循环尝试。乐观最常见的实现就是CAS。 乐观一般来说有以下2种方式: 1.使用数据版本记录机制实现,这是乐观最常用的一种实现方式。给数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的version字段来实现。 适用场景: 1.悲观适合写操作多的场景。 2.乐观适合读操作多的场景,不加锁可以提升读操作的性能。

    73340发布于 2021-09-28
  • 来自专栏醉程序

    悲观、乐观,浅析

    悲观和乐观是并发控制常用的两种技术手段。 并发控制是用来确保 多个事务同时读写DB中同一条数据时不破坏事务的隔离性、统一性以及数据库的统一性。 悲观 悲观 (Pessimistic Lock),又称悲观并发控制 (Pessimistic Concurrency Control) 对数据的处理保持悲观的心态。 在数据处理过程中,利用数据库层提供的机制,始终将数据置于锁定状态,直至处理完成。 悲观的流程如下: 1. 在数据更新前对该待更新数据加排他 2. 时),与悲观锁相比效率会更高一些(支持更高的并发量),但同样因此可能存在ABA的问题。 参考 深入理解乐观悲观 MySQL 乐观悲观

    67010发布于 2019-12-29
  • 来自专栏捞月亮的小北

    悲观和乐观

    在Java中,悲观和乐观是处理并发访问共享资源时采用的不同策略。它们主要的区别在于对数据竞争的预期和处理方式。 悲观 (Pessimistic Lock) 悲观基于“悲观”的假设,即默认情况下它认为数据可能会被其他线程修改,因此在操作数据前会尝试获得独占的。 一旦某个线程持有悲观,其他试图访问相同资源的线程将被阻塞,直到被释放。 概念和作用: 悲观通过确保在任何时刻只有一个线程能够访问共享资源,从而避免了数据的竞争条件。 new Object(); Thread thread1 = new Thread(() -> { synchronized (lock) { // 悲观 } }); Thread thread2 = new Thread(() -> { synchronized (lock) { // 悲观

    27310编辑于 2024-07-08
  • 来自专栏action的经验之路

    悲观和乐观

    我就想到了悲观和乐观的思想,下面我解释一下在数据库中的悲观和乐观         1.悲观就是把数据库的一些操作,放在事务当中,依赖数据库的隔离级别,实现对数据修改的封锁,这样做数据一致性可以保持的很好 ,但是效率比较低下,悲观从程序的角度上将,就是不在应用程序中做任何保证数据一致性操作,而是把操作放在事务中,把保证数据一致性的任务,交给数据库去做,也就是依赖数据库的机制。         2.乐观其实从真正意义上并不是,是一种代替事务的操作,在应用程序中,如果一个事务不是太复杂,又能容忍数据的更新失败,并且可以尝试重复更新,那么可以考虑用乐观来替代事务,即不通过事务来保证数据的一致性 悲观与乐观的区别:          悲观是一种排他,效率低下,但是数据安全,一般实现在数据库中,不是实现在应用程序中,乐观准备说不是一种机制,它是应用程序自己加的一种保证数据一致性的机制, 所以一般实现在应用程序中,而不是实现在数据库中,并且在hibernate中我们可以显示配置悲观乐观,当然乐观需要在配置文件中配置version属性(用来充当版本号)。

    47640编辑于 2022-11-30
  • 来自专栏小小码农一个。

    何谓悲观与乐观

    乐观对应于生活中乐观的人总是想着事情往好的方向发展,悲观对应于生活中悲观的人总是想着事情往坏的方向发展。这两种人各有优缺点,不能不以场景而定说一种人好于另外一种人。 悲观 总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到(共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程 传统的关系型数据库里边就用到了很多这种机制,比如行,表等,读,写等,都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占就是悲观思想的实现。 两种的使用场景 从上面对两种的介绍,我们知道两种各有优缺点,不可认为一种好于另一种,像乐观适用于写比较少的情况下(多读场景),即冲突真的很少发生的时候,这样可以省去了的开销,加大了系统的整个吞吐量 但如果是多写的情况,一般会经常产生冲突,这就会导致上层应用会不断的进行retry,这样反倒是降低了性能,所以一般多写的场景下用悲观就比较合适。

    87310发布于 2020-06-08
领券