LinkedBlockingQueue多线程安全的保障 —————— 开开开山怪

本文深入分析了LinkedBlockingQueue如何通过链表结构、AtomicInteger、ReentrantLock及Condition等机制实现多线程安全。重点讲解了通过putLock和takeLock分别控制添加和删除操作,确保head和last节点的准确性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

LinkedBlockingQueue多线程安全的保障

相信看过我的ArrayBlockingQueue的博客,对于我们分析LinkedBlockingQueue会有一定的帮助,这两个阻塞队列也可以作为我们阻线程池中阻塞对列的选择。

LinkedBlockingQueue采用的是带头节点链表的数据结构。
我们来通过这个类的成员后具体的代码来进行分析LinkedBlockingQueue所采用的实现多线程安全的手段是什么。

public class LinkedBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {
    //用来表示链表的容量大小,如果用户不进行设置的话,那么 capacity = Integer.MAX_VALUE   
      private final int capacity;
   //这个AtomicInteger 类中有一个重要的成员private volatile int value;
   //采用这个 AtomicInteger 中的value进行记录当前元素的数量,
   // AtomicInteger 中对value值进行更改的时候,采用的是CAS进行更改,
   //所以在 LinkedBlockingQueue中调用AtomicIntege的方法虽value进行更改的话是可以保证线程安全的,因为1.value采用类volatile保证了其值的可见性,
   //2是因为采用CAS的形式对其值进行更改,保证其原子性。 
      private final AtomicInteger count = new AtomicInteger();
   //用来记录头节点    
      transient Node<E> head;
   //用来记录尾结点
      private transient Node<E> last;
   //对于LinkedBlockingQueue来说我们采用的是两个ReentrantLock 的对象
   //分别为takeLock 和 putlock,将添加和拿出的操作进行区分。
   //notEmpty 为 takeLock的阻塞队列。
   //notFull  为 putlock的阻塞队列
      private final ReentrantLock takeLock = new ReentrantLock();
      private final Condition notEmpty = takeLock.newCondition();
      private final ReentrantLock putLock = new ReentrantLock();
      private final Condition notFull = putLock.newCondition();

从上边的成员的介绍,你们可能知道了,关于记录阻塞队列中的元素个数,我们知道是线程安全的因为采用了Volitile和CAS,才保证的count个数具有准确定,
但你们一定很迷惑,为什么head和last这两个成员没有任何的修饰,虽然count的准确性保证了,但对于头节点和尾结点的准确性是如何保障的?

我们都知道在进行删除或添加的时候,都需要对头节点和尾结点进行更改
那我们举个例子,我们采用普通的链表的删除和添加的方法

当一个线程想要删除的时候,那么会将head的值先copy一份,然后当线程的时间片段到了,而此时刚好有个线程想要添加,那么此时这个线程会先将tail的值copy一份,然后时间片段到了,想要删除的线程抢占到cpu资源开始执行删除操作,那么将会使头节点的后驱节点设为null,那就说明tail这个节点不会再被引用了,然后当删除线程进行删除完后,添加节点的线程继续添加,因为添加线程已经将tail的值copy一份,所以线程还是一句当前的tail的值进行添加,那么这个tail还是没有删除前的那个tail,此时线程添加的时候,将会添加到tail的后面,那么此时这个阻塞队列就会成为这个局面,由于tail节点不再被引用导致添加的新节点也不会被引用。导致真正内存中的队列只剩下一个头节点,把本来应该要加入的新节点丢失了。

但LinkedBlockingQueue中采用的节点的删除法是将头节点的后驱节点中中的内容进行清除,然后将头节点删除,将头节点的后驱节点作为删除后的头节点,这样的话,对于就不会造成上述所说的节点缺失的问题,
在这里插入图片描述

这个问题是解决了,但是对于不同的线程来说,都保存的是head或者last的复制本,并且也是对其复制本进行操作,会带来一个问题就是最终内存中的head和last的值回因为多线程的问题,导致内存中的head和last不准确

那么LinkedBlockingQueue采取的措施是什么呢。
针对上边的成员来说,我们看到有两个Reentrantlock锁,一个是takelock一个是putlock,那么LinkedBlockingQueue就是采用这两个锁来保证线程安全的。
我们来看看添加操作和删除操作,只展示部分代码说明问题

public boolean offer(E e) {
            final ReentrantLock putLock = this.putLock;
        putLock.lock();//采用的是putlock
        try {
            if (count.get() < capacity) {
                enqueue(node);
                c = count.getAndIncrement();
                if (c + 1 < capacity)
                    notFull.signal();
            }
        } finally {
            putLock.unlock();
        }
  }
put()
 public void put(E e) throws InterruptedException {
 	final ReentrantLock putLock = this.putLock;
 	final AtomicInteger count = this.count;
        putLock.lockInterruptibly();//采用的是putlock
         while (count.get() == capacity) {
                notFull.await();
            }
            enqueue(node);
            c = count.getAndIncrement();
            if (c + 1 < capacity)
                notFull.signal();
        } finally {
            putLock.unlock();
        }

我们从上边的方法就可以看出来,对于添加操作,采用的是putlock锁,
那不用说对于删除操作采用的是takelock,
我们再来看put和offer两个方法调用的核心方法enqueue(node);
发现这个方法只有一行有效代码,并且只对last节点进行了操作

private void enqueue(Node<E> node) {
        // assert putLock.isHeldByCurrentThread();
        // assert last.next == null;
        last = last.next = node;
    }

poll和take方法代用的核心方法我们同样发现了,只用了head节点,或者说只对head节点进行操作。

private E dequeue() {
               Node<E> h = head;
        Node<E> first = h.next;
        h.next = h; // help GC
        head = first;
        E x = first.item;
        first.item = null;
        return x;
    }

那我们来总结一下成员head和last为什么没有任何关于线程安全的修饰,同样可以保证多线程安全呢
因为对于LinkedBlockingQueue来说,添加操作采用了putlock锁来保证添加操作的同步,同时又因为添加操作只是对last进行修改,那可以说明last这个变量具有准确性
。同样删除操作采用takelock锁才保证删除操作的同步,同时删除只对head变量进行操作,所以head也是具有准确性的。

<think>好的,我现在需要回答用户关于LinkedBlockingQueue如何实现线程安全的问题。首先,我得回忆一下LinkedBlockingQueue的基本结构和用途。它是一个基于链表实现的阻塞队列,常用于多线程环境下的生产者-消费者模型。线程安全是关键特性,所以用户想知道其内部机制。 接下来,我应该分解LinkedBlockingQueue线程安全实现。首先想到的是锁机制。LinkedBlockingQueue通常使用两个ReentrantLock锁,一个用于入队(putLock),一个用于出队(takeLock)。这样可以分离入队和出队的操作,减少竞争,提高并发性能。但需要确认是否正确,比如是否真的用了两个锁,或者有没有例外情况。 然后是内部数据结构。链表结构由节点构成,每个节点包含元素和指向下一个节点的引用。头节点和尾节点的操作需要保证原子性,这时候锁的作用就体现出来了。比如,入队操作在尾部添加节点,需要获取putLock,而出队操作从头部移除节点,需要获取takeLock。这样同时进行入队和出队不会互相阻塞。 接下来是条件变量(Condition)。当队列为空时,消费者线程需要等待,直到有元素入队;当队列满时,生产者线程需要等待,直到有空间。这里可能使用了notEmpty和notFull这两个条件变量,分别由对应的锁管理。例如,put操作在队列满时调用notFull.await(),而take操作在取出元素后调用notFull.signal(),反之亦然。 还需要考虑容量控制。LinkedBlockingQueue可以有界或无界,当有界时,容量达到上限会阻塞生产者线程。容量通过原子变量(如AtomicInteger)来维护吗?或者是否通过锁来同步?实际上,容量可能由内部的count变量来维护,而count变量由putLock和takeLock共同管理,使用原子操作或者volatile关键字保证可见性。但具体实现可能用到了双重检查,或者使用锁来保护count的修改。 原子操作方面,比如入队和出队时对count的增减是否线程安全。由于入队和出队分别由不同的锁控制,但count可能被两个锁同时影响,所以需要使用原子变量或者在操作count时用主锁(比如,是否有一个全局锁?不过我记得LinkedBlockingQueue是用了两个锁,所以count的修改可能需要在两个锁的保护下进行,或者使用volatile加上原子操作。例如,count是AtomicInteger类型,或者用volatile int,再结合锁来保证原子性。) 另外,迭代器的线程安全。虽然LinkedBlockingQueue本身是线程安全的,但它的迭代器是弱一致性的,这意味着迭代器创建后可能不会反映所有修改。这部分是否需要提及?用户可能想知道迭代时是否安全,所以应该说明迭代器不会抛出ConcurrentModificationException,但数据可能不是最新的。 还有,入队和出队的具体操作步骤。比如,入队操作需要获取putLock,插入节点到尾部,然后判断如果之前队列为空,可能需要唤醒等待的消费者线程。同时,如果插入后队列未满,继续唤醒其他生产者线程。这里需要确保在释放锁之前正确发出信号。 可能存在的边界情况,比如队列为空或满时的处理,如何正确使用条件变量来等待和唤醒线程。例如,当执行take()时,如果队列为空,线程会阻塞在notEmpty条件上,直到有元素被放入队列,此时入队操作会唤醒notEmpty上的线程。 此外,需要确认LinkedBlockingQueue的默认容量是多少,比如Integer.MAX_VALUE,即无界队列,但用户也可以指定容量。容量的大小影响阻塞行为,当有界时,put操作在队列满时阻塞,offer操作可以设置超时或立即返回false。 最后,总结其线程安全的关键点:分离锁设计、条件变量控制阻塞与唤醒、原子变量维护状态、以及链表操作的线程安全。需要将这些点组织成清晰的步骤,用中文逐步解释,确保用户容易理解。 可能还需要比较其他阻塞队列的实现,比如ArrayBlockingQueue使用单一锁,而LinkedBlockingQueue使用双锁,因此在高并发下性能更好。但用户的问题不需要比较,只要解释LinkedBlockingQueue的实现,所以可能不需要展开这部分。 检查是否有遗漏的关键点,比如节点对象的不可变性?或者内存可见性如何保证?比如,Node中的item是volatile的吗?或者通过锁的释放来保证happens-before关系。例如,在入队时,更新tail节点后,释放putLock,这样其他线程获取putLock时能看到之前的修改。同样,出队操作通过takeLock来保证可见性。 总结起来,回答的结构应该是: 1. 分离锁机制(入队和出队锁) 2. 条件变量管理线程阻塞与唤醒 3. 原子变量维护队列状态(count) 4. 链表操作的线程安全 5. 迭代器的弱一致性 6. 容量控制与阻塞策略 这样分点详细说明,每个部分解释其如何保证线程安全,确保回答结构清晰,用户容易理解。</think>LinkedBlockingQueue 是 Java 并发包中基于链表的阻塞队列,其线程安全通过以下机制实现: --- ### **1. 分离锁设计(双锁机制)** - **入队锁 (`putLock`) 和出队锁 (`takeLock`)** 入队操作(如 `put()`)使用 `putLock`,出队操作(如 `take()`)使用 `takeLock`。两者独立,允许生产者和消费者线程并发执行,减少竞争。 ```java private final ReentrantLock putLock = new ReentrantLock(); private final ReentrantLock takeLock = new ReentrantLock(); ``` --- ### **2. 条件变量控制阻塞与唤醒** - **队列非空条件 (`notEmpty`)** 消费者线程在队列为空时通过 `notEmpty.await()` 阻塞,生产者插入元素后通过 `notEmpty.signal()` 唤醒消费者。 - **队列非满条件 (`notFull`)** 生产者线程在队列满时通过 `notFull.await()` 阻塞,消费者取出元素后通过 `notFull.signal()` 唤醒生产者。 ```java private final Condition notEmpty = takeLock.newCondition(); private final Condition notFull = putLock.newCondition(); ``` --- ### **3. 原子变量维护队列状态** - **容量计数器 (`count`)** 通过原子变量 `AtomicInteger` 记录队列元素数量,确保入队和出队操作的原子性。 ```java private final AtomicInteger count = new AtomicInteger(0); ``` - **入队时**:先加锁 `putLock`,插入元素后原子性增加 `count`。 - **出队时**:先加锁 `takeLock`,移除元素后原子性减少 `count`。 --- ### **4. 链表操作的线程安全** - **头节点 (`head`) 和尾节点 (`last`)** 链表操作在锁的保护下进行: - **入队**:在尾部追加节点,更新 `last`(受 `putLock` 保护)。 - **出队**:移除头节点,更新 `head`(受 `takeLock` 保护)。 - **内存可见性** 锁的释放会强制刷新内存状态,确保其他线程能感知到最新修改。 --- ### **5. 容量控制与阻塞策略** - **有界队列** 初始化时指定容量上限,队列满时 `put()` 阻塞,`offer()` 返回 `false`。 - **无界队列** 默认容量为 `Integer.MAX_VALUE`,`put()` 永不阻塞。 --- ### **6. 迭代器的弱一致性** 迭代器通过遍历链表快照实现,不保证实时一致性,但避免抛出 `ConcurrentModificationException`。 --- ### **总结** LinkedBlockingQueue 通过 **分离锁、条件变量、原子计数和链表操作同步** 实现高效线程安全,适用于高并发生产-消费场景。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值