java多线程基础（volatile、synchronized、Lock）

java多线程基础（volatile、synchronized、Lock）

java多线程安全性问题简单分析

并发编程模型的两个关键问题：
1.线程间的通信： java线程间通信是通过共享变量来解决的，所以我们主要解决的是java内存可见性问题
2.同步：同步是指程序中用于控制不同线程间操作发生相对顺序的机制。
下面分析一下问题原因和在java中出现这两个问题的解决方案。
java解决多线程内存可见性问题
  • 问题原因分析： 在cpu工作的中，每个线程都会一个独立的缓存（就CPU的一级缓存二级缓存），而cpu为了提高工作效率，在运算中只操作缓存中的数据，之后在异步的刷到主内存中（jvm）。如下图，线程A修改了某个全局变量，它只能保证线程A缓存中的变量值是正确的，线程A缓存的变量值什么时候刷新到主内存中这个是不确定的，如果线程A修改了变量值没有及时刷新道主内存中，线程B正好用到线程A修改的变量，这个时候线程B缓存的变量值就是错误的。
image.png
如下代码：

    public class Test {
        private volatile static int i = 0;
        public static void main(String[] args) throws InterruptedException {
            new Thread() {
                @Override
                public void run() {
                    while (i == 0){

                    }
                }
            }.start();

            Thread.sleep(1000);
            i = 1;
        }

    }

上面代码：我们把main线程当做图中A线程，new Thread().start(); 当做图中的B线程，i是全局变量。运行结果B线程会线图死循环中，因为A线程修改了i,没有刷新到主内存中所以B线程看到的i一直是0。

  • 内存可见性问题解决方案：
    1.变量增加volatile
    2.CAS操作变量，本质也是用到的volatile（原子类：AtomicInteger、AtomicLong、Atomic*...）
    3.synchronized,到这我们都会有个疑问synchronized是jvm级别的一个锁，为什么锁会解决内存可见性问题，等我们分析JMM的时候就清楚了。
java解决多线程同步问题
  • 问题现状: 在系统并行执行时经常会遇见某一个操作或者一组操作是线程之间互斥的，例如：队列的入列和出列、栈的压栈 出栈等。这时就需要用到java的锁来实现同步功能。
  • 同步问题解决方案：~~~~
    1.synchronized 锁实现同步 例子：Hashtable、Vector、StringBuffer
    2.Lock 锁实现同步 例子： jdk1.7 ConcurrentHashMap

volatile

volatile简介
volatile主要作用是解决全局变量多线程之间可见性问题，在多线程中一个变全局量被volatile修饰了，一个线程修改了该变量，其它线程会立刻感知到。
volatile实现原理

java代码：

    instance = new Singleton(); // instance 是 volatile变量

转变成汇编代码：

0x01a3de1d: movb $0×0,0×1104800(%esi);
0x01a3de24: lock addl $0×0,(%esp);

我们可以看到有volatile修饰的变量进行写的时候会多出第二行汇编代码。我们说一下这个第二行代码lock都干了什么事：
1.Lock前缀指令会引起处理器缓存会写到内存
2.一个处理器的缓存会写到内存会导致其他处理的缓存无效，CPU使用嗅探技术保证它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。

synchronized

synchronized简介
synchronized，jvm实现的同步锁，当一个线程执行到synchronized的时，需要先获取到锁，退出或异常时会释放锁。
synchronized三种形态
  • 对于普通同步方法，锁的是当前实例类对象

  • 对于静态同步方法，锁的是当前类的Class对象

  • 对于同步方法快，所得是synchronized括号里面配置的对象。
synchronized实现原理
JVM基于进入和退出monitor对象来实现方法同步和代码块同步，但是两者实现的细节不一线，代码块同步是使用monitorrenters和
monitorexit指令实现的，方法同步是ACC_SYNCHRONIZED标示实现的。下面我们看一下synchronized实现的同步的代码。

java代码：

public class Test {

   public synchronized void fun1(){
       int i = 1;
   }

   public void fun2(){

       synchronized (this){
           try{
               int i = 1;
           }catch (Exception e){

           }
       }

   }
}

上述java代码 fun1方法是synchronized方法同步的例子，fun2是synchronized代码块同步的例子。我们把这个类变异成class，看一看这个类的字节码信息。

