JAVA乐观锁、悲观锁实现

一、名词解释

  1、悲观锁:认为每次对数据库的操作(查询、修改)都是不安全的,因此每次操作都会把这条数据锁掉,直到本次操作完毕释放该锁

  2、乐观锁:查询数据的时候总是认为是安全的,不会锁数据;等到更新数据的时候会判断这个数据是否被人修改过,如果有人修改过了则本次修改失败

二、使用过程

  1、悲观锁:悲观锁的内部实现是采用的数据库内部的锁机制,一个典型的依赖数据库的悲观锁调用:

    SELECT * FROM TABLE WHERE ID=‘1‘ FOR UPDATE;

    这条语句锁定了TABLE表总id=‘1‘的这条数据,本次事务提交之前(事务提交后会释放事物终的锁)外界无法修改本条记录,同时也保证了本条数据的准确性;

   悲观锁缺陷:如果在高并发的情况下,每条数据都排队按照以上过程去加锁、运行、解锁,那么可想而知执行时间,等待时间是非常长的,用户体验是非常差的

  2、乐观锁:乐观锁的实现方式有两种:1是添加version字段每次修过叠加;2是使用updatetime每次更新数据后系统自动更新

    UPDATE TABLE SET NAME=‘DD‘ WHERE UPDATETIME=‘查询出的时间‘AND ID=‘1‘

    UPDATETIME也可换成version 在where条件加上这两天自动更新字段,如果不符合说明有改动

   乐观锁缺陷:如果修过特别频繁冲突特别多的情况下会导致很多操作都失败

时间: 2024-10-29 19:08:47

JAVA乐观锁、悲观锁实现的相关文章

最全Java锁详解:独享锁/共享锁+公平锁/非公平锁+乐观锁/悲观锁

在Java并发场景中,会涉及到各种各样的锁如公平锁,乐观锁,悲观锁等等,这篇文章介绍各种锁的分类: 公平锁/非公平锁 可重入锁 独享锁/共享锁 乐观锁/悲观锁 分段锁 自旋锁 01.乐观锁 vs 悲观锁 乐观锁与悲观锁是一种广义上的概念,体现了看待线程同步的不同角度,在Java和数据库中都有此概念对应的实际应用. 1.乐观锁 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制. 乐观锁适用于多

【Java多线程】悲观锁 与 乐观锁

一:悲观锁 悲观锁,就是不管是否发生多线程冲突,只要存在这种可能,就每次访问都加锁,加锁就会导致锁之间的争夺,有争夺就会有输赢,输者等待. syncrhoized是一种独占锁,即:占用该锁的线程才可以执行,申请该锁的线程就只能挂起等待,直到占用锁的线程释放锁才唤醒,拿到锁并执行.由于在进程挂起和恢复执行过程中存在着很大的开销,并且当一个线程正在等待锁时,它不能做任何事.所以syncrhoized是一种悲观锁,凡是用syncrhoized加了锁的多线程之间都会因锁的争夺结果导致挂起.唤醒等开销.

AtomicInteger如何保证线程安全以及乐观锁/悲观锁的概念

众所周知,JDK提供了AtomicInteger保证对数字的操作是线程安全的,线程安全我首先想到了synchronized和Lock,但是这种方式又有一个名字,叫做互斥锁,一次只能有一个持有锁的线程进入,再加上还有不同线程争夺锁这个机制,效率比较低,所以又称“悲观锁”. 但是相应的有了乐观锁的概念,他的思路就是,它不加锁去完成某项操作,如果因为冲突失败就重试,直到成功为止.这种说的比较抽象,我们直接拿AtomicInteger源码举例,因为AtomicInteger保证线程安全就是因为使用了乐观

[转]数据库并发控制 乐观锁,悲观锁

