锁的分类

最新推荐文章于 2023-03-10 16:04:09 发布

今天你学习了么

最新推荐文章于 2023-03-10 16:04:09 发布

阅读量206

点赞数

分类专栏：深入理解java多线程

本文链接：https://blog.csdn.net/weixin_43907800/article/details/105214909

版权

深入理解java多线程专栏收录该内容

38 篇文章 2 订阅

订阅专栏

大部分图片来源不可不说的Java“锁”事
在这里插入图片描述

1. 乐观锁与悲观锁

`悲观锁`(互斥同步锁)

悲观锁的思想就是，如果我不锁住这个资源，别人就会来争抢，就会造成数据结果的错误，所以每次悲观锁就会为了保证结果的正确性，在每次获取并修改数据的时候把数据锁住，让别人无法访问数据（典型的就是synchronizd和lock），但是这样的思想会有缺陷

① 阻塞和唤醒会带来性能的劣势
在线程的挂起与唤醒会发生上下文切换，会带来性能的损耗

② 永久阻塞
如果持有锁的线程被永久阻塞，比如遇到了无限循环，死锁等活跃性问题，那么等待该线程释放锁的那几个另外的线程就永远得不到执行

③ 优先级反转
如果优先级较低的线程拿到锁一直不是放，那么优先级较高的线程反而无法运行

`乐观锁`(非互斥同步锁)

乐观锁的思想是认为自己在处理操作的时候不会有其他线程来干扰，所以并不会锁住被操作的对象，为了保证正确性，在更新的时候去对比在我修改的期间数据有没有被其他人改变过

如果没有被改变过，就说明真的只有我在操作数据，那么我就正常的修改数据
如果数据和我一开始拿到的不一样，就说明其他人在这段时间内改过数据，那我就不能继续刚才的更新数据操作了，我会选择放弃，报错，重试等策略

在这里插入图片描述

乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的

Git也是典型的乐观锁的例子：
当我们往远端仓库push的时候，git会检查远端的仓库的版本是不是领先于我们现在的版本，如果远程的仓库的版本号和我们现在的不一样就说明有人修改了远端的代码，我们这次的提交就失败了；如果一致，那么就可以顺利提交；

Git不适合悲观锁的原因也是显而易见的，假如使用悲观锁，员工A从仓库拉取了资源，那他就会独占这个资源，别的员工根本就无法访问，更别提正常的工作了

开销对比

悲观锁的原始开销要高于乐观锁(因为涉及到上下文切换啊，创建管程对象啊等等操作)，但是他是一劳永逸的

所以悲观锁适合并发写入多，临界区持锁的时间较长的情况，悲观锁可以避免大量的无用自旋等消耗

临界区有IO操作
临界区代码复制且循环量大
临界区竞争激烈

相反乐观锁一开始的开销比悲观锁小，但是如果自旋时间很长或者不停重试，那么消化的资源也就越来越多(他一直不会释放cpu)

适合并发写入少，大部分都是读取的场景

2. 可重入锁与不可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁

public class Widget {
    public synchronized void doSomething() {
        System.out.println("方法1执行...");
        doOthers();
    }

    public synchronized void doOthers() {
        System.out.println("方法2执行...");
    }
}

在上面的代码中，类中的两个方法都是被内置锁synchronized修饰的，doSomething()方法中调用doOthers()方法。因为内置锁是可重入的，所以同一个线程在调用doOthers()时可以直接获得当前对象的锁，进入doOthers()进行操作。

如果是一个不可重入锁，那么当前线程在调用doOthers()之前需要将执行doSomething()时获取当前对象的锁释放掉，实际上该对象锁已被当前线程所持有，且无法释放。所以此时会出现死锁

lock.getHoldCount() //获得被重入了几次

ReentrantLock和synchronized都是重入锁，那么我们通过重入锁ReentrantLock以及非可重入锁NonReentrantLock的源码来对比分析一下为什么非可重入锁在重复调用同步资源时会出现死锁。

首先ReentrantLock和NonReentrantLock都继承父类AQS，其父类AQS中维护了一个同步状态status来计数重入次数，status初始值为0。

当线程尝试获取锁时，可重入锁先尝试获取并更新status值，如果status == 0表示没有其他线程在执行同步代码，则把status置为1，当前线程开始执行。如果status != 0，则判断当前线程是否是获取到这个锁的线程，如果是的话执行status+1，且当前线程可以再次获取锁。

而非可重入锁是直接去获取并尝试更新当前status的值，如果status != 0的话会导致其获取锁失败，当前线程阻塞。

释放锁时，可重入锁同样先获取当前status的值，在当前线程是持有锁的线程的前提下。如果status-1 == 0，则表示当前线程所有重复获取锁的操作都已经执行完毕，然后该线程才会真正释放锁。

而非可重入锁则是在确定当前线程是持有锁的线程之后，直接将status置为0，将锁释放
在这里插入图片描述

3. 公平锁和非公平锁

`公平`

公平指的是按照线程请求的顺序来分配锁
ReentryLock默认是非公平的，但是可以设置为公平锁

