文章目录

  • Java 乐观锁和悲观锁
    • 1、悲观锁
    • 2、乐观锁
      • 2.1 CAS
      • 2.2 模拟CAS算法
      • 2.3 JUC
      • 2.4 CAS中的ABA问题
      • 2.5 使用CAS会引发的问题

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() {@Overridepublic 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() {@Overridepublic 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就无法保证操作的原子性,这个时候就需要借助于锁来实现