❤️并发编程❤️各式各样的“锁”

灰太狼 2022-08-28 08:45 73阅读 0赞

> ***【并发编程系列】***  
> [❤️并发编程❤️创建线程的四种方式 线程通信  
> ][Link 1]  
> [❤️并发编程❤️一万字线程生命周期和状态转换知识梳理  
> ][Link 2]  
> [❤️并发编程❤️Java内存模型  
> ][Java_]  
> [❤️并发编程❤️重排序与happens-before  
> ][happens-before]  
> [❤️并发编程❤️显式锁Lock和内置锁知识整理  
> ][Lock_]  
> [❤️并发编程❤️如何正确停止线程？  
> ][Link 3]  
> [❤️并发编程❤️生产者消费者模式实现的三种方式  
> ][Link 4]  
> [❤️并发编程❤️线程安全问题分析和场景总结  
> ][Link 5]  
> [❤️并发编程❤️线程池源码分析以及线程复用的原理  
> ][Link 6]  
> [❤️并发编程❤️如何正确关闭线程池？shutdown 和 shutdownNow 的区别？  
> ][shutdown _ shutdownNow _]  
> [❤️并发编程❤️synchronized锁原理分析  
> ][synchronized_]  
> [❤️并发编程❤️各式各样的“锁”  
> ][Link 7]

### 文章目录 ###

*   *   *  注意
     *  （一）无锁、偏向锁、轻量级锁、重量级锁
     *   *  （1）Java对象头
         *  （2）无锁
         *  （3）偏向锁
         *  （4）轻量级锁
         *  （5）重量级锁
         *  （6）总结锁的升级流程
         *  （7）各种锁的优缺点对比
     *  （二）可重入锁/非可重入锁
     *  （三）共享锁/独占锁
     *  （四）公平锁/非公平锁
     *  （五）悲观锁/乐观锁
     *  （六）自旋锁/非自旋锁
     *  （七）可中断锁/不可中断锁

### 注意 ###

Java多线程的锁都是基于对象的，Java中的每一个对象都可以作为一个锁。  
还有一点需要注意的是，我们常听到的类锁其实也是对象锁。

Java类只有一个Class对象（可以有多个实例对象，多个实例共享这个Class对象），而Class对象也是特殊的Java对象。所以我们常说的类锁，其实就是Class对象的锁。

## （一）无锁、偏向锁、轻量级锁、重量级锁 ##

Java 6 为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁“。在Java 6 以前，所有的锁都是”重量级“锁。所以在Java 6 及其以后，一个对象其实有四种锁状态，它们级别由低到高依次是：

无锁状态  
偏向锁状态  
轻量级锁状态  
重量级锁状态

### （1）Java对象头 ###

Java的锁都是基于对象的，每个Java对象都有对象头。如果是非数组类型，则用2个字宽来存储对象头，如果是数组，则会用3个字宽来存储对象头。在32位处理器中，一个字宽是32位；在64位虚拟机中，一个字宽是64位。对象头的内容如下表：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16]  
Mark Word的格式：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
【说明】当对象状态为偏向锁时，Mark Word存储的是偏向的线程ID；当状态为轻量级锁时，Mark Word存储的是指向线程栈中Lock Record的指针；当状态为重量级锁时，Mark Word为指向堆中的monitor对象的指针。

### （2）无锁 ###

无锁就是没有对资源进行锁定，任何线程都可以尝试去修改它，一般的没有额外的锁以及安全操作的都是无锁状态

### （3）偏向锁 ###

Hotspot的作者经过以往的研究发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，于是引入了偏向锁。

偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也就是说，偏向锁在资源无竞争情况下消除了同步语句，连CAS操作都不做了，提高了程序的运行性能。

一个线程在第一次进入同步块时，会在对象头和栈帧中的锁记录里存储锁的偏向的线程ID。当下次该线程进入这个同步块时，会去检查锁的Mark Word里面是不是放的自己的线程ID。