ReentrantLock lock = new ReentrantLock(true);

在这里插入图片描述
如上图所示，假设有一口水井，有管理员看守，管理员有一把锁，只有拿到锁的人才能够打水，打完水要把锁还给管理员。每个过来打水的人都要管理员的允许并拿到锁之后才能去打水，如果前面有人正在打水，那么这个想要打水的人就必须排队。管理员会查看下一个要去打水的人是不是队伍里排最前面的人，如果是的话，才会给你锁让你去打水；如果你不是排第一的人，就必须去队尾排队，这就是公平锁。

`非公平`

非公平锁指的是不完全按照请求的顺序，在一定情况下可以插队，注意非公平也是同样不提倡插队的行为的，只是在合适的时机会插队，而不是盲目的插队

上面的例子对于非公平锁，管理员对打水的人没有要求。即使等待队伍里有排队等待的人，但如果在上一个人刚打完水把锁还给管理员而且管理员还没有允许等待队伍里下一个人去打水时，刚好来了一个插队的人，这个插队的人是可以直接从管理员那里拿到锁去打水，不需要排队，原本排队等待的人只能继续等待。如下图所示：
在这里插入图片描述

这样做可以提高效率，避免唤醒带来的空档期，假如现在A线程持有锁，B等待锁，这个时候A释放了锁，那么B要被唤醒，在B进行上下文切换的时候突然来了一个没有休眠的线程C把A释放的锁拿了，在B切换上下文的时间段内使用完又释放了锁，实际上这对B是没有影响的，而且提升了整个程序的吞吐量

可以看到下面的源码，ReentrantLock里面有一个内部类Sync，Sync继承AQS（AbstractQueuedSynchronizer），添加锁和释放锁的大部分操作实际上都是在Sync中实现的。它有公平锁FairSync和非公平锁NonfairSync两个子类。ReentrantLock默认使用非公平锁，也可以通过构造器来显示的指定使用公平锁，公平锁在占锁之前会先去判断他前面有没有线程在等待
在这里插入图片描述

特例`tryLock()`

针对tryLock()方法，他是不遵守设定的公平规则的，只要有线程释放了锁，那么正在tryLock()的线程就会获得锁，即使他前面有人等待

优缺点

公平锁： 各个线程公平等待，但是吞吐量会变小
非公平锁： 吞吐量大但是可能会产生线程饥饿

4. 共享锁和排它锁

`排它锁`

排它锁又称独占锁，获得了以后既能读又能写，，其他没有获得锁的线程不能读也不能写，典型的xynchronized就是排它锁

`共享锁`

共享锁又称读锁，获得了共享锁以后可以查看但无法修改和删除数据，其他线程也能获得共享锁，也可以查看但不能修改和删除数据

在没有读写锁之前，那么我们虽然保证了线程安全，但是也浪费了一定的资源，因为多个读操作同时进行并没有线程安全问题

ReentrantReadWriteLock中读锁就是共享锁，写锁是排它锁，在读的地方使用读锁，在写的地方使用写锁，灵活控制，如果不这样，读是无限阻塞的，这样提高了程序的执行效率

适用场合

ReentrantReadWriteLock适合用于读多写少的情况，可以提高并发的效率

5. 自旋锁和阻塞锁

阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。

在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

而为了让当前线程“稍等一下”，我们需让当前线程进行自旋，如果在自旋完成后前面锁定同步资源的线程已经释放了锁，那么当前线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁
在这里插入图片描述

缺点

自旋锁本身是有缺点的，它不能代替阻塞。自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程

适用场景

自旋锁一般用于多核的服务器，并在并发度不是特别高的情况下，比阻塞锁的效率高
自旋锁适合于临界区短小的情况，否则线程会很久释放锁，别的线程就要自旋很久

实现原理

自旋锁的实现原理同样也是CAS，AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作，如果修改数值失败则通过循环来执行自旋，直至修改成功
在这里插入图片描述
自旋锁在JDK1.4.2中引入，使用-XX:+UseSpinning来开启。JDK 6中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。

自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源

自定义自旋锁

/**
 * 描述：     自旋锁
 */
public class SpinLock {

    private AtomicReference<Thread> sign = new AtomicReference<>();

    public void lock() {
        Thread current = Thread.currentThread();
        while (!sign.compareAndSet(null, current)) {
            System.out.println("自旋获取失败，再次尝试");
        }
    }

    public void unlock() {
        Thread current = Thread.currentThread();
        sign.compareAndSet(current, null);
    }

    public static void main(String[] args) {
        SpinLock spinLock = new SpinLock();
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                System.out.println(Thread.currentThread().getName() + "开始尝试获取自旋锁");
                spinLock.lock();
                System.out.println(Thread.currentThread().getName() + "获取到了自旋锁");
                try {
                    Thread.sleep(300);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    spinLock.unlock();
                    System.out.println(Thread.currentThread().getName() + "释放了自旋锁");
                }
            }
        };
        Thread thread1 = new Thread(runnable);
        Thread thread2 = new Thread(runnable);
        thread1.start();
        thread2.start();
    }
}