public io.netty.example.Test();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 3: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lio/netty/example/Test;

  public synchronized void fun1();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=1, locals=2, args_size=1
         0: iconst_1
         1: istore_1
         2: return
      LineNumberTable:
        line 6: 0
        line 7: 2
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       3     0  this   Lio/netty/example/Test;
            2       1     1     i   I

  public void fun2();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=4, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter
         4: iconst_1
         5: istore_2
         6: goto          10
         9: astore_2
        10: aload_1
        11: monitorexit
        12: goto          20
        15: astore_3
        16: aload_1
        17: monitorexit
        18: aload_3
        19: athrow
        20: return
      Exception table:
         from    to  target type
             4     6     9   Class java/lang/Exception
             4    12    15   any
            15    18    15   any
      LineNumberTable:
        line 11: 0
        line 13: 4
        line 16: 6
        line 14: 9
        line 17: 10
        line 19: 20
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      21     0  this   Lio/netty/example/Test;
      StackMapTable: number_of_entries = 4
        frame_type = 255 /* full_frame */
          offset_delta = 9
          locals = [ class io/netty/example/Test, class java/lang/Object ]
          stack = [ class java/lang/Exception ]
        frame_type = 0 /* same */
        frame_type = 68 /* same_locals_1_stack_item */
          stack = [ class java/lang/Throwable ]
        frame_type = 250 /* chop */
          offset_delta = 4

在上面class文件中我们可以看出来
fun1方法同步在flags后面有个标志ACC_SYNCHRONIZED来描述此方法是同步方法需要现获取锁。
fun2方法中我们我可看到在CODE 3 , 11 , 17 处，有个monitorenter，monitorexit ，分别对应 monitorenter 获取锁，11 monitorexit正常退出释放锁，17 monitorexit 异常退出释放锁。

通过上面我们知道了synchronized 方法同步是通过ACC_SYNCHRONIZED 实现获取锁和释放锁，代码块同步是通过 monitorenter，monitorexit两个指令实现获取锁和释放锁。

synchronized的锁是存在java对象头里的。我们来看一下java对象头mark word的结构。

32位虚拟机：

image.png

64位虚拟机：

image.png

锁标志位：
01：偏向锁或者无锁
00：轻量级锁
10：重量级锁
11：GC标记
是否是偏向锁
0：否
1：是

java对象头mark word的状态变化：
无锁状态：

image.png

偏向锁：


image.png

轻量锁:


image.png

重量锁：


image.png

被GC标记过的mark word：


image.png

到这我们就应该明白了，synchronized是怎么控制锁的，所有机关都是对象mark word中。判断对象是否有锁先查看mark word里面的信息。 获取锁和释放锁都会修改mark word 信息。

synchronized锁升级

  • 偏向锁
    简单的讲就是在对象头上记录threadId, 第一次获取锁如果将NULL替换成当前线程的threadId，下次在获取锁的时候发现threadid是一样的就可以直接认为当前线程获取到了锁，忽略了轻量锁和重量锁提高了加锁效率。偏向锁使用了一种等到竞争出现才释放锁的机制，所以其他线程尝试竞争偏向锁是，持有偏向锁的线程才会释放。偏向锁的撤销，需要等待全局安全点（线程暂停,在这个时间点上没有正在执行的字节码）。
    偏向锁获取和撤销流程


    image.png

  • 轻量锁、重量级锁
    轻量锁：轻量锁是通过CAS把Mark Word更新成指向栈中所记录指针（有心的可以看一下C++的代码 ， 获取锁的时候会创建一个BasicLock的对象，Mark Word 记录的就是这个对象的指针），所标记更新成00，更新失败会有一个自旋的过程，通过-XX:PreBlockSpin=10来设置自旋次数，默认是10次。
    重量锁：重量级锁是把Mark Word更新成monitor对象指针。通过monitor对象来维护锁的等待和获取。

    monitor对象关键属性：
    _recursions： 重入锁的次数
    _owner： 当前持有所得线程
    _WaitSet：等待线程组成的双向循环链表，_WaitSet是第一个节点
    _cxq： 多线程竞争锁进入时的单向链表
    _EntryList: _owner从该双向循环链表中唤醒线程结点，_EntryList是第一个节点
    java底层维护了一个两个队列一个是待获取锁队列一个是等待队列，_owner属性表示当前持有锁的线程。谁先占有_owner属性谁就获取到线程锁，队列响应就会移出去一个节点。

    锁膨胀流程图：