如果是，表明该线程已经获得了锁，以后该线程在进入和退出同步块时不需要花费CAS操作来加锁和解锁 ；如果不是，就代表有另一个线程来竞争这个偏向锁。这个时候会尝试使用CAS来替换Mark Word里面的线程ID为新线程的ID，这个时候要分两种情况：  
1：成功，表示之前的线程不存在了， Mark Word里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁；  
2：失败，表示之前的线程仍然存在，那么暂停之前的线程，设置偏向锁标识为0，并设置锁标志位为00，升级为轻量级锁，会按照轻量级锁的方式进行竞争锁。  
![在这里插入图片描述][70d0f8c9a9c5484e8619650be15c2e9a.png]

### （4）轻量级锁 ###

多个线程在不同时段获取同一把锁，即不存在锁竞争的情况，也就没有线程阻塞。针对这种情况，JVM采用轻量级锁来避免线程的阻塞与唤醒。

1.  轻量级锁的加锁  
    JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，我们称为Displaced Mark Word。如果一个线程获得锁的时候发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。

然后线程尝试用CAS将锁的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

自旋：不断尝试去获取锁，一般用循环来实现。

自旋是需要消耗CPU的，如果一直获取不到锁的话，那该线程就一直处在自旋状态，白白浪费CPU资源。解决这个问题最简单的办法就是指定自旋的次数，例如让其循环10次，如果还没获取到锁就进入阻塞状态。

但是JDK采用了更聪明的方式——适应性自旋，简单来说就是线程如果自旋成功了，则下次自旋的次数会更多，如果自旋失败了，则自旋的次数就会减少。

自旋也不是一直进行下去的，如果自旋到一定程度（和JVM、操作系统相关），依然没有获取到锁，称为自旋失败，那么这个线程会阻塞。同时这个锁就会升级成重量级锁。

1.  轻量级锁的释放

在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。

### （5）重量级锁 ###

重量级锁依赖于操作系统的互斥量（mutex） 实现的，而操作系统中线程间状态的转换需要相对比较长的时间，所以重量级锁效率很低，但被阻塞的线程不会消耗CPU。

每一个对象都可以当做一个锁，当多个线程同时请求某个对象锁时，对象锁会设置几种状态用来区分请求的线程：  
Contention List：所有请求锁的线程将被首先放置到该竞争队列  
Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List  
Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set  
OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck  
Owner：获得锁的线程称为Owner  
!Owner：释放锁的线程

当一个线程尝试获得锁时，如果该锁已经被占用，则会将该线程封装成一个ObjectWaiter对象插入到Contention List的队列的队首，然后调用park函数挂起当前线程。

当线程释放锁时，会从Contention List或EntryList中挑选一个线程唤醒，被选中的线程叫做Heir presumptive即假定继承人，假定继承人被唤醒后会尝试获得锁，但synchronized是非公平的，所以假定继承人不一定能获得锁。这是因为对于重量级锁，线程先自旋尝试获得锁，这样做的目的是为了减少执行操作系统同步操作带来的开销。如果自旋不成功再进入等待队列。这对那些已经在等待队列中的线程来说，稍微显得不公平，还有一个不公平的地方是自旋线程可能会抢占了Ready线程的锁。

如果线程获得锁后调用Object.wait方法，则会将线程加入到WaitSet中，当被Object.notify唤醒后，会将线程从WaitSet移动到Contention List或EntryList中去。需要注意的是，当调用一个锁对象的wait或notify方法时，如当前锁的状态是偏向锁或轻量级锁则会先膨胀成重量级锁。

### （6）总结锁的升级流程 ###

每一个线程在准备获取共享资源时：  
第一步，检查MarkWord里面是不是放的自己的ThreadId ,如果是，表示当前线程是处于 “偏向锁” 。

第二步，如果MarkWord不是自己的ThreadId，锁升级，这时候，用CAS来执行切换，新的线程根据MarkWord里面现有的ThreadId，通知之前线程暂停，之前线程将Markword的内容置为空。

第三步，两个线程都把锁对象的HashCode复制到自己新建的用于存储锁的记录空间，接着开始通过CAS操作，  
把锁对象的MarKword的内容修改为自己新建的记录空间的地址的方式竞争MarkWord。

