线程是否要锁住同步资源
- 锁住 乐观锁
- 不锁住 乐观锁
锁住同步资源失败 线程是否要阻塞
- 阻塞
- 不阻塞自旋锁，适应性自旋锁
多个线程竞争同步资源的流程细节有没有区别
- 不锁住资源，多个线程只有一个能批改资源胜利，其它线程会重试无锁
- 同一个线程执行同步资源时主动获取资源偏差锁
- 多个线程竞争同步资源时，没有获取资源的线程自旋期待锁开释 轻量级锁
- 多个线程竞争同步资源时，没有获取资源的线程阻塞期待唤醒 重量级锁
4. 多个线程竞争锁时是否要排队
- 排队偏心锁
- 先尝试插队，插队失败在排队非偏心锁
一个线程的多个流程能不能获取同一把锁
- 能 可重入锁
- 不能非可重入锁
多个线程能不能共享一把锁
- 能 共享
- 不能排他锁
乐观锁与乐观锁
乐观锁与乐观锁时一种狭义的概念，体现的是对待线程同步的不同角度。
乐观锁
乐观锁认为本人在应用数据的时候肯定有别的线程来批改数据，在获取数据的时候会先加锁，确保数据不会被别的线程批改。
锁实现：synchronized 接口 Lock 的实现类
实用场景：写操作多，先加锁能够保障写操作时数据正确。
乐观锁
乐观锁认为本人在应用数据时不会有别的线程批改数据，所以不会增加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。
锁实现：CAS算法，例如 AtomicInteger 类的原子自增时通过 CAS 自旋实现。
实用场景：读操作较多，不加锁的特点可能使其读操作的性能大幅度晋升。
乐观锁的执行流程：
线程 A 获取到数据当前间接操作，操作完数据当前筹备更新同步资源，更新之前会先判断内存中同步资源是否被更新：
1. 如果没有被更新，更新内存中同步资源的值。
2. 如果同步资源被其余线程更新，依据实现办法执行不同的操做(报错 or 重试)。
CAS 算法
全名：Compare And Swap（比拟并替换）
无锁算法：基于硬件原语实现，在不应用锁 (没有线程被阻塞) 的状况下实现多线程之间的变量同步。
jdk 中的实现：java.util.concurrent 包中的原子类就是通过 CAS 来实现了乐观锁。
算法波及到的三个操作数：
须要读写的内存值 V
进行比拟的值 A
要写入的新值的 B
CAS 存在的问题
1.ABA 问题
线程 1 筹备用 CAS 将变量的值由 A 替换为 B，在此之前，线程 2 将变量的值由 A 替换为 C，又由 C 替换为 A，而后线程 1 执行 CAS 时发现变量的值依然为 A，所以 CAS 胜利。但实际上这时的现场曾经和最后不同了，只管 CAS 胜利，但可能存在潜藏的问题。
举例：一个小偷，把他人家的钱偷了之后又还了回来，还是原来的钱吗，你老婆出轨之后又回来，还是原来的老婆吗？ABA 问题也一样，如果不好好解决就会带来大量的问题。最常见的就是资金问题，也就是他人如果挪用了你的钱，在你发现之前又还了回来。然而他人却曾经触犯了法律。
然而 jdk 曾经解决了这个问题。
想追下源码来着，然而一追发现间接到 c 了。
2. 循环工夫长开销大
3. 只能保障一个共享变量的原子操作
Unsafe
AtomicInteger
public final int incrementAndGet() {for (;;) {int current = get();
int next = current + 1;
if (compareAndSet(current, next))
return next;
}
}
public final boolean compareAndSet(int expect, int update) {return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}
从这里可见原子类的办法调用了 unsafe 类的办法unsafe
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
再往底层的话，理论加上就到了 C。
最终的实现就是 cmpxchg = cas 批改变量值
lock cmpxchg 指令
硬件：
lock 指令在执行前面指令的时候锁定一个北桥信号（不采纳锁总线的形式）
自旋锁
是指当一个线程在获取锁的时候，如果锁曾经被其余线程获取，那么该线程将循环期待，而后一直的判断锁是否可能被胜利获取，自旋直到获取到锁才会退出循环。
自旋存在的意义与应用场景
阻塞与唤醒线程须要操作系统切换 CPU 状态，须要耗费肯定工夫。
同步代码块逻辑简略，执行工夫很短。
自适应自旋锁假设不同线程持有同一个锁对象的工夫根本相当，竞争水平趋于稳定，因而，能够依据上一次自旋的工夫与后果调整下一次自旋的工夫。
JDK>=1.7 自旋锁的参数被勾销，虚拟机不再反对由用户配置自旋锁，自旋锁总是会执行，自旋锁次数也是由虚拟机主动调整。
锁降级
锁降级流程
jdk6 的时候对锁进行了很多优化，其中就有了锁的降级过程。
1. 偏差锁：只有一个线程进入临界区，实用于只有一个线程拜访同步块的场景
2. 轻量级锁：多线程为竞争或者竞争不强烈，实用于谋求响应工夫，同步块执行速度十分快。3. 重量级锁：多线程竞争，实用于谋求吞吐量，同步块执行速度较长。JVM 对象加锁的原理
对象的内存构造？
对象头：比方 hash 码，对象所属的年代，对象锁，锁状态标记，偏差锁（线程）ID，偏差工夫，数组长度（数组对象）等。
实例数据：创建对象时，对象中的成员变量，办法等。
对齐填充：就为了凑够 8 的倍数。
利用一个插件，比照对象上锁前后的差别：
<dependencies>
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
</dependencies>
public static void main(String[] args) {Object o = new Object();
System.out.println(ClassLayout.parseInstance(o).toPrintable());
System.out.println("===============================================");
synchronized (o){System.out.println(ClassLayout.parseInstance(o).toPrintable());
}
}
实例对象是怎么存储的？
对象实例存储在堆空间，对象的元数据存在元空间，对象援用存在栈空间。
锁打消
/**
* @author yhd
* @createtime 2020/9/8 20:40
*/
public class Demo2 {public static void main(String[] args) {StringBuffer buffer = new StringBuffer();
buffer.append("a").append("b");
System.out.println(ClassLayout.parseInstance(buffer).toPrintable());
}
}
咱们都晓得 StringBuffer 是线程平安的，因为他的要害办法都加了 synchronized，然而，从打印后果能够看出，锁被打消了。因为buffer 这个援用只会在 main 办法中应用，不可能被其余线程援用 (因为是局部变量，栈公有)，所以buffer 是不可能共享的资源，JVM会主动打消 StringBuffer 对象外部的锁。
锁粗化
/**
* @author yhd
* @createtime 2020/9/8 20:48
*/
public class Demo3 {public static void main(String[] args) {
int i=0;
StringBuffer buffer = new StringBuffer();
while (i<100){buffer.append(i);
i++;
}
System.out.println(buffer.toString());
System.out.println(ClassLayout.parseInstance(buffer).toPrintable());
}
}
JVM会检测到这样一连串的操作都对同一个对象加锁（while 循环内 100 次执行 append，没有锁粗化的就要进行 100 次加锁 / 解锁），此时 JVM 就会将加锁的范畴粗化到这一连串的操作的内部（比方 while 空幻体外），使得这一连串操作只须要加一次锁即可。
AQS
钻研了 AQS 一天，终于找到了他的入口，接下来看我的想法：
多线程操做共享数据问题
/**
* @author yhd
* @createtime 2020/9/8 8:11
*/
public class Demo1 {
public static int m=0;
public static void main(String[] args)throws Exception {Thread []threads=new Thread[100];
for (int i = 0; i < threads.length; i++) {threads[i]=new Thread(()->{for (int j = 0; j < 100; j++) {m++;}
});
}
for (Thread t :threads) t.start();
for (Thread t :threads) t.join();// 线程程序完结
System.out.println(m);
}
}
毫无疑问，这段代码是存在线程平安问题的，只有理解一点并发编程，都是能够看进去的。那么咱们能够怎么来解决呢？
应用 synchronized 来解决
/**
* @author yhd
* @createtime 2020/9/8 8:32
*/
public class Demo2 {
public static int m=0;
public static void main(String[] args)throws Exception {Thread []threads=new Thread[100];
for (int i = 0; i < threads.length; i++) {threads[i]=new Thread(()->{synchronized (Demo2.class) {for (int j = 0; j < 100; j++) {m++;}
}
});
}
for (Thread t :threads) t.start();
for (Thread t :threads) t.join();// 线程程序完结
System.out.println(m);
}
这样解决了线程平安的问题，然而同时也存在一个问题，synchronized 是操作系统层面的办法，也就是须要 jvm 和操做零碎之间进行一个切换(用户态和内核态的切换)，这样实际上是影响效率的。另一种解决办法：
应用 ReentrantLock 来解决
/**
* @author yhd
* @createtime 2020/9/8 8:41
*/
public class Demo3 {
public static int m=0;
public static Lock lock=new ReentrantLock();
public static void main(String[] args)throws Exception {Thread []threads=new Thread[100];
for (int i = 0; i < threads.length; i++) {threads[i]=new Thread(()->{
try {lock.lock();
for (int j = 0; j < 100; j++) {m++;}
} finally {lock.unlock();
}
});
}
for (Thread t :threads) t.start();
for (Thread t :threads) t.join();// 线程程序完结
System.out.println(m);
}
}
那么这种形式的底层是怎么做的呢？接下来追源码。
public ReentrantLock() {sync = new NonfairSync();
}
这个 sync 又是啥呢？接着追
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {return nonfairTryAcquire(acquires);
}
}
它实际上是 ReentrantLock 的一个外部类继承了 Sync，而他外面的办法实际上也是调用了Sync 的办法。这样指标就明确了，咱们能够看一下 Sync。
这个 Sync 的源码：
abstract static class Sync extends AbstractQueuedSynchronizer
由此可知，实际上 ReentrantLock 是利用 AbstractQueuedSynchronizer 也就是 AQS 来实现的。
AbstractQueuedSynchronizer 概述
这个类的外部有一个外部类Node
static final class Node {static final Node SHARED = new Node();
volatile Node prev;// 前驱指针
volatile Node next;// 后继指针
volatile Thread thread;// 以后线程
private transient volatile Node head;// 头节点
private transient volatile Node tail;// 尾节点
private volatile int state;// 锁状态，加锁胜利则为 1，重入 +1 解锁则为 0
.....
}
看到这里就想到了LinkedHashMap，实际上也就是相似于维持了一个双向的链表，每个节点都是一个线程。
它保护了一个 volatile int state（代表共享资源）和一个 FIFO 线程期待队列（多线程争用资源被阻塞时会进入此队列）。这里 volatile 是外围关键词，具体 volatile 的语义，在此不述。state 的拜访形式有三种:
getState()
setState()
compareAndSetState()
AQS定义两种资源共享形式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。
不同的自定义同步器争用共享资源的形式也不同。自定义同步器在实现时只须要实现共享资源 state 的获取与开释形式即可，至于具体线程期待队列的保护（如获取资源失败入队 / 唤醒出队等），AQS 曾经在顶层实现好了。自定义同步器实现时次要实现以下几种办法：
`isHeldExclusively()`：该线程是否正在独占资源。只有用到 condition 才须要去实现它。`tryAcquire(int)`：独占形式。尝试获取资源，胜利则返回 true，失败则返回 false。`tryRelease(int)`：独占形式。尝试开释资源，胜利则返回 true，失败则返回 false。`tryAcquireShared(int)`：共享形式。尝试获取资源。正数示意失败；0 示意胜利，但没有残余可用资源；负数示意胜利，且有残余资源。`tryReleaseShared(int)`：共享形式。尝试开释资源，如果开释后容许唤醒后续期待结点返回 true，否则返回 false。以 ReentrantLock 为例，state 初始化为 0，示意未锁定状态。A 线程 lock()时，会调用 tryAcquire() 独占该锁并将 state+1。尔后，其余线程再 tryAcquire() 时就会失败，直到 A 线程 unlock()到 state=0（即开释锁）为止，其它线程才有机会获取该锁。当然，开释锁之前，A 线程本人是能够反复获取此锁的（state 会累加），这就是可重入的概念。但要留神，获取多少次就要开释如许次，这样能力保障 state 是能回到零态的。
再以 CountDownLatch 以例，工作分为 N 个子线程去执行，state 也初始化为 N（留神 N 要与线程个数统一）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown() 一次，state 会 CAS 减 1。等到所有子线程都执行完后 (即 state=0)，会unpark() 主调用线程，而后主调用线程就会从 await()函数返回，持续后余动作。
一般来说，自定义同步器要么是独占办法，要么是共享形式，他们也只需实现 tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也反对自定义同步器同时实现独占和共享两种形式，如ReentrantReadWriteLock。
源码解读与执行流程剖析
独占锁
acquire(int)==
此办法是独占模式下线程获取共享资源的顶层入口。如果获取到资源，线程间接返回，否则进入期待队列，直到获取到资源为止，且整个过程疏忽中断的影响。这也正是 lock()的语义，当然不仅仅只限于 lock()。获取到资源后，线程就能够去执行其临界区代码了。
public final void acquire(int arg) {if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();}
函数流程如下：
tryAcquire()尝试间接去获取资源，如果胜利则间接返回；addWaiter()将该线程退出期待队列的尾部，并标记为独占模式；acquireQueued()使线程在期待队列中获取资源，始终获取到资源后才返回。如果在整个期待过程中被中断过，则返回 true，否则返回 false。如果线程在期待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断 selfInterrupt()，将中断补上。
tryAcquire(int)
此办法尝试去获取独占资源。如果获取胜利，则间接返回 true，否则间接返回 false。这也正是 tryLock()的语义，还是那句话，当然不仅仅只限于 tryLock()。
protected boolean tryAcquire(int arg) {throw new UnsupportedOperationException();
}
一开始还傻乎乎的想为啥间接抛异样了，起初才反馈过去，这不是给自定义的办法么？AQS 这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了。
addWaiter(Node)
此办法用于将以后线程退出到期待队列的队尾，并返回以后线程所在的结点。
private Node addWaiter(Node mode) {
// 以给定模式结构结点。mode 有两种：EXCLUSIVE（独占）和 SHARED（共享）Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
Node 结点是对每一个拜访同步代码的线程的封装，其蕴含了须要同步的线程自身以及线程的状态，如是否被阻塞，是否期待唤醒，是否曾经被勾销等。变量 waitStatus 则示意以后被封装成 Node 结点的期待状态，共有 4 种取值 CANCELLED、SIGNAL、CONDITION、PROPAGATE。
CANCELLED：值为 1，在同步队列中期待的线程期待超时或被中断，须要从同步队列中勾销该 Node 的结点，其结点的 waitStatus 为 CANCELLED，即完结状态，进入该状态后的结点将不会再变动。
SIGNAL：值为 -1，被标识为该期待唤醒状态的后继结点，当其前继结点的线程开释了同步锁或被勾销，将会告诉该后继结点的线程执行。说白了，就是处于唤醒状态，只有前继结点开释锁，就会告诉标识为 SIGNAL 状态的后继结点的线程执行。
CONDITION：值为 -2，与 Condition 相干，该标识的结点处于期待队列中，结点的线程期待在 Condition 上，当其余线程调用了 Condition 的 signal()办法后，CONDITION 状态的结点将从期待队列转移到同步队列中，期待获取同步锁。
PROPAGATE：值为 -3，与共享模式相干，在共享模式中，该状态标识结点的线程处于可运行状态。
0状态：值为 0，代表初始化状态。
AQS 在判断状态时，通过用 waitStatus>0 示意勾销状态，而 waitStatus<0 示意无效状态。
== enq(Node)==
此办法用于将 node 退出队尾。
private Node enq(final Node node) {for (;;) {// 自旋
Node t = tail;
if (t == null) { // Must initialize
// 队列为空，创立一个空的标记结点作为 head 结点，并将 tail 也指向它
if (compareAndSetHead(new Node()))
tail = head;
} else {// 失常放入队列尾部
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
cas 自旋 volatile 变量
acquireQueued(Node, int)
通过 tryAcquire()和 addWaiter()，该线程获取资源失败，曾经被放入期待队列尾部了。聪慧的你立即应该能想到该线程下一步该干什么了吧：进入期待状态劳动，直到其余线程彻底开释资源后唤醒本人，本人再拿到资源，而后就能够去干本人想干的事了。没错，就是这样！是不是跟医院排队拿号有点类似~~acquireQueued()就是干这件事：在期待队列中排队拿号（两头没其它事干能够劳动），直到拿到号后再返回。这个函数十分要害，还是上源码吧：
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;// 标记是否曾经拿到锁
try {
boolean interrupted = false;// 标记期待过程中是否被中断过
for (;;) {final Node p = node.predecessor();// 拿到前驱节点
// 如果前驱是 head，即该结点已成老二，那么便有资格去尝试获取资源（可能是老大开释完资源唤醒本人的，当然也可能被 interrupt 了）。if (p == head && tryAcquire(arg)) {setHead(node);
// 拿到资源后，将 head 指向该结点。所以 head 所指的标杆结点，就是以后获取到资源的那个结点或 null。p.next = null; // help GC
failed = false;
return interrupted;
}
// 如果本人能够劳动了，就进入 waiting 状态，直到被 unpark()
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;// 如果期待过程中被中断过，哪怕只有那么一次，就将 interrupted 标记为 true
}
} finally {if (failed)
cancelAcquire(node);
}
}
shouldParkAfterFailedAcquire(Node, Node)
此办法次要用于查看状态，看看本人是否真的能够去劳动了。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;// 拿到前驱的状态
if (ws == Node.SIGNAL)
// 如果曾经通知前驱拿完号后告诉本人一下，那就能够安心劳动了
return true;
if (ws > 0) {
/*
* 如果前驱放弃了，那就始终往前找，直到找到最近一个失常期待的状态，并排在它的后边。* 留神：那些放弃的结点，因为被本人“加塞”到它们前边，它们相当于造成一个无援用链，稍后就会被保安大叔赶走了(GC 回收)！*/
do {node.prev = pred = pred.prev;} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 如果前驱失常，那就把前驱的状态设置成 SIGNAL，通知它拿完号后告诉本人一下。有可能失败，人家说不定刚刚开释完呢！compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
整个流程中，如果前驱结点的状态不是 SIGNAL，那么本人就不能安心去劳动，须要去找个安心的劳动点，同时能够再尝试下看有没有机会轮到本人拿号。
parkAndCheckInterrupt()
如果线程找好平安劳动点后，那就能够安心去劳动了。此办法就是让线程去劳动，真正进入期待状态。
private final boolean parkAndCheckInterrupt() {LockSupport.park(this);
return Thread.interrupted();}
``
Thread.interrupted()会革除以后线程的中断标记位。== 整个获取锁的流程：==
1. 如果尝试获取锁胜利，间接返回。2. 没胜利，先退出到期待队列尾部，标记为独占模式。3. 尝试这获取一次锁后，如果还是获取不到就去劳动，有机会时（轮到本人，会被 unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个期待过程中被中断过，则返回 true，否则返回 false。4. 如果线程在期待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断 selfInterrupt()，将中断补上。** 这也就是 ReentrantLock.lock()的流程 **
==release(int)==
此办法是独占模式下线程开释共享资源的顶层入口。它会开释指定量的资源，如果彻底开释了（即 state=0）, 它会唤醒期待队列里的其余线程来获取资源。public final boolean release(int arg) {if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
// 唤醒期待队列里的下一个线程
return true;
}
return false;
}
** 它是依据 tryRelease()的返回值来判断该线程是否曾经实现开释掉资源了！所以自定义同步器在设计 tryRelease()的时候要明确这一点！！**
**tryRelease(int)**
此办法尝试去开释指定量的资源。protected boolean tryRelease(int arg) {throw new UnsupportedOperationException();
}
还是须要 AQS 的实现类本人去写。**unparkSuccessor(Node)**
此办法用于唤醒期待队列中下一个线程。private void unparkSuccessor(Node node) {
// 这里，node 个别为以后线程所在的结点。int ws = node.waitStatus;
if (ws < 0)
// 置零以后线程所在的结点状态，容许失败。compareAndSetWaitStatus(node, ws, 0);
// 找到下一个须要唤醒的结点 s
Node s = node.next;
if (s == null || s.waitStatus > 0) {// 如果为空或已勾销
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)// 从这里能够看出，<= 0 的结点，都是还无效的结点。s = t;
}
if (s != null)
LockSupport.unpark(s.thread);// 唤醒
}
用 unpark()唤醒期待队列中最前边的那个未放弃线程。** 开释锁的流程 **
1. 开释指定锁的资源并返回后果。2. 如果胜利开释，就唤醒期待队列中最前边的那个未放弃线程。3. 如果没胜利，返回 false。## 共享锁
public final void acquireShared(int arg) {if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
此办法用于将以后线程退出期待队列尾部劳动，直到其余线程开释资源唤醒本人，本人胜利拿到相应量的资源后才返回。private void doAcquireShared(int arg) {final Node node = addWaiter(Node.SHARED);
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {final Node p = node.predecessor();
if (p == head) {int r = tryAcquireShared(arg);
if (r >= 0) {// 胜利
setHeadAndPropagate(node, r);// 将 head 指向本人，还有残余资源能够再唤醒之后的线程
p.next = null; // help GC
if (interrupted)
selfInterrupt();
failed = false;
return;
}
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {if (failed)
cancelAcquire(node);
}
}
跟独占模式比，这里只有线程是 head.next 时（“老二”），才会去尝试获取资源，有残余的话还会唤醒之后的队友。那么问题就来了，如果老大用完后开释了 5 个资源，而老二须要 6 个，老三须要 1 个，老四须要 2 个。老大先唤醒老二，老二一看资源不够，他是把资源让给老三呢，还是不让？答案是否定的！老二会持续 park()期待其余线程开释资源，也更不会去唤醒老三和老四了。独占模式，同一时刻只有一个线程去执行，这样做未尝不可；但共享模式下，多个线程是能够同时执行的，当初因为老二的资源需求量大，而把前面量小的老三和老四也都卡住了。当然，这并不是问题，只是 AQS 保障严格依照入队程序唤醒罢了（保障偏心，但升高了并发）。== setHeadAndPropagate(Node, int)==
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();}
}
== doReleaseShared()==
private void doReleaseShared() {for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
unparkSuccessor(h);
}
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
if (h == head) // loop if head changed
break;
}
}
## 自定义锁
不同的自定义同步器争用共享资源的形式也不同。自定义同步器在实现时只须要实现共享资源 state 的获取与开释形式即可，至于具体线程期待队列的保护（如获取资源失败入队 / 唤醒出队等），AQS 曾经在顶层实现好了。自定义同步器实现时次要实现以下几种办法： isHeldExclusively()：该线程是否正在独占资源。只有用到 condition 才须要去实现它。tryAcquire(int)：独占形式。尝试获取资源，胜利则返回 true，失败则返回 false。tryRelease(int)：独占形式。尝试开释资源，胜利则返回 true，失败则返回 false。tryAcquireShared(int)：共享形式。尝试获取资源。正数示意失败；0 示意胜利，但没有残余可用资源；负数示意胜利，且有残余资源。tryReleaseShared(int)：共享形式。尝试开释资源，如果开释后容许唤醒后续期待结点返回 true，否则返回 false。
自定义一个简略的锁
/**
- @author yhd
- @createtime 2020/9/8 9:44
*/
public class MLock implements Lock {
private AbstractQueuedSynchronizer sync=new Sync();
@Override
public void lock() {sync.acquire(1);
}
@Override
public void lockInterruptibly() throws InterruptedException {}
@Override
public boolean tryLock() {return false;}
@Override
public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {return false;}
@Override
public void unlock() {sync.release(1);
}
@Override
public Condition newCondition() {return null;}
// 自定义一个独占锁
private class Sync extends AbstractQueuedSynchronizer {
@Override
protected boolean tryAcquire(int arg) {if (compareAndSetState(0, 1)) {setExclusiveOwnerThread(Thread.currentThread());
return true;
}
return false;
}
@Override
protected boolean tryRelease(int arg) {
assert arg == 1;
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
setExclusiveOwnerThread(null);
setState(0);
return true;
}
@Override
protected boolean isHeldExclusively() {return getExclusiveOwnerThread() == Thread.currentThread();}
}
}
Demo 测试：/**
- @author yhd
- @createtime 2020/9/8 9:36
*/
public class Demo6 {
public static int m = 0;
public static Lock lock = new MLock();
public static void main(String[] args) throws Exception {Thread[] threads = new Thread[100];
for (int i = 0; i < threads.length; i++) {threads[i] = new Thread(() -> {
try {lock.lock();
for (int j = 0; j < 100; j++) {m++;}
} finally {lock.unlock();
}
});
}
for (Thread t : threads) t.start();
for (Thread t : threads) t.join();// 线程程序完结
System.out.println(m);
}
}
## 最初
欢送大家关注我的公众号：** 前程有光 **，金九银十跳槽面试季，为大家整顿了 1000 多道 BATZ 面试题！将近 500 多页 pdf 文档的 Java 面试题材料放在外面，助你圆梦 BATZ！文章都会在外面更新，整顿的材料也会放在外面。谢谢你的观看!