java锁常识

可爱的小小小狼

已于 2024-05-08 11:23:06 修改

阅读量1.2k

点赞数 44

分类专栏：并发编程文章标签： java 开发语言

于 2024-04-22 23:13:45 首次发布

本文链接：https://blog.csdn.net/qq_35693377/article/details/138093240

版权

并发编程专栏收录该内容

25 篇文章 0 订阅

订阅专栏

在这里插入图片描述

AQS框架

AQS（AbstractQueuedSynchronizer）是 Java 中用于构建锁和同步器的基础框架。它提供了一种实现同步器的方式，使得开发者可以基于 AQS 构建各种类型的同步工具，如独占锁、共享锁、信号量等。

AQS 主要基于 FIFO 队列（即先进先出队列）的方式来管理线程之间的竞争和等待。它的核心思想是将等待线程封装成一个 FIFO 的队列，当某个线程需要获取锁而锁已经被其他线程占用时，该线程会被封装成一个节点（Node）并加入到等待队列中，然后被阻塞。当锁被释放时，AQS 会从队列中选择一个线程唤醒，使其尝试获取锁。

AQS 的设计允许开发者通过实现不同的方法来定制同步器的行为，其中最重要的方法包括 tryAcquire() 和 tryRelease()，它们分别用于尝试获取和释放锁。通过重写这些方法，开发者可以创建各种不同类型的锁和同步器。

AQS

class AQS{
private volatile int state;
//借助 FIFO 队列管理线程
private static class Node {
volatile Node prev;
volatile Node next;
Thread thread;

    Node(Thread thread) {
        this.thread = thread;
    }
}

private volatile Node head;
private volatile Node tail;

}
它使用了一个简单的双向链表来存储等待获取锁的线程，通过一个条件变量 Condition 来实现线程的等待和唤醒。当线程尝试获取锁时，它会加入到链表的尾部，如果发现自己不是头结点，则进入等待状态；当释放锁时，它会从链表头部移除，并唤醒下一个等待线程。

乐观锁和悲观锁

在这里插入图片描述

// ------------------------- 悲观锁的调用方式 -------------------------
// synchronized
public synchronized void testMethod() {
	// 操作同步资源
}
// ReentrantLock
private ReentrantLock lock = new ReentrantLock(); // 需要保证多个线程使用的是同一个锁
public void modifyPublicResources() {
	lock.lock();
	// 操作同步资源
	lock.unlock();
}

// ------------------------- 乐观锁的调用方式 -------------------------
private AtomicInteger atomicInteger = new AtomicInteger();  // 需要保证多个线程使用的是同一个AtomicInteger
atomicInteger.incrementAndGet(); //执行自增1（通过CAS）

atomicInteger是CAS，通过CPU的cmpxchg指令，去比较寄存器中的 A 和内存中的值 V。如果相等，就把要写入的新值 B 存入内存中。如果不相等，就将内存值 V 赋值给寄存器中的值 A。然后通过Java代码中的while循环再次调用cmpxchg指令进行重试，直到设置成功为止。

自旋

在这里插入图片描述
AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作

无锁

无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

无锁的特点就是修改操作在循环内进行，线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出，否则就会继续循环尝试。如果有多个线程修改同一个值，必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。上面我们介绍的CAS原理及应用即是无锁的实现。无锁无法全面代替有锁，但无锁在某些场合下的性能是非常高的。

偏向锁

在大多数情况下，锁总是由同一线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。

如果此时有其他线程尝试获取这个对象的偏向锁，会检查对象头的 Mark Word 中记录的线程ID是否就是当前线程ID，如果不是，则会撤销偏向锁。

轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。

偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态。撤销偏向锁后恢复到无锁（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

偏向锁先撤销，再决定变为什么锁。

偏向锁撤销后，对象的状态会根据竞争情况而变化，可能会有以下几种情况：

用线程转储（Thread Dump）来观察正在竞争锁的线程以及它们的状态。

膨胀为轻量级锁：如果多个线程同时尝试获取对象锁，那么偏向锁就会被撤销并升级为轻量级锁。此时，竞争线程会尝试使用CAS（比较并交换）来尝试获取锁，如果竞争激烈，就会进一步升级为重量级锁。
竞争失败后进入自旋：在偏向锁被撤销后，如果对象没有升级为轻量级锁，那么其他线程可能会进入自旋状态，即在一个循环内快速尝试获取锁，以避免进入阻塞状态。自旋可以减少进入阻塞状态带来的线程切换开销。
标记为重量级锁：如果自旋超过阈值或者其他线程获取锁失败，那么对象可能会被标记为重量级锁，此时获取锁的线程将进入阻塞状态，等待被唤醒。

轻量级锁

是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，然后拷贝对象头中的Mark Word复制到锁记录中。

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。

如果轻量级锁的更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明多个线程竞争锁。

若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。

重量级锁

升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

整体的锁状态升级流程如下：

无锁

无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。

偏向锁

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

在大多数情况下，锁总是由同一线程多次获得，不存在多线程竞争，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。

当一个线程访问同步代码块并获取锁时，会在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。

偏向锁在JDK 6及以后的JVM里是默认启用的。可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，关闭之后程序默认会进入轻量级锁状态。

轻量级锁

是指当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。

重量级锁

升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

整体的锁状态升级流程如下：
在这里插入图片描述

可重入锁 VS 非可重入锁

Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。
一个类中synchronized修饰的方法a和方法b，在方法a中可以递归调用方法a或者b，都不会阻塞死锁。
ReentrantLock和NonReentrantLock都继承父类AQS，其父类AQS中维护了一个同步状态status来计数重入次数，status初始值为0。
在这里插入图片描述

读写锁

在最开始提及AQS的时候我们也提到了state字段（int类型，32位），该字段用来描述有多少线程获持有锁。

在独享锁中这个值通常是0或者1（如果是重入锁的话state值就是重入的次数），在共享锁中state就是持有锁的数量。但是在ReentrantReadWriteLock中有读、写两把锁，所以需要在一个整型变量state上分别描述读锁和写锁的数量（或者也可以叫状态）。于是将state变量“按位切割”切分成了两个部分，高16位表示读锁状态（读锁个数），低16位表示写锁状态（写锁个数）。
在这里插入图片描述