image.png

  • 偏向锁、轻量锁、重量锁升级过程

    来自网上的一张图讲述了偏向锁到轻量锁再到重量锁全部过程， 很NB分享一下。


    image.png

Lock

Lock简介
synchronized是JVM实现的锁，Lock是JDK实现的锁，提供了雨synchronized关键字类似的功能，只是需要显示的获取或和释放锁。虽然Lock锁少了隐式获取锁释放锁的便捷性，但是却拥有获取锁与释放锁的操作性、可中断性已经超时获取锁等多种。Lock支持ReentranLock可重入锁，ReentrantReadWriteLock可重入读写锁，以上两个锁都支持公平非公平两种模式。
Lock接口Api
image.png
Lock实现原理
AQS 简介
Lock锁实现主要依赖的是AbstarctQueuedSynchronized（简称AQS）同步器是实现的锁的一系列功能，我们来分析一下AQS的主要代码。
AQS->方法概述

可重写方法：


image.png

模板方法：


image.png
AQS->关键属性

/* 等待队列链表头节点 AQS用的双向链表做的FIFO队列 /
private transient volatile Node head;
/ 等待队列链表尾节点 */
private transient volatile Node tail;

/* 同步状态: 锁没有被线程获取时是0 */
private volatile int state;

AQS->Node属性介绍
 final class Node {
        /** 标记共享节点 */
        static final Node SHARED = new Node();
        /** 标记独占节点 */
        static final Node EXCLUSIVE = null;
        /**
         * 节点等待状态
         *
         * CANCELLED =  1;
         * 由于队列中的等待的线程等待超时或者中断，需要从同步队列中取消等待，节点进入该状态不会变化
         *
         * SIGNAL    = -1;
         * 后续几点处于等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后续节点，是后续节点的线程得以运行
         *
         * CONDITION = -2;
         * 节点在等待队列中，节点线程在Condition上，当其他线程对Condition调用了signal方法后，该节点将会从等待队列中转义到同步队列中，加入到对同步状态的获取中
         *
         * PROPAGATE = -3;
         * 表示下一次共享式同步状态获取将会无条件地传播下去
         *
         * 0  初始状态
         */
        volatile int waitStatus;

        /**
         * 队列上一个节点
         */
        volatile Node prev;

        /**
         * 队列下一个节点
         */
        volatile Node next;

        /**
         * 当前获取节点线程
         */
        volatile Thread thread;

        /**
         * 下一个等待节点
         */
        Node nextWaiter;

    }
独占锁
  • 独占锁状态获取
public final void acquire(int arg) {
        // tryAcquire 尝试获取锁如果成功直接退出
        // addWaiter 创建节点并添加到队列尾部（EXCLUSIVE 表示独占节点）
        // acquireQueued 采用死循环方式获取同步状态，为获取到活执行park线程阻塞
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

addWaiter创建等待节点，添加至等待队列尾部：

        /**
    * 节点添加至队列尾部 mode： SHARED，EXCLUSIVE 共享独占两种方式
    */
    private Node addWaiter(Node mode) {
        // 创建节点对象
        Node node = new Node(Thread.currentThread(), mode);
        // tail 队列尾节点
        Node pred = tail;
        
        if (pred != null) {
            // 新节点前序节点指向 tail节点
            node.prev = pred;
            // 通过CAS 方式替换尾部节点
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        //  tail为空 或者 CAS 失败循环添加节点到队列尾部
        enq(node);
        return node;
    }

        /**
    * 循环通过CAS方式添加节点至队列尾部，
    */
    private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) { // tail 是空初始队列
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
                node.prev = t;
                // 通过CAS 方式替换尾部节点
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

acquireQueued 获取同步状态：

/**
    *   FIFO队列获取同步状态
    */
    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                // 当前节点的前序节点
                final Node p = node.predecessor();
                // 如果前序节点是头节点 尝试获取同步状态
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                // shouldParkAfterFailedAcquire 通过waitStatus判断线程是否需要阻塞  
                // parkAndCheckInterrupt 阻塞线程
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            // 执行了interrupt 终止线程，撤销获取同步状态
            if (failed)
                cancelAcquire(node);
        }
    }
    
    /**
    * 通过waitStatus判断线程是否需要阻塞
    */
    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        // 前序节点是等待状态 当前节点返回阻塞
        if (ws == Node.SIGNAL)
            return true;
        // 前序节点放弃了获取同步状态继续往前找节点 
        if (ws > 0) {
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            // CAS 替换节点为 等待状态， 如果成功阻塞线程
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }
  • 独占锁释放
