悲观锁和乐观锁,啥情况
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了悲观锁和乐观锁,啥情况相关的知识,希望对你有一定的参考价值。
乐观锁和悲观锁的区别如下:1、悲观锁是当线程拿到资源时,就对资源上锁,并在提交后,才释放锁资源,其他线程才能使用资源。
2、乐观锁是当线程拿到资源时,上乐观锁,在提交之前,其他的锁也可以操作这个资源,当有冲突的时候,并发机制会保留前一个提交,打回后一个提交,让后一个线程重新获取资源后,再操作,然后提交。和git上传代码一样,两个线程都不是直接获取资源本身,而是先获取资源的两个copy版本,然后在这两个copy版本上修改。
3、悲观锁和乐观锁在并发量低的时候,性能差不多,但是在并发量高的时候,乐观锁的性能远远优于悲观锁。
4、常用的synchronized是悲观锁,lock是乐观锁。 参考技术A 锁。我们知道,最常用的处理多用户并发访问的方法是加锁。当一个用户锁住数据库中的某个对象时,其他用户就不能再访问该对象。加锁对并发访问的影响体现在锁的粒度上。比如,放在一个表上的锁限制对整个表的并发访问;放在数据页上的锁限制了对整个数据页的访问;放在行上的锁只限制对该行的并发访问。可见行锁粒度最小,并发访问最好,页锁粒度最大,表锁介于2者之间。锁有两种:悲观锁和乐观锁。悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。与悲观锁相反,乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。
从数据库厂商的角度看,使用乐观的页锁是比较好的,尤其在影响很多行的批量操作中可以放比较少的锁,从而降低对资源的需求提高数据库的性能。再考虑聚集索引。在数据库中记录是按照聚集索引的物理顺序存放的。如果使用页锁,当两个用户同时访问更改位于同一数据页上的相邻两行时,其中一个用户必须等待另一个用户释放锁,这会明显地降低系统的性能。interbase和大多数关系数据库一样,采用的是乐观锁,而且读锁是共享的,写锁是排他的。可以在一个读锁上再放置读锁,但不能再放置写锁;你不能在写锁上再放置任何锁。锁是目前解决多用户并发访问的有效手段。本回答被提问者和网友采纳 参考技术B
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
两种锁各有优缺点,不可认为一种好于另一种。
像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。
但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。
Java 乐观锁和悲观锁
文章目录
Java 乐观锁和悲观锁
1、悲观锁
总是假设最坏的情况,每次在去获取共享数据的时候都认为别人会修改,所以每次都在获取数据的时候加锁。 传统的关系型数据库里就用到很多这种锁,比如行锁,表锁、读锁、写锁等都是在操作之前先上锁,比如java中Synchronized关键字的实现也是悲观锁。
悲观锁存在的问题
在多线程竞争下,加锁,释放锁会导致比较多的上下文切换和调度延迟,引起性能问题一个线程持有锁会导致其他需要此锁的线程挂起
2、乐观锁
认为数据一般情况下不会产生并发冲突,所以在数据进行提交更新的时候,才会对数据是否产生并发冲突进行检测,如果发现并发冲突,则返回错误信息,需要用户去决定如何操作。乐观锁实现的典型是CAS(Compare and Swap)
2.1 CAS
具有原子特性
CAS
是乐观锁的实现技术,当多个线程尝试使用CAS
同时更新同一个变量,只有一个线程能更新变量的值,而其他的线程都失败,失败的线程不会被挂起,而是被告知这次竞争失败了,并可以再次进行尝试。
CAS操作中涉及三个操作数:
● 需要读写的内存位置(V)
● 需要比较的预期原值(A)
● 拟写入的新值(B)
如果内存位置V的值与预期原值A相匹配,那么处理器会自动的将该位置值更新为B,否则处理器不做任何处理。
第一步: 获取位置V的值A
第二步: 将获取的值A和位置V的内容进行比较,如果相等,认为没有其他线程修改该位置,即不存在并发竞争,就可以将新值B写入位置V。如果不相等,说明存在其他的线程在对该位置进行并发操作。不能直接修改,继续跳转第一步,获取位置V的值,再进行比较,直至相等再修改为B。
2.2 模拟CAS算法
CompareAndSwap类
public class CompareAndSwap
private int value;
//获取内存值
public synchronized int getValue()
return value;
//比较并交换
public synchronized int compareAndSwap(int expectedValue, int newValue)
int oldValue = value;
//如果内存值和预期值一致,就替换
if (oldValue == expectedValue)
this.value = newValue;
return oldValue;
//设置调用比较并交换, 看期望值和原来的值是否一致
public synchronized boolean compareAndSet(int expectValue, int newValue)
return expectValue == compareAndSwap(expectValue, newValue);
TestCAS类
import java.util.Random;
public class TestCAS
public static void main(String[] args)
CompareAndSwap compareAndSwap = new CompareAndSwap();
for (int i = 0; i < 10; i++)
new Thread(new Runnable()
@Override
public void run()
Random random = new Random();
int expectedValue = compareAndSwap.getValue();
int newValue = random.nextInt(100);
boolean b = compareAndSwap.compareAndSet(expectedValue, newValue);
System.out.println("线程:" + Thread.currentThread().getName() + ",预期值:" + expectedValue + ",待写入值:" + newValue + ",操作结果:" + b);
).start();
运行结果:
2.3 JUC
在JDK 1.5中新增了java.util.concurrent(J.U.C)
建立在CAS之上,相对于Synchronized是一种线程阻塞处理,CAS是非阻塞的一种常见实现,及线程即使没有获取到变量,也不会进入到阻塞状态。就是在不使用锁的情况下来保证线程安全,在JUC下存在如AtomicInteger为例,其中一些++i操作是安全性操作,如getAndIncrement方法。
代码示例:
public class TestJUC
public static void main(String[] args)
AtomicInteger atomicInteger = new AtomicInteger();
for (int i = 0; i < 10; i++)
new Thread(new Runnable()
@Override
public void run()
int i = atomicInteger.getAndIncrement();
System.out.println(Thread.currentThread().getName() +
",预期值:" + i);
).start();
运行结果:
2.4 CAS中的ABA问题
CAS会引起ABA的问题,假如存在如下执行序列:
1、线程1从内存中V取出A
2、线程2从内存中V取出A
3、线程2进行了一些操作,将B写入位置V。
4、线程2将A再次写入位置V
5、线程1进行CAS操作,发现位置V依然是A,进行修改操作并成功
6、尽管线程1的CAS操作成功,但不代表这个过程没有问题,对于线程1,线程2的修改已经丢失了。
一个链表ABA的问题:
1、 现有一个单向链表实现的堆栈,栈顶为A。这时线程1已经知道A.next是B,希望通过CAS操作将栈顶替换为B,线程1执行compareAndSwap(A,B)
2、 在线程1执行上面指令之前,线程2介入,将A、B出栈,在依次入栈D、C、A,而对象B次数处于游离状态。
3、 此时线程1执行CAS操作,检测栈顶认为A,所以CAS成功,栈顶是B,但实际B.next为null,此时堆栈中只有一个B元素,C和D组成的链表就不存在在堆栈中,C、D被丢弃了
ABA问题的解决
ABA问题的解决思路就是使用
版本号
,在变量上追加一个版本号,每次变量变更把版本号加1,那么A-B-A就回去变成1A-2B-3A。
2.5 使用CAS会引发的问题
使用CAS好处就是被使用锁的开销要小,但存在问题
- ABA的问题
ABA的问题的解决方案是加版本号解决 - 循环时间开销大
如果CAS如果长时间不成功,会给CPU带来非常大的执行开销 - 只能保证一个共享变量的原子操作
当对一个共享变量执行操作时,可以使用循环CAS的方式保证原子操作,但对于多个共享变量,循环CAS就无法保证操作的原子性,这个时候就需要借助于锁来实现
以上是关于悲观锁和乐观锁,啥情况的主要内容,如果未能解决你的问题,请参考以下文章