线程是否要锁住同步资源
- 锁住 乐观锁
- 不锁住 乐观锁
锁住同步资源失败 线程是否要阻塞
- 阻塞
- 不阻塞自旋锁，适应性自旋锁
多个线程竞争同步资源的流程细节有没有区别
- 不锁住资源，多个线程只有一个能批改资源胜利，其它线程会重试无锁
- 同一个线程执行同步资源时主动获取资源偏差锁
- 多个线程竞争同步资源时，没有获取资源的线程自旋期待锁开释 轻量级锁
- 多个线程竞争同步资源时，没有获取资源的线程阻塞期待唤醒 重量级锁
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！文章都会在外面更新，整顿的材料也会放在外面。谢谢你的观看!
发表回复