/**
    * 释放锁
    */
    public final boolean release(int arg) {
        // 同步状态 归0
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                // 初始等待状态 获取下一个节点 并唤醒线程
                unparkSuccessor(h);
            return true;
        }
        return false;
    }
    
    
    /**
    *   初始等待状态、唤后序节点醒线程
    */
    private void unparkSuccessor(Node node) {
        
        int ws = node.waitStatus;
        // 等待状态初始为0
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        // 获取下一个节点
        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)
                    s = t;
        }
        if (s != null)
            // 唤醒阻塞线程
            LockSupport.unpark(s.thread);
    }
获取共享锁
  • 共享锁状态获取
/**
    * 创建共享模式等待节点 ，死循环获取同步状态，获取失败阻塞线程
    */
    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) {
                    // 尝试获取共享锁 大于0 获取成功
                    int r = tryAcquireShared(arg);
                    if (r >= 0) {
                        // 向后传播共享模式同步状态
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                // shouldParkAfterFailedAcquire 通过waitStatus判断线程是否需要阻塞  
                // parkAndCheckInterrupt 阻塞线程
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }
  • 共享模式同步状态释放
public final boolean releaseShared(int arg) {
        // 释放同步状态
        if (tryReleaseShared(arg)) {
            // 唤醒等待线程
            doReleaseShared();
            return true;
        }
        return false;
    }
    
    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;   
                    unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;
            }
            if (h == head)   
                break;
        }
    }
AQS->公平锁、非公平锁

ReentrantLock来说公平锁和非公平锁。
公平锁：公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。
优点：保证时间顺序获取锁，锁获取相对公平，不会有线程饥饿问题 缺点：效率低会频繁的CPU上下文切换
非公平锁： 只要CAS成功就获取到锁，不按照时间顺序获取说
有点：效率高 缺点：会产生线程饥饿

公平锁获取源码分析：

/**
    * 公平锁
    */
    static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
            // 直接执行AQS获取同步状态方法、严格按照FIFO顺序获取锁
            acquire(1);
        }

        
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            // 可重入锁 如果当前线程和以获取锁的线程是一个 可以再次获取锁
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

非公平锁源码分析：

/**
    * 非公平锁
    */
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

       
        final void lock() {
            // 先更新一个同步锁的状态，成功就获取到锁，不成功在行AQS获取锁的方法
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
    }
    
    
    final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
重入锁

ReentrantLock 可重入锁,用的AQS独占锁。

读写锁

ReentrantReadWriteLock 可重入读写锁。读写锁和可重入锁不同的是：
1.写锁用的是AQS的独占锁，读锁用AQS的共享锁；
2.锁状态区分读写锁：高16位表示读锁， 低16位表示写锁


image.png

源码分析一下读锁的实现，写锁是低16位标示的实现和上面的可重入锁基本一致。我们只分析锁的获取即可：

/**
        * 尝试获取读锁
        */
        protected final int tryAcquireShared(int unused) {
            Thread current = Thread.currentThread();
            int c = getState();
            /**
            *exclusiveCount (c & ((1 << SHARED_SHIFT) - 1)) 返回非0标示已经有写锁占用  
            *getExclusiveOwnerThread() != current 判断已获取读锁的线程和当前线程不是一个线程 
            *返回-1 获取锁失败
            */ 
            if (exclusiveCount(c) != 0 &&
                getExclusiveOwnerThread() != current)
                return -1;
            // 锁共享次数    
            int r = sharedCount(c);
            // readerShouldBlock 
            //  公平锁下：判断当前线程是否需要被阻塞 ，如果队列中有等待返回true 
            //  非公平锁下： 判断如果head 下一个节点是写锁， 先让写锁执行 避免写锁饥饿
            if (!readerShouldBlock() &&
            // 必须要小于最大获取锁次数
                r < MAX_COUNT &&
                // CAS 占用锁状态 
                compareAndSetState(c, c + SHARED_UNIT)) {
                
                // 到这了就标示已经获取到锁了
                if (r == 0) {
                    firstReader = current;
                    firstReaderHoldCount = 1;
                } else if (firstReader == current) {
                    firstReaderHoldCount++;
                } else {
                    HoldCounter rh = cachedHoldCounter;
                    if (rh == null || rh.tid != getThreadId(current))
                        cachedHoldCounter = rh = readHolds.get();
                    else if (rh.count == 0)
                        readHolds.set(rh);
                    rh.count++;
                }
                return 1;
            }
            
            // 循环获取锁 
            return fullTryAcquireShared(current);
        }