在数据库中,并发控制有乐观锁和悲观锁之间,什么时候用乐观锁比较好什么时候用悲观锁比较好? 实际生产环境里边,如果并发量不大,完全可以使用悲观锁定的方法,这种方法使用起来非常方便和简单.但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以就要选择乐观锁定的方法. 悲观锁假定其他用户企图访问或者改变你正在访问.更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁.悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长

【多线程】公平锁/非公平锁、乐观锁/悲观锁

公平锁/非公平锁(多线程执行顺序的维度) 概念理解 公平锁:加锁前先查看是否有排队等待的线程,有的话优先处理排在前面的线程,先来先得. 非公平所:线程加锁时直接尝试获取锁,获取不到就自动到队尾等待. 例子 ReentrantLock 同时支持两种锁 //创建一个非公平锁,默认是非公平锁 Lock nonFairLock= new ReentrantLock(); Lock nonFairLock= new ReentrantLock(false); //创建一个公平锁,构造传参true Lock

Java 中的悲观锁和乐观锁的实现

锁(locking) 业务逻辑的实现过程中,往往需要保证数据访问的排他性.如在金融系统的日终结算 处理中,我们希望针对某个cut-off时间点的数据进行处理,而不希望在结算进行过程中 (可能是几秒种,也可能是几个小时),数据再发生变化.此时,我们就需要通过一些机 制来保证这些数据在某个操作过程中不会被外界修改,这样的机制,在这里,也就是所谓 的“锁”,即给我们选定的目标数据上锁,使其无法被其他程序修改. Hibernate支持两种锁机制:即通常所说的“悲观锁(Pessimistic Lockin

Java编程:悲观锁、乐观锁的区别及使用场景

定义: 悲观锁(Pessimistic Lock): 每次获取数据的时候,都会担心数据被修改,所以每次获取数据的时候都会进行加锁,确保在自己使用的过程中数据不会被别人修改,使用完成后进行数据解锁.由于数据进行加锁,期间对该数据进行读写的其他线程都会进行等待. 乐观锁(Optimistic Lock): 每次获取数据的时候,都不会担心数据被修改,所以每次获取数据的时候都不会进行加锁,但是在更新数据的时候需要判断该数据是否被别人修改过.如果数据被其他线程修改,则不进行数据更新,如果数据没有被其他线程

并发控制:(二)乐观锁 悲观锁

悲观锁:(pessimistic locking):假定:发生冲突的概率比较高,实现:在对任意记录进行修改前,先尝试为该记录加上排他锁(exclusive locking).这样其他事务如果想操作该记录,需要等待锁的释放特点: 当并发量较大,频繁访问时,等待时间较长,并发访问性不好例如: java的synchronized,SqlServer页级锁,Oracle行级锁 乐观锁:(optimistic locking)假设:发生冲突的概率比较低实现:在提交对记录的更改时才将对象锁住,提交前需要检查

MySQL 乐观锁 悲观锁 共享锁 排他锁

乐观锁 乐观锁是逻辑概念上的锁,不是数据库自带的,需要我们自己去实现.乐观锁是指操作数据库时(更新操作),想法很乐观,认为这次的操作不会导致冲突,在操作数据时,并不进行任何其他的特殊处理(也就是不加锁),而在进行更新后,再去判断是否有冲突了. 通常实现是这样的:在表中的数据进行操作时(更新),先给数据表加一个版本(version)字段,每操作一次,将那条记录的版本号加1.也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查

解决并发问题,数据库常用的两把锁——悲观锁,乐观锁

一.概念: 乐观锁:适用于写少读多的情景,因为这种乐观锁相当于java的cas(比较并替换),所以多条数据同事过来的时候不用等待,可以立即进行返回 悲观锁:适用于写多读少的情景,这种情况也相当于java的synchronized,reentrantLock等,大量数据过来的时候,只有一条被写入,其他数据需要等待,智行完成后下一条数据继续. 二:实现方式: 乐观锁:采用版本号的方式.即当前版本号如果对应上了就可以写入数据,如果判断当前版本号不一致,那么就不会更新成功. 比如 update tabl