Lock和ReentrantLock

最新推荐文章于 2022-09-02 16:58:54 发布
最新推荐文章于 2022-09-02 16:58:54 发布
阅读量520 收藏
点赞数
文章标签： java 开发语言 后端
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/iiiiiiiiiooooo/article/details/122982279
版权

JDK1.5中提供了锁的接口：java.util.concrrent.locks.lock,提供了ReentrantLock,ReentrankReadWriteLock实现类

Lock接口

Lock接口提供了比Synchronized方法更加灵活的锁的操作接口，可以具有很大的属性，支持多个相关Condition对象（线程间通信，Object方法提供的wait、notify、notifyall）

Lock接口提供的方法操作：

Lock()

void lock()

获取锁，如果锁被使用会一直阻塞直到获取到锁

LockInterruptibly()

void lockInterruptibly() throws InterruptedException

如果当前线程未被中断，则获取锁

如果锁可用，则获取锁，并立即返回，如果在加锁过程中发生了Interrupt中断操作，会抛出InterruptedException异常，并中断掉当前线程的加锁状态

tryLock()

boolean tryLock()

尝试获取锁，仅在调用时锁为空闲状态才获取锁，如果锁是可用的返回true，如果锁不可用，该方法会立即返回false

tryLock()

boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException

在指定时间内尝试性获取锁

unlock

void unlock()

释放锁，加锁和释放锁是成对出现的，对应于lock()、tryLock()、tryLock(xx)、lockInterruptibly()等操作，如果成功的话应该对应于一个unlock操作，这样可以避免死锁或者资源的浪费

newCondition()

Condition newCondition()

返回绑定到Lock实例的新的Condition实例，可以进行线程间通信

AQS

AQS（AbstractQueueSynchronizer）是J.U.C下较复杂的一个类，提供了一个为实现依赖于先进先出（FIFO）等待队列的阻塞锁和相关同步器（信号量、事件，等等）提供了一个框架。

通过上面查看类的子类的层级关系可知：AQS是CountdownLatch、ReentrankLock、threadPoolExecutor、ReentrantReadWriterLock和Semaphore实现的基础。

AQS存在的必要性

上图中体现AQS很重要的概念：“阻塞队列”，当线程无法获取资源时，提供一个FIFO类型的有序队列，用于维护所有处于“等待中”的线程

AQS核心字段：

主要有三个核心字段：

private transient volatile Node head;
private transient volatile Node tail;
private volatile int state;

其中state是描述有多少个线程获取锁

state=0：表示锁第空闲状态
state>0：表示锁被占用
state<0:表示溢出

state在AQS中是一个很重要的属性，不管是独占锁还是共享锁，通过CAS操作该字段，

如果是独占锁，需要通过CAS将其从0变为1，标记加锁成功

如果是共享锁，表示的是并发的线程数