Condition源码分析
Api

Condition 提供了类似Object的wait/notify的方法和Lock配合使用


image.png
await线程等待源码分析

ConditionObject 类属性分析：

// 第一个等待节点
private transient Node firstWaiter;
/** 最末尾等待节点 */
private transient Node lastWaiter;

/** 可以看出来Condition,用链表做了一个等待对了。 */

await方法源码

/**
        * 持有LOCK线程进入阻塞状态 并释放锁
        */
        public final void await() throws InterruptedException {
            if (Thread.interrupted())
                throw new InterruptedException();
            // 创建等待节点
            Node node = addConditionWaiter();
            // 释放同步状态 并返回原同步状态值
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            // isOnSyncQueue 节点是否在同步队列中 在同步队列中的不能 wait
            while (!isOnSyncQueue(node)) {
                // 线程阻塞
                LockSupport.park(this);
                // 线程恢复 进入同步队列的带获取同步状态
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            // acquireQueued 获取同步状态
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // 
                // 清除等待队列的垃圾节点
                unlinkCancelledWaiters();
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }
signal线程等待源码分析

signal 源码：

public final void signal() {
            // 当前线程没有锁 则抛出异常
            if (!isHeldExclusively())
                throw new IllegalMonitorStateException();
            Node first = firstWaiter;
            if (first != null)
                // 真正的唤醒线程
                doSignal(first);
        }
        
        
        private void doSignal(Node first) {
            do {
                //清除第一个等待节点
                if ( (firstWaiter = first.nextWaiter) == null)
                    lastWaiter = null;
                first.nextWaiter = null;
                // transferForSignal 真正真正的唤醒线程
            } while (!transferForSignal(first) &&
                     (first = firstWaiter) != null);
        }
        
        final boolean transferForSignal(Node node) {
        // 节点等待状态 恢复初始状态  
        if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
            return false;

        // 等待节点添加到同步队列末尾，返回上一个等待节点
        Node p = enq(node);
        int ws = p.waitStatus;
        
        //ws > 0，同步状态未占用， 可以立即恢复线程
        //上一个节点 状态改成等待状态，标示当前节点就是head节点可以立即恢复线程
        if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
            // 恢复线程
            LockSupport.unpark(node.thread);
        return true;
        }

signalall源码：

private void doSignalAll(Node first) {
            // 等待队列收尾都值为空
            lastWaiter = firstWaiter = null;
            do {
                // 循环每个等待节点， 请求transferForSignal添加到等待队列或者 直接恢复线程
                Node next = first.nextWaiter;
                first.nextWaiter = null;
                transferForSignal(first);
                first = next;
            } while (first != null);
        }

想整理的基本就这么多，大部分是《java并发编程艺术》观后整理的一些东西， 一少部分是自己带着疑问去研究的。

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 211,348评论 6赞 491
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,122评论 2赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 156,936评论 0赞 347
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,427评论 1赞 283
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,467评论 6赞 385
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,785评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,931评论 3赞 406
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,696评论 0赞 266
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,141评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,483评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,625评论 1赞 340
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,291评论 4赞 329
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,892评论 3赞 312
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,741评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,977评论 1赞 265
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,324评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,492评论 2赞 348

推荐阅读更多精彩内容

  • 你说
    夜莺2517阅读 127,717评论 1赞 9
  • 送你一个晚安故事
    我是黑夜里大雨纷飞的人啊 1 “又到一年六月，有人笑有人哭，有人欢乐有人忧愁，有人惊喜有人失落，有的觉得收获满满有...
    陌忘宇阅读 8,529评论 28赞 53
  • 2015.9.17-盐鸭蛋
    兔子虽然是枚小硕 但学校的硕士四人寝不够 就被分到了博士楼里 两人一间 在学校的最西边 靠山 兔子的室友身体不好 ...
    待业的兔子阅读 2,593评论 2赞 9
  • 信任重要性
    信任包括信任自己和信任他人 很多时候，很多事情，失败、遗憾、错过，源于不自信，不信任他人 觉得自己做不成，别人做不...
    吴氵晃阅读 6,186评论 4赞 8