第四步，第三步中成功执行CAS的获得资源，失败的则进入自旋 。

第五步，自旋的线程在自旋过程中，成功获得资源(即之前获的资源的线程执行完成并释放了共享资源)，则整个状态依然处于 轻量级锁的状态，如果自旋失败 。

第六步，进入重量级锁的状态，这个时候，自旋的线程进行阻塞，等待之前线程执行完成并唤醒自己。

### （7）各种锁的优缺点对比 ###

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16 2]

## （二）可重入锁/非可重入锁 ##

所谓重入锁，顾名思义。就是支持重新进入的锁，也就是说这个锁支持一个线程对资源重复加锁。

对于可重入锁而言，最典型的就是 ReentrantLock 了，正如它的名字一样，reentrant 的意思就是可重入，它也是 Lock 接口最主要的一个实现类。

synchronized关键字就是使用的重入锁。比如说，你在一个synchronized实例方法里面调用另一个本实例的synchronized实例方法，它可以重新进入这个锁，不会出现任何异常。

## （三）共享锁/独占锁 ##

共享锁指的是我们同一把锁可以被多个线程同时获得，而独占锁指的就是，这把锁只能同时被一个线程获得。我们的读写锁ReentrantReadWriteLock，就最好地诠释了共享锁和独占锁的理念。读写锁中的读锁，是共享锁，而写锁是独占锁。读锁可以被同时读，可以同时被多个线程持有，而写锁最多只能同时被一个线程持有。

## （四）公平锁/非公平锁 ##

这里的“公平”，其实通俗意义来说就是“先来后到”，也就是FIFO。如果对一个锁来说，先对锁获取请求的线程一定会先被满足，后对锁获取请求的线程后被满足，那这个锁就是公平的。反之，那就是不公平的。

一般情况下，非公平锁能提升一定的效率。但是非公平锁可能会发生线程饥饿（有一些线程长时间得不到锁）的情况。所以要根据实际的需求来选择非公平锁和公平锁。

ReentrantLock支持非公平锁和公平锁两种， ReentrantLock的默认策略是非公平锁。

## （五）悲观锁/乐观锁 ##

悲观锁的概念是在获取资源之前，必须先拿到锁，以便达到“独占”的状态，当前线程在操作资源的时候，其他线程由于不能拿到锁，所以其他线程不能来影响我。而乐观锁恰恰相反，它并不要求在获取资源前拿到锁，也不会锁住资源；相反，乐观锁利用 CAS 理念，在不独占资源的情况下，完成了对资源的修改。

悲观锁就是我们常说的锁（比如synchronized）。对于悲观锁来说，它总是认为每次访问共享资源时会发生冲突，所以必须对每次数据操作加上锁，以保证临界区的程序同一时间只能有一个线程在执行。

乐观锁又称为“无锁”，顾名思义，它是乐观派。乐观锁总是假设对共享资源的访问没有冲突，线程可以不停地执行，无需加锁也无需等待。而一旦多个线程发生冲突，乐观锁通常是使用一种称为CAS的技术来保证线程执行的安全性。

由于无锁操作中没有锁的存在，因此不可能出现死锁的情况，也就是说乐观锁天生免疫死锁。

乐观锁多用于“读多写少“的环境，避免频繁加锁影响性能；而悲观锁多用于”写多读少“的环境，避免频繁失败和重试影响性能。

悲观锁和乐观锁是从是否锁住资源的角度进行分类的。

悲观锁比较悲观，它认为如果不锁住这个资源，别的线程就会来争抢，就会造成数据结果错误，所以悲观锁为了确保结果的正确性，会在每次获取并修改数据时，都把数据锁住，让其他线程无法访问该数据，这样就可以确保数据内容万无一失。

乐观锁比较乐观，认为自己在操作资源的时候不会有其他线程来干扰，所以并不会锁住被操作对象，不会不让别的线程来接触它，同时，为了确保数据正确性，在更新之前，会去对比在我修改数据期间，数据有没有被其他线程修改过：如果没被修改过，就说明真的只有我自己在操作，那我就可以正常的修改数据；如果发现数据和我一开始拿到的不一样了，说明其他线程在这段时间内修改过数据，那说明我迟了一步，所以我会放弃这次修改，并选择报错、重试等策略。