head和tail加上CAS就构成了一个FIFO队列，是一个双向链表，每个节点是Node类型，通过双向队列来完成同步状态的管理，如果当前线程获取同步状态失败，AQS将会把当前线程以及等待的状态信息构建成一个节点Node并加入到同步队列，同时会阻塞当前线程，当同步状态释放掉，会将处于队列首节点的线程唤醒，让该线程获取同步状态，在队列中节点用来保存同步状态的线程（thread）、等待状态（waitStatus）、前驱节点（prev）和后继节点（next）

 static final class Node {
    /** 标记表示节点正在共享模式中等待 */
    static final Node SHARED = new Node();
    /** 标记表示节点正在独占模式下等待 */
    static final Node EXCLUSIVE = null;

    /** 
    * 表示线程已经被取消 
    * 同步队列中的线程因为超时或中断，需要从同步队列中取消。被取消的节点将不会有任何改变
    */
    static final int CANCELLED = 1;


    /** 
    * 后继节点的线程处于等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后
    * 继节点，使后继节点的线程得以运行 
    */
    static final int SIGNAL = -1;


    /** 
      * 节点在等待队列中，节点线程等待在Condition上，当其他线程对Condition调用了signal()方法 
     *  后，该节点将会从等待队列中转移到同步队列中，加入到对同步状态的获取 
     */
    static final int CONDITION = -2;


    /**
     * 下一次共享模式同步状态获取将会无条件的被传播下去
     */
    static final int PROPAGATE = -3;



    /**
     *   等待状态，仅接受如下状态中的一个值：
     *   SIGNAL:  -1
     *   CANCELLED:   1
     *   CONDITION:   -2
     *   PROPAGATE:   -3
     *   0:  初始化的值
     *
     * 对于正常的同步节点，它的初始化值为0，对于条件节点它的初始化的值是CONDITION。它使用
     * CAS进行修改。
     */
    volatile int waitStatus;

    /**
     *  前驱节点
     */
    volatile Node prev;

    /**
     * 后继节点
     */
    volatile Node next;

    /**
     * 获取同步状态的线程
     */
    volatile Thread thread;

    /**
     * 等待队列中的后继节点。如果当前节点是共享的，那么这个字段是一个SHARED常量，也就是说
     * 节点类型（独占和共享）和等待队列中的后继节点公用同一个字段
     */
    Node nextWaiter;

    /**
     * 如果节点在共享模式下等待则返回true
     */
    final boolean isShared() {
        return nextWaiter == SHARED;
    }

    /**
     * 获取前驱节点
     */
    final Node predecessor() throws NullPointerException {
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }

    Node() {
    }

    Node(Thread thread, Node mode) { 
        this.nextWaiter = mode;
        this.thread = thread;
    }

    Node(Thread thread, int waitStatus) { 
        this.waitStatus = waitStatus;
        this.thread = thread;
    }
}

volatile int waitStatus:节点的等待状态，一个节点可能位于以下几种状态：

CANCELLED = 1

当前的线程被取消,节点操作因为超时或者对应的线程被interrupt。节点不应该留在此状态，一旦达到此状态将从CHL队列中踢出。

SIGNAL = -1

表示当前节点的后继节点包含的线程需要运行，也就是unpark.节点的继任节点是（或者将要成为）BLOCKED状态（例如通过LockSupport.park()操作），因此一个节点一旦被释放（解锁）或者取消就需要唤醒（LockSupport.unpack()）它的继任节点。

CONDITION = -2

当前节点在等待condition，也就是在condition队列中.表明节点对应的线程因为不满足一个条件（Condition）而被阻塞。

PROPAGATE=-3

当前场景下后续的acquireShared能够得以执行

对于正常的同步节点，他的初始化值为0，新生的非CONDITION节点都是此状态。

非负值标识节点不需要被通知（唤醒）。

volatile Node prev;此节点的前一个节点。节点的waitStatus依赖于前一个节点的状态。

volatile Node next;此节点的后一个节点。后一个节点是否被唤醒（uppark()）依赖于当前节点是否被释放。

volatile Thread thread;节点绑定的线程。

Node nextWaiter;下一个等待条件（Condition）的节点，由于Condition是独占模式，因此这里有一个简单的队列来描述Condition上的线程节点。

节点（Node）是构成CHL的基础，同步器拥有首节点（head）和尾结点（tail），没有成功获取同步状态的线程会构成一个节点并加入到同步器的尾部。CHL的基本结构如下：

AQS同步器原理

基本的思想是表现为一个同步器，支持下面两个操作：

获取锁：首先判断当前状态是否允许获取锁，如果是就获取锁，阻塞操作或者获取失败，也就是说如果独占锁就可能阻塞，如果是共享锁就可能失败。另外如果是阻塞线程，那么线程就需要进入阻塞队列。当状态位允许获取锁时就修改状态，并且如果进了队列就从队列中移除

while(synchronization state does not allow acquire){
   enqueue current thread if not already queued;
   possibly block current thread;
}
dequeue current thread if it was queued;

