Java EE——常见锁策略和CAS及锁的其他概念

最新推荐文章于 2024-07-27 13:31:57 发布

Xiao8830

最新推荐文章于 2024-07-27 13:31:57 发布

阅读量339

点赞数 1

分类专栏： java 文章标签： java jvm 开发语言

本文链接：https://blog.csdn.net/m0_60867520/article/details/126965350

版权

java 专栏收录该内容

174 篇文章 2 订阅

订阅专栏

常见锁策略

由于使用场景的不同，我们的锁有许多不同的分类

乐观锁和悲观锁

乐观锁就是觉得程序锁冲突的概率不高，因此设计的锁没那么复杂
悲观锁就是觉得程序锁冲突的概率很高，因此就让锁实现的更好，避免冲突

乐观锁由于没那么多冲突，因此代码的效率就会提升，但是相对应的数据的准确度就会下降

读写锁和普通互斥锁

普通互斥锁就和synchronized一样，只要同时访问就会竞争

读写锁有两把锁，读锁和写锁
当读锁和读锁同时访问一个数据，不会发生竞争
当读锁和写锁同时访问一个数据，会发生竞争
当写锁和写锁同时访问一个数据，会发生竞争

因此，读写锁相比于普通互斥锁少了很多竞争，也就提升了效率

重量级锁和轻量级锁

轻量级锁的加锁和解锁的开销小，例如纯用户态的加锁
重量级锁的加锁和解锁的开销大，例如用户态和内核态切换的加锁

和我们刚才讲的乐观锁和悲观锁对比，重量级锁轻量级锁主要描述的是锁的加锁解锁消耗的时间和资源，而乐观锁悲观锁主要说的是加锁解锁中干的工作多不多

而乐观锁一般就是轻量级锁，悲观锁一般是重量级锁

自旋锁和挂起等待锁

自旋锁是在锁冲突阻塞等待时，反复询问当前锁是否就绪，这样的话如果解锁了就可以第一时间获得锁
挂起等待锁则是在这个等待时间中可以去干一点别的事情，这样的话可能会错过锁

自旋锁尽管看起来消耗了很多资源，但是是轻量级锁，因为自选锁减少了线程的挂起和恢复，这是由用户态到内核态的过程

公平锁和非公平锁

公平锁就是在锁竞争后，按照先来后到获取锁
而非公平锁就是锁竞争后，几个线程重新竞争锁

偏向锁

类似于懒汉模式，能不加锁就不加锁，当没有锁冲突时就不加锁，一旦发生冲突了，就在发生冲突的代码段上加锁

synchronized

synchronized的锁策略

即是乐观锁，又是悲观锁
即是轻量级锁，又是重量级锁
乐观锁是自旋锁，悲观锁是挂起等待锁
是普通互斥锁
是非公平锁
是可重入锁
是偏向锁
之所以说synchronized即是乐观锁又是悲观锁，是因为我们的synchronized是一个很高级的锁，他是通过锁竞争的次数，自适应锁的状态，竞争的少就是乐观锁，竞争的锁就是悲观锁

synchronized的锁优化

锁消除

当JVM判定我们的代码有的地方是不用加锁的，就会把这个锁去掉，比如虽然有多个线程，但并不修改同一个变量
这种优化是编译器有十足把握才会优化的

锁粗化

锁中的代码数量代表锁的粒度，粒度越粗，代码越多
锁粗化就是一个让锁粒度变粗的操作
当我们对一段连续的代码段，同时用一个锁对象多次加锁，我们的synchronized就会自动把这些锁合并成一个，减少了连续加锁解锁的资源消耗
当然，锁粒度不是越粗越好，既要保证实现的逻辑，也要保证效率

CAS

概念

英文全称是compare and swap，也就是比较并交换
将内存中的值和寄存器A的进行比较，如果一样就把寄存器B的值和内存中的值进行交换
由于CAS是CPU指令完成的，因此这个过程是原子的，也就不会涉及到锁冲突，也十分高效，因此我们可以在一些场景下用CAS来代替加锁

使用场景

实现原子类

我们将各个数据类型的前置++，后置++，前置–，后置–等操作封装起来的类就是原子类，这种类在多线程下是线程安全的，并且十分高效

伪代码

class AtomicInteger {
	private int value;
	public int getAndIncrement() {
		int oldValue = value;
		while ( CAS(value, oldValue, oldValue+1) != true) {
			oldValue = value;
		}
		return oldValue;
	}
}

这个CAS方法中的参数，第一个参数value就相当于内存中的值，第二个oldvalue则是寄存器1中的值，oldvalue + 1则是寄存器2中的值。在自增方法中，先循环判断内存中的值和寄存器1中的值是否相同，如果相同就把寄存器b中的值给内存，也就实现了自增操作，如果不同，oldvalue将赋值为新的value操作。

实际操作中，有1和2两个线程，1线程先加载内存中的值，然后2线程也加载内存中的值，然后内存1CAS操作将内存中的值加一，2线程再进行CAS操作时就会发现自己加载的值和内存中的值不一样了，于是重新加载内存中的值，然后再进行加加操作，这样就避免了线程不安全

java标准库中的实现

demo

public static void main(String[] args) throws InterruptedException {
        AtomicInteger count = new AtomicInteger(0);
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count.getAndIncrement();
//                count.incrementAndGet();
//                count.getAndDecrement();
//                count.decrementAndGet();
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                count.getAndIncrement();
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(count);
    }

getAndIncrement() 后置加加
incrementAndGet() 前置加加
getAndDecrement() 后置减减
decrementAndGet() 前置减减

另外还有其他数据类型的类
AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference

实现自旋锁

伪代码

public class SpinLock {
	private Thread owner = null;
	public void lock(){
		while(!CAS(this.owner, null, Thread.currentThread())){
		}
	}
	public void unlock (){
		this.owner = null;
	}
}

在加锁过程中判断锁的持有者是不是空，如果是，就将锁的持有者变成自己，否则就一直判断，直到锁的持有者变成空

ABA问题

也就是CAS操作无法分辨出内存中的值是不是改变了之后又改变回来了

假设我去取钱，银行取钱时用CAS来对账户余额进行更改操作。，本来账户有1000块，由于atm卡了，我按了两次取800的操作。这时就会创建出两个线程进行CAS操作，两个线程的CAS都从我账户余额中读到了1000的原始余额，a线程先让账户减少了800，这时有别人给我转了800，我的账户余额就又变成1000了，这时b线程就觉得我的账户还没有进行减余额的操作，于是又给我减了800块