悲观锁和乐观锁概念并不是 Java 中独有的，这是一种广义的思想，这种思想可以应用于其他领域，比如说在数据库中，同样也有对悲观锁和乐观锁的应用。

Java 中悲观锁的实现包括 synchronized 关键字和 Lock 相关类等，我们以 Lock 接口为例，例如 Lock 的实现类 ReentrantLock，类中的 lock() 等方法就是执行加锁，而 unlock() 方法是执行解锁。处理资源之前必须要先加锁并拿到锁，等到处理完了之后再解开锁，这就是非常典型的悲观锁思想。

乐观锁的典型案例就是原子类，例如 AtomicInteger 在更新数据时，就使用了乐观锁的思想，多个线程可以同时操作同一个原子变量。

数据库中同时拥有悲观锁和乐观锁的思想。例如，我们如果在 MySQL 选择 select for update 语句，那就是悲观锁，在提交之前不允许第三方来修改该数据，这当然会造成一定的性能损耗，在高并发的情况下是不可取的。

相反，我们可以利用一个版本 version 字段在数据库中实现乐观锁。在获取及修改数据时都不需要加锁，但是我们在获取完数据并计算完毕，准备更新数据时，会检查版本号和获取数据时的版本号是否一致，如果一致就直接更新，如果不一致，说明计算期间已经有其他线程修改过这个数据了，那我就可以选择重新获取数据，重新计算，然后再次尝试更新数据。

UPDATE student
        SET 
            name = ‘XXX’,
            version= 2
        WHERE   id= 100
            AND version= 1

## （六）自旋锁/非自旋锁 ##

自旋锁的理念是如果线程现在拿不到锁，并不直接陷入阻塞或者释放 CPU 资源，而是开始利用循环，不停地尝试获取锁，这个循环过程被形象地比喻为“自旋”，就像是线程在“自我旋转”。相反，非自旋锁的理念就是没有自旋的过程，如果拿不到锁就直接放弃，或者进行其他的处理逻辑，例如去排队、陷入阻塞等。

## （七）可中断锁/不可中断锁 ##

在 Java 中，synchronized 关键字修饰的锁代表的是不可中断锁，一旦线程申请了锁，只能等到拿到锁以后才能进行其他的逻辑处理。而我们的 ReentrantLock 是一种典型的可中断锁，例如使用 lockInterruptibly 方法在获取锁的过程中，突然不想获取了，那么也可以在中断之后去做其他的事情，不需要一直傻等到获取到锁才离开。

[Link 1]: https://blog.csdn.net/Octopus21/article/details/120106529
[Link 2]: https://blog.csdn.net/Octopus21/article/details/120589643
[Java_]: https://blog.csdn.net/Octopus21/article/details/120120576
[happens-before]: https://blog.csdn.net/Octopus21/article/details/120120611
[Lock_]: https://blog.csdn.net/Octopus21/article/details/120468606
[Link 3]: https://blog.csdn.net/Octopus21/article/details/120584190
[Link 4]: https://blog.csdn.net/Octopus21/article/details/120591757
[Link 5]: https://blog.csdn.net/Octopus21/article/details/120596474
[Link 6]: https://blog.csdn.net/Octopus21/article/details/120608492
[shutdown _ shutdownNow _]: https://blog.csdn.net/Octopus21/article/details/120612116
[synchronized_]: https://blog.csdn.net/Octopus21/article/details/120619359
[Link 7]: https://blog.csdn.net/Octopus21/article/details/120619395
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/c26868f0b08b46bbaac743ddadfbcef3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/8dbfb2e6426840c0a16812667f8f6963.png
[70d0f8c9a9c5484e8619650be15c2e9a.png]: /images/20220828/ec222b7628374336b5044221847edf10.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAWldaaGFuZ1l1_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/8102c2773d654b61878ef2ff2d901b37.png