释放锁：这个过程就是修改状态位，如果有线程因为状态位阻塞的话就唤醒队列中的一个或者更多线程。

update synchronization state;
if(state may permit a blocked thread to acquire)
   unlock one or more queued threads;

要支持上面两个操作就必须有下面的条件：

  1. 原子性操作同步器的状态位state->CAS
  2. 阻塞和唤醒线程
  3. 一个有序的队列

目标明确，要解决的问题也清晰了，那么剩下的就是解决上面三个问题

状态位的原子操作

这里使用一个32位的整数来描述状态位，使用CAS操作来修改状态。事实上这里还有一个64版本的同步器，这里暂且不谈。

阻塞和唤醒线程

标准的JAVA API里面是无法挂起（阻塞）一个线程，然后在将来某个时刻再唤醒它。

在JDK1.5以后利用JNI在LockSupport类中实现了此特性

LockSupport.park()

LockSupport.park(Object)

LockSupport.parkNanos(Object, long)

LockSupport.parkNanos(long)

LockSupport.parkUntil(Object, long)

LockSupport.parkUntil(long)

LockSupport.unpark(Thread)

上面的API中park()是在当前线程中调用，导致线程阻塞，带参数的Object是挂起的对象，这样监视的时候就能够知道此线程是因为什么资源导致阻塞的。由于park()立即返回，所以通常情况下需要在循环中去检测竞争资源来决定是否进行下一次阻塞。park()返回的原因有三：

  1. 其他某个线程调用将当前线程作为目标调用unpark；
  2. 其他某个线程中断当前线程
  3. 该调用不合逻辑的返回

其实第三条就决定了需要循环检测，类似于通常写的while(checkCondition()){Thread.sleep(time);}类似的功能。

有序队列

在AQS中采用CHL列表来解决有序的队列问题

 AQS采用的CHL模型采用下面的算法完成FIFO的入队列和出队列过程。

查看类的方法和属性

快捷键：comand(win)+7

非快捷键：类的顶部栏：View->Tool Windows->Structure

对于入队列：从数据结构上出发，入队列是比较简单的，无非就是当前队列中的尾结点指向新节点，新节点的prev指向队列的尾结点，然后将同步器的tail节点指向新节点。在AQS中入列的源码如下：

/**
 * 为当前线程和给定的模式创建节点并计入到同步队列中
 *
 * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
 * @return the new node
 */
private Node addWaiter(Node mode) {
    // 创建一个节点
    Node node = new Node(Thread.currentThread(), mode);
    // 快速尝试添加尾节点，如果失败则调用enq(Node node)方法设置尾节点
    Node pred = tail;
    // 判断tail节点是否为空，不为空则添加节点到队列中
    if (pred != null) {
        node.prev = pred;
        // CAS设置尾节点
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

/**
 * 插入节点到队列中
 * @param node the node to insert
 * @return node's predecessor
 */
private Node enq(final Node node) {
    // 死循环 知道将节点插入到队列中为止
    for (;;) {
        Node t = tail;
        // 如果队列为空，则首先添加一个空节点到队列中
        if (t == null) {
            if (compareAndSetHead(new Node()))
                tail = head;
        } else {
            // tail 不为空，则CAS设置尾节点
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

从上面源码中我们可以看到，在将节点添加到CHL（同步队列）尾部的时候，使用了一个CAS方法(compareAndSetTail(pred, node))，这里使用CAS的原因是防止在并发添加尾结点的时候出现线程不安全的问题（即有可能出现遗漏节点的情况）

入队列的过程

 同步队列遵循FIFO规范，首节点的线程在释放同步状态后，将会唤醒后续节点的线程，并且后继节点的线程在获取到同步状态后会将自己设置为首节点，因为设置首节点是通过获取同步状态成功的线程来完成的，因此设置头结点的方法不需要使用CAS来保证，因为只有一个线程能获取到同步状态。CHL出队列的过程如下：

AQS在J.U.C里面是一个非常核心的工具，而且也非常复杂，里面考虑到了非常多的逻辑实现。

ReentrantLock

ReentrantLock是java中重入锁的实现，一次只能有一个线程来持有锁，包含三个内部类，Sync、NonFairSync、FairSync

构造函数如下：

   //无参构造，默认使用的是非公平性锁 
   public ReentrantLock() {
        sync = new NonfairSync();
    }
   //有参构造， Boolean类型的参数 true：表示公平性锁  false：非公平性锁
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

ReentrantLock是Lock接口的实现类，实现了Lock接口下的所有方法

获取锁的方法lock、trylock、lockinterruptibly加锁方式以及释放锁

公平性锁和非公平性锁的实现示例

public class NonFairAndFairDemo implements Runnable {
    //静态变量，线程共享
    static Integer num = 0;
    //锁实例
    private ReentrantLock rtl;


    public NonFairAndFairDemo (ReentrantLock rtl) {
        this.rtl = rtl;
    }


    @Override
    public void run() {
        while (true) {
            //加锁
            rtl.lock();
            num++;
            System.out.println(Thread.currentThread().getName()+":"+num);
            rtl.unlock();
        }

    }
}


    public static void main(String[] args) {
        //模拟两个线程不断的获取同一个共享资源，可以实现公平性锁和非公平性锁

        //公平性锁
        ReentrantLock fairLock = new ReentrantLock(true);
        //非公平性锁
        ReentrantLock noFairLock = new ReentrantLock(false);

        //非公平性锁演示
        Thread threadA = new Thread(new NonFairAndFairDemo(noFairLock));
        threadA.setName("A");
        Thread threadB = new Thread(new NonFairAndFairDemo(noFairLock));
        threadB.setName("B");
        threadA.start();
        threadB.start();

    }

公平性锁特征如上：按照线程的访问顺序进行获取

非公平性锁的特点，每个线程都连续执行多次后再替换成其他线程执行

公平性锁和非公平性锁如何实现：

公平性锁和非公平性锁的父类是Sync

Sync类是AbstractQueuedSynchoronizer的子类，AQS是一个同步器，提供同步功能

abstract static class Sync extends AbstractQueuedSynchronizer {
        private static final long serialVersionUID = -5179523762034025860L;

        //加锁操作，声明是抽象方法，nofairsync和fairsync中各自实现
        abstract void lock();

        //非公平获取，公平性锁和非公平性锁都需要这个方法
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            //AQS获取state值 
            int c = getState();
            if (c == 0) {
                //锁空闲状态
                //通过cas获取锁状态，修改state状态
                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");
                //当前线程继续持有锁，仅对state进行加操作
                setState(nextc);
                return true;
            }
            return false;
        }

    
        //释放锁  sync中的tryRelease是公平性锁和非公平性锁的释放锁流程都是该方法
        protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            //只有持有锁的线程才能释放锁
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {//锁才会被释放
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

       //判断当前线程是否持有锁
        protected final boolean isHeldExclusively() {
            return getExclusiveOwnerThread() == Thread.currentThread();
        }

        final ConditionObject newCondition() {
            return new ConditionObject();
        }

        //获取锁的持有者线程
        final Thread getOwner() {
            return getState() == 0 ? null : getExclusiveOwnerThread();
        }

        //加锁的次数
        final int getHoldCount() {
            return isHeldExclusively() ? getState() : 0;
        }

        //是否上锁  true:表示加锁
        final boolean isLocked() {
            return getState() != 0;
        }
    }

该Sync中方法的封装是调用AQS中的方法实现的

公平性锁和非公平锁如何实现？

公平性锁：FairLock

static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {
            acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                //同步状态为空闲，需要等待队列中第一个等待着执行
                //什么时候当前线程可以执行，等待队列里没有线程等待或者是有线程等待且等待的第一个线程就是当前线程
//hasQueuedPredecessors()主要是用来判断线程需不需要排队，因为队列是FIFO的，所以需要判断队列中有没有相关线程的节点已经在排队了。有则返回true表示线程需要排队，没有则返回false则表示线程无需排队。
                if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
           
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                //当前同步状态非空闲，被线程占用且是当前线程
                int nextc = c + acquires;
                if (nextc < 0)
                    //有符号的int类型。最高位为1表示负数
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }

类AbstractQueuedSynchronizer#acquire
    public final void acquire(int arg) {
    //当前同步状态非空闲，并且是其他线程持有锁 返回false
        if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

公平性锁获取锁流程：

1、如果同步状态为空，就可以抢锁，能够获取锁的前提条件是当前等待队列为空，或者等待队列的队头是当前线程才能抢锁，通过CAS抢锁，抢锁成功并记录当前线程信息到锁上

2、如果同步状态不为空，即存在线程占用锁并且占用线程是当前线程，当前线程可成功获取锁

非公平性锁

static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        final void lock() {
            //执行Lock操作，尝试立即获取锁，失败就退回常规流程
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);//立即获取锁失败进入到acquire，首先调用tryAcquire
        }

        protected final boolean tryAcquire(int acquires) {
            //同步状态为空闲或者不为空闲但是是当前线程持有锁，返回true表示抢锁成功
            return nonfairTryAcquire(acquires);
        }
    }

  
类AbstractQueuedSynchronizer#acquire
    public final void acquire(int arg) {
    //当前同步状态非空闲，并且是其他线程持有锁 返回false
        if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

通过代码可知：很多方法，trylock、unlock都是在父类sync实现

非公平性锁抢锁流程：

1、直接通过CAS操作抢锁，如果不成功进入常规抢锁流程

2、获取当前锁的状态（state是否为0），如果为0表示空闲，直接通过CAS抢锁，如果成功，记录线程信息到锁上

3、如果锁不为空闲且是当前线程持有锁，则可直接获取锁（state+1）

重入锁的实现：

ReentrantLock都是将具体实现委托给内部类（Sync\NonFairSync\FairSync）

ReentrantLock的重入次数是使用AQS的state属性，state大于0表示锁被占用（值表示当前线程重入次数），等于0表示空闲，小于0表示重入次数太多导致溢出

可重入锁需要一个重入计数的变量，初始值为0，当成功抢锁+1，释放锁时减1，当释放锁时计数为0则真正释放锁

重入锁必须持有对锁持有者的引用，用以判断是否可以重入

Condition

Synchronized与wait、notify、notifyall方法结合可以实现等待、通知模式，reentrantLock同样了以实现等待、通知模式，需要借助于Condition对象，具有更好的灵活性

public Condition newCondition()

Condition中提供的方法如下：

 awaitXXX和Object中的wait方法类似，使当前线程进入休眠进行等待

signal和Object中的notify方法类似，唤醒一个处于休眠状态的线程

signalAll和Object中的notifyAll方法类似，唤醒所有处于休眠状态的线程

生产者/消费者模型基于Condition实现

/**
 * 生产者
 */
public class Consumer implements Runnable {
    //仓库，容量限制为3
    private LinkedList <Integer> cap;
    private ReentrantLock rtl;
    private Condition cTop;
    private Condition pToc;
    private Random random = new Random();

    public Consumer(LinkedList <Integer> cap, ReentrantLock rtl, Condition cp, Condition pc) {
        this.cap = cap;
        this.rtl = rtl;
        this.cTop = cp;
        this.pToc = pc;
    }

    @Override
    public void run() {
        while (true) {
            rtl.lock();
            try {
                //当仓库满了，需要等待，直至消费者通知
                while (cap.size() == 3) {
                    System.out.println("仓库满了，生产者需要等待");
//                    cap.wait();
                    pToc.await();
                }

                //此处说明仓库不满，可以继续生产
                int value = random.nextInt(1000);
                //生产的数据放入仓库
                cap.add(value);
                System.out.println("生产者生产数据：" + value);

                Thread.sleep(value);

                //生成者通知消费者
                cTop.signal();
//                cap.notifyAll();


            } catch (Exception e) {

            }
            //释放锁
            rtl.unlock();
        }
    }
}


/**
 * 消费者
 */
public class Producer implements Runnable {
    //仓库，容量限制为3
    //仓库，容量限制为3
    private LinkedList <Integer> cap;
    private ReentrantLock rtl;
    private Condition cTop;
    private Condition pToc;
    private Random random = new Random();

    public Producer(LinkedList <Integer> cap, ReentrantLock rtl, Condition cp, Condition pc) {
        this.cap = cap;
        this.rtl = rtl;
        this.cTop = cp;
        this.pToc = pc;
    }

    @Override
    public void run() {
        while (true) {
            //仓库是作为生产者消费者共享区域，一个方数据，一个消费数据，需要互斥访问
            rtl.lock();
            try {
                while (cap.size() == 0) {
                    //当前仓库为空,消费者需要等待生产者通知
                    System.out.println("仓库空了，消费者需要等待");
//                    cap.wait();
                    cTop.await();
                }

                //当前步骤表示仓库不为空，可以消费
                Integer value = cap.remove();
                System.out.println("消费者消费产品为：" + value);

                Thread.sleep(random.nextInt(1000) + 1000);//至少休眠1秒

//                通知生产者(生产者在仓库满的情况下才会对该通知起作用，否则不起作用)
//                cap.notifyAll();
                //消费者单向通知生产者
                pToc.signal();

            } catch (Exception e) {
                e.printStackTrace();
            }

            rtl.unlock();
        }

    }
}

public static void main(String[] args) {
        //给定一个三个容量的仓库
        LinkedList <Integer> cap = new LinkedList<>();
        //加锁实例
        ReentrantLock reentrantLock = new ReentrantLock();
        //生产者通知消费者Condition
        Condition cToP = reentrantLock.newCondition();
        //消费者通知生产者Condition
        Condition pToC = reentrantLock.newCondition();
        new Thread(new Producer(cap,reentrantLock,cToP,pToC)).start();
        new Thread(new Consumer(cap,reentrantLock,cToP,pToC)).start();
    }

在调用Condition中的await方法或者是signal这些方法中的任何方法是必须持有锁（ReentrantLock），如果没有持有锁，则抛出异常IlegalMonitorStateException

在调用await方法时，将释放掉锁，并在这些方法返回之前，重新先获取该锁，才能执行

如果线程在等待中被中断，则等待将停止，并抛出InterruptedException，清除掉中断状态

等待状态的线程按照FIFO顺序接收信号

等待方法返回的线程重新获取锁的顺序与线程最初获取锁的顺序是相同的

线程A、B、C三个线程，每个线程打印线程名，打印结果为ABCABC...每个线程打印十遍

通过await、signal实现：

public class ABCThread extends Thread {
    private String name;
    private ReentrantLock rtl;
    private Condition waitc;//等待Condition
    private Condition sigalc; //通知Condition

    public ABCThread(String name,ReentrantLock rtl,Condition wc,Condition sc){
        this.name = name;
        this.rtl = rtl;
        this.waitc = wc;
        this.sigalc = sc;
    }

    @Override
    public void run() {
        int num =0;
        while (true) {
            rtl.lock();
            //等待其他线程通知，
            try {
                waitc.await();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            //打印当前线程信息
            System.out.println(name);

            //通知下一个线程
            sigalc.signal();
            ++num;
            if (num >= 10) break;
            rtl.unlock();
        }
    }
}


public static void main(String[] args) {
        ReentrantLock reentrantLock = new ReentrantLock();
        //A通知B
        Condition ab = reentrantLock.newCondition();
        //B通知C
        Condition bc = reentrantLock.newCondition();
        //C通知A
        Condition ca = reentrantLock.newCondition();


        new ABCThread("A", reentrantLock, ca, ab).start();
        new ABCThread("B", reentrantLock, ab, bc).start();
        new ABCThread("C", reentrantLock, bc, ca).start();
        //先发起通知A线程
        reentrantLock.lock();
        ca.signal();
        reentrantLock.unlock();




    }

iiiiiiiiiooooo
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Lock、Synchoronized和ReentrantLock的使用
11-11
Lock、Synchronized 和 ReentrantLock 的使用 Lock、Synchronized 和 ReentrantLock 是 Java 中三种常用的同步机制，每种机制都有其特点和使用场景。下面对这三种机制进行详细的分析和比较。 一、Synchronized ...
ReentrantLock lock方法注释
01-11
ReentrantLock lock方法注释
Lock与ReentrantLock
m0_38033199的博客
09-02 1939
Lock位于java.util.concurrent.locks包下，是一种线程同步机制，就像synchronized块一样。但是，Lock比synchronized块更灵活、更复杂。
【多线程】Lock和ReentrantLock使用和源码分析
weixin_44823875的博客
03-24 1378
多线程---Lock和ReentrantLock使用详情（1）Lock和ReentrantLock介绍（2）Lock锁实现同步效果（3）Lock的trylock方法（4）使用Lock时候的线程交互（5）总结Lock（ReentrantLock）和synchronized的区别（6）ReenTrantLock实现的原理（7）什么情况下使用ReenTrantLock（8）案例一：使用Lock把MyStack改造为线程安全的类并且实现生产者消费者问题（9）案例二：借助tryLock 解决死锁问题 （1）Lock和
Java中synchronized和ReentrantLock之外的锁
jt781861965的博客
05-14 233
CountDownLatch（门栓） zookeeper连接时经常用 countDownLatch.countDown()参数递减 countDownLatch.await()参数为0时，放行 CyclicBarrier（栅栏） cyclicBarrier.await 人齐就发车、多个线程协同执行，等所有的线程都拿到返回结果，再执行下一步 Phaser（好多排小栅栏，可以进行过滤） phaser.arriveAndAwaitAdvance()（去栅栏处等，线程齐后，进行下一步） phaser.arriveA
java之Synchronize、lock 和 ReentrantLock的详细分析
码农研究僧的博客
03-05 836
目录前言1. Synchronize2. lock3. ReentrantLock总结 前言 关于锁的相关问题，在代码源码以及高并发等问题都非常常见 甚至在面试题中也是一个高频的考点 对于synchronize的相关知识点补充可看我之前的文章 java并发之synchronized详细分析（全） 以及关于这部分其他知识也可看我之前的文章 JUC高并发编程从入门到精通（全） 补充一个可重入锁的概念： Synchronize和ReentrantLock这两者都是可重入锁（防止死锁） 实现原理：每个锁都有一个请求
Java 中的Lock锁对象(ReentrantLock/ReentrantReadWriteLock)详解
swadian2008的博客
08-29 3158
当有线程获取读锁时，如果当前没有线程持有写锁，则读锁将立即被获取，读锁计数器加一，表示当前有一个线程持有读锁。在 getValue() 方法中，线程会获取锁，返回共享变量 value 的值，最后释放锁。例如，如果一个线程在尝试获取锁的过程中遇到了饥饿现象（即一直获取不到锁），那么系统可能会采用类似于睡眠的方式，让该线程暂时让出 CPU 资源，等待一段时间后再次尝试获取锁。接着，它获取读锁，释放写锁，这样就实现了锁降级。这是因为写锁是独占锁，不能被多个线程同时持有，而读锁是共享锁，可以被多个线程同时持有。
ReentrantLock实现原理详解
08-31
本文将深入探讨ReentrantLock的实现原理，包括其与`synchronized`的区别、AQS（AbstractQueuedSynchronizer）的运用，以及lock()和unlock()的实现细节。 1. **synchronized与Lock的对比** - **synchronized的局限...
使用ReentrantLock和Lambda表达式让同步更
最新发布
11-22
在高级并发编程中，`ReentrantLock`是一个强大的工具，相较于内置的`synchronized`关键字，它提供了更多的灵活性和控制。本篇文章将深入探讨`ReentrantLock`的使用以及如何结合Lambda表达式来优化同步代码。 `...
java ReentrantLock详解
08-26
Java ReentrantLock 是 Java 1.5 中引入的锁机制，相比于传统的 synchronized 锁，它提供了更加灵活和强大的功能。ReentrantLock 是一种可重入锁，意味着同一个线程可以多次获得锁，而不会造成死锁。 ReentrantLock...
Java 理论与实践: JDK 5.0 中更灵活、更具可伸缩性的锁定机制
liumyong的专栏
11-22 1280
新的锁定类提高了同步性 —— 但还不能现在就抛弃 synchronizedJDK 5.0 为开发人员开发高性能的并发应用程序提供了一些很有效的新选择。例如，java.util.concurrent.lock 中的类 ReentrantLock 被作为 Java 语言中 synchronized 功能的替代，它具有相同的内存语义、相同的锁定，但在争用条件下却有更好的性能，此外，它还有 synchro
synchronized 和 Lock 和 ReentrantLock 有什么区别
段远山
03-31 1962
synchronized 和 Lock 有什么区别: synchronized 是Java内置关键字，在jvm层面，Lock是个java类。 synchronized 无法判断是否获取锁的状态，Lock 可以判断是否获取到锁。 synchronized 会自动释放锁，Lock 需要在 finally 中手工释放锁（unlock() 方法释放锁），否则容易造成线程死锁。 用 synchro...
synchronized和lock(reentrantlock) 区别
积跬步，至千里；
04-17 9693
1.某个线程在等待一个锁的控制权的这段时间需要中断 2.需要分开处理一些wait-notify，ReentrantLock里面的Condition应用，能够控制notify哪个线程 3.具有公平锁功能，每个到来的线程都将排队等候   1，3
ReentrantLock的三种获取锁Lock，tryLock，lockInterruptibly的区别
及时雨的csdn
07-08 4498
重入锁有三种获取锁的方式,本文就是来说明三种方式的异同点的.
ReentrantLock的lock-unlock流程详解
热门推荐
luonanqin的专栏
12-11 2万+
在jdk1.5之前，多线程之间的同步是依靠synchronized来实现。synchronized是java的关键字，直接由jvm解释成为指令进行线程同步管理。因为操作简单，而且现在jdk的后续版本已经对synchronized进行了很多的优化，所以一直是大家编写多线程程序常用的同步工具。那为什么要推出新的同步api呢？jdk1.5发布的时候，synchronized性能并不好，这可能是concurrent包出现的一个潜在原因，但是更重要的是新的api提供了更灵活，更细粒度的同步操作，以满足不同的需求。但是
Lock和实现类中ReentrantLock中的lock()与tryLock()区别
weixin_42739473的博客
07-26 1787
先上代码 package time.task.excutor; import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class ReentrantDemo { public ...
synchronized 和 Lock、ReentrantLock有什么区别
syilt的博客
05-26 4412
synchronized 与Lock的区别 synchronized 可以给类、方法、代码块加锁；而 lock 只能给代码块加锁。 synchronized 不需要手动获取锁和释放锁，使用简单，发生异常会自动释放锁，不会造成死锁；而 lock 需要自己加锁和释放锁，如果使用不当没有 unLock()去释放锁就会造成死锁，所以常在finally代码块释放。 通过 Lock 可以知道有没有成功获...
基于ReentrantLock理解AQS同步队列的细节和设计模式
凡是过往，皆为序章
08-01 1256
目录 重入锁Reentrantlock Lock接口 公平锁和非公平锁 总结 Reentrantlock与AQS 总结 Node和AQS工作原理 总结 基于Reentrantlock分析AQS独占锁模式的实现 非公平锁的获取锁 获取锁 加入同步队列 自旋 总结： 1、A直接获取到锁: 2、B尝试获取锁： 3、C尝试获取锁： 非公平锁的释放锁 总结 Re...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值