阻塞队列-双锁实现

 我们原来单锁的话 容易  比较双锁来讲效率较低,而且size变量是线程不安全的,我们用双锁来进行优化

队列接口

public interface BlockingQueue <E>{
    void offer(E e) throws InterruptedException;
    Boolean offer(E e,long timeout) throws InterruptedException;
    E poll() throws InterruptedException;
}

阻塞队列双锁实现类 

我们的双锁实现的精髓 就是

我们添加元素之后,获得poll的锁之后,只唤醒一次poll线程,如果还有其他poll线程,由poll线程自己判断是否需要唤醒其他的poll线程

相应的  我们删除元素之后,获得offer锁之后,只唤醒一次offer线程,由offer线程内部去判断是否需要唤醒其他offer线程

public class ArrayBlockQueueTwoLock<E> implements BlockingQueue<E> {
    private final E[] array;
    private int head;//记录出队时候的头指针
    private int tail;//记录入队的指针
    //记录数组 个数  但是多线程下 单纯的int 是线程不安全的  我们换成线程安全的
    AtomicInteger size = new AtomicInteger(0);
    //双锁 实现 我们让  offer 线程 和poll线程分别持有一把锁
    private ReentrantLock tailLock = new ReentrantLock();//offer 线程的锁

    private ReentrantLock headLock = new ReentrantLock();//poll线程的锁
    private Condition headWait = headLock.newCondition();//控制 入队的 同步队列
    private Condition tailWait = tailLock.newCondition();//控制出队的同步队列

    public ArrayBlockQueueTwoLock(int capacity) {
        array = (E[]) new Object[capacity];
    }

    private Boolean isFull() {
        return size.get() == array.length;
    }

    private Boolean isEmpty() {
        return size.get() == 0;
    }

    @Override
    public String toString() {
        return "ArrayBlockingQueue{" +
                "array=" + Arrays.toString(array) +
                '}';
    }

    @Override
    public void offer(E e) throws InterruptedException {
        int count;//我们单纯的双锁 进行 判断 优化的还是不够好
        // 我们加一个计数器  加入同时有多个线程阻塞
        // 我们通过计数器判断 是应该单个线程 直接唤醒多个剩余的offer线程 还是单个线程只加锁一次
        tailLock.lockInterruptibly();
        try {
            while (isFull()) {
                tailWait.await();//如果满了 加入等待队列
            }
            array[tail] = e;
            if (++tail == array.length) {
                tail = 0;
            }
            count = size.incrementAndGet();//返回原来的数 并且 返回之后加1
            //如果有三个 offer 线程等待加入  发现 size为空 那我们 直接唤醒剩下的offer线程
            if (count < array.length) {
                tailWait.signal();
            }
        } finally {
            tailLock.unlock();
        }
        //如果 不为空队列的时候 加入一个 唤醒  删除的线程
        //我们唤醒 删除线程只需要唤醒 一次 即可
        // 后续的 让 删除的线程 自己去判断是否应该唤醒 其他的删除线程
        if(count==1){
            headLock.lockInterruptibly();
            try {
                headWait.signal();
            } finally {
                headLock.unlock();
            }
        }

    }

    @Override
    public E poll() throws InterruptedException {
        E e;
        int count;
        headLock.lockInterruptibly();
        try {
            while (isEmpty()) {
                headWait.await();//如果为空 一直等待
            }
            e = array[head];
            array[head] = null;
            if (++head == array.length) {
                head = 0;
            }
            count = size.decrementAndGet();
            //如果这时候排了几个删除的线程 我们发现 count 不为空 那么直接唤醒删除的线程
            if (count > 0) {
                headWait.signal();
            }
        } finally {
            headLock.unlock();
        }
        //如果队列满的时候 删除一个 元素之后  需要唤醒等待的 offer线程  我们也只需要唤醒一次就行
        // 写到 poll锁中容易死锁 所以我们把锁分开
        if(count==array.length-1){
            tailLock.lockInterruptibly();
            try {
                tailWait.signal();
            } finally {
                tailLock.unlock();
            }
        }
        return e;
    }

    @Override
    public Boolean offer(E e, long timeout) throws InterruptedException {
        return null;
    }

}

<think>好的,我现在要回答用户的问题,主要是关于LinkedBlockingQueue是否属于阻塞队列,以及线程池为何通常使用阻塞队列而不是非阻塞队列。我需要参考用户提供的引用内容,并结合自己的知识来组织答案。 首先,用户的问题分两部分:确认LinkedBlockingQueue是否为阻塞队列,以及线程池使用阻塞队列的原因。根据引用内容,引用[1]提到LinkedBlockingQueue是阻塞队列,引用[4]也讨论了LinkedBlockingQueue作为默认线程池的阻塞队列。所以第一部分应该直接回答LinkedBlockingQueue属于阻塞队列,并解释其特性,比如基于链表、可选有界等。 接下来是线程池使用阻塞队列的原因。用户之前的回答已经详细列过阻塞队列的优势,比如资源管控、线程协作、适应任务波动等。这里需要结合用户的引用内容,比如引用[2]中提到的阻塞队列的put和take方法使用锁和条件变量,当队列满或空时线程会进入等待状态,避免CPU空转。引用[4]提到LinkedBlockingQueue作为默认选择的原因,可能包括吞吐量和灵活性。需要将这些点整合起来,说明阻塞队列如何帮助线程池管理任务和线程资源,而非阻塞队列的问题,如无法缓冲任务、导致频繁拒绝或资源耗尽。 另外,用户引用[3]提到Tomcat的线程池使用TaskQueue(继承自LinkedBlockingQueue),说明实际应用中的例子,可以引用这个例子来支持线程池使用阻塞队列的常见性。 需要注意用户可能已经了解部分内容,所以需要简明扼要,结构清晰,分点回答。同时,用户提供的引用中有一些源码分析,比如put方法使用await()导致线程进入WAITING状态,这可以用于解释阻塞队列如何工作,避免线程忙等待,提升效率。 可能还需要对比阻塞队列和非阻塞队列的差异,比如非阻塞队列如ConcurrentLinkedQueue在队列满或空时立即返回,导致线程池无法有效处理任务,需要依赖拒绝策略,而阻塞队列能自然地进行流量控制和资源管理。 最后,总结LinkedBlockingQueue作为阻塞队列的地位,以及线程池选择它的原因,包括设计上的协同工作、资源管控和稳定性等。</think>### **LinkedBlockingQueue的阻塞队列属性及线程池选择原因** --- #### **一、LinkedBlockingQueue是标准的阻塞队列** 1. **定义与特性** - **阻塞队列接口实现**: $LinkedBlockingQueue$ 是 Java实现了 $BlockingQueue$ 接口的典型阻塞队列,支持线程安全的**生产者-消费者模型**。其核心方法(如$put()$、$take()$)在队列满或空时自动阻塞线程,符合阻塞队列的核心特征[^1][^4]。 - **数据结构与容量**: - 基于链表实现,默认容量为$Integer.MAX\_VALUE$(无界队列),也可通过构造函数指定为有界队列。 - 高并发场景下吞吐量优于$ArrayBlockingQueue$,因采用“双锁分离”设计(生产者和消费者使用独立锁),减少竞争[^1][^3]。 2. **典型应用场景** - **线程池默认队列**: Java 标准线程池(如$Executors.newFixedThreadPool$)默认使用$LinkedBlockingQueue$,因其平衡了吞吐量和任务缓冲能力[^4]。 - **框架级使用**: 如 Tomcat 的线程池通过自定义$TaskQueue$(继承自$LinkedBlockingQueue$)管理任务,优化任务提交与执行流程[^3]。 --- #### **二、线程池选择阻塞队列的核心原因** 1. **任务缓冲与流量削峰** - **队列容量动态调控**: 阻塞队列(如$LinkedBlockingQueue$)允许线程池在任务量超过$corePoolSize$时暂存任务,避免直接触发扩容或拒绝策略。例如: ```java // 线程池任务提交逻辑(简化) if (当前线程数 < corePoolSize) 创建新线程; else if (队列未满) 任务入队; else if (线程数 < maxPoolSize) 创建新线程; else 执行拒绝策略; ``` - **防止瞬时过载**: 突发流量通过队列缓冲后,线程池可按固定速率处理任务,避免短时高负载压垮系统(如电商秒杀场景)[^4]。 2. **高效的线程协作机制** - **自动阻塞与唤醒**: - 生产者线程调用$put()$时,若队列满,则通过$ReentrantLock$和$Condition$进入等待状态(调用$await()$),释放锁并挂起线程,避免空转消耗CPU[^2]。 - 消费者线程调用$take()$时,若队列空,同样挂起等待,直到新任务到达后被唤醒[^1]。 ```java // LinkedBlockingQueue.put()方法逻辑(简化) lock.lock(); try { while (队列满) notFull.await(); // 线程进入WAITING状态 enqueue(task); } finally { lock.unlock(); } ``` - **减少竞争开销**: $LinkedBlockingQueue$的“双锁分离”设计(生产者和消费者使用不同锁),显著降低高并发下的锁争用,提升吞吐量[^3]。 3. **资源稳定性与参数协同** - **防止资源耗尽**: 使用有界$LinkedBlockingQueue$可限制任务堆积量,避免无限制增长导致内存溢出(OOM)。队列满后触发扩容或拒绝策略,形成资源保护屏障。 - **动态扩缩容**: 队列容量与线程池参数($corePoolSize$, $maxPoolSize$)协同工作: - 队列未满时,优先复用核心线程; - 队列满后,扩容至$maxPoolSize$以应对峰值; - 任务减少后,超时线程自动回收[^4]。 4. **与非阻塞队列的对比劣势** - **非阻塞队列的缺陷**: - **无法缓冲任务**:如$ConcurrentLinkedQueue$(非阻塞队列)在队列满时直接返回失败,导致线程池频繁触发拒绝策略,即使系统负载仅为短暂峰值。 - **CPU资源浪费**:消费者线程需循环轮询队列(如`while (queue.isEmpty())`),导致空转消耗CPU,而阻塞队列通过挂起线程彻底避免这一问题[^2]。 - **参数失效**:非阻塞队列无法与$maxPoolSize$协同,线程池可能始终维持$corePoolSize$线程数,失去弹性扩缩容能力。 --- #### **三、总结** 1. **LinkedBlockingQueue的定位**: 它是标准的阻塞队列,通过链表实现双锁分离设计,在高并发场景下提供高吞吐量和灵活的任务缓冲能力,是线程池的默认选择之一[^1][^3]。 2. **线程池选择阻塞队列的本质原因**: - **系统稳定性**:通过队列容量限制和阻塞机制,防止资源耗尽; - **高效协作**:自动挂起/唤醒线程,减少CPU空转; - **参数协同**:与线程池核心参数动态配合,实现弹性资源管理。 --- ### **相关问题** 1. 如何根据业务场景选择$LinkedBlockingQueue$和$ArrayBlockingQueue$? 2. 为什么$SynchronousQueue$适合“直接传递”任务场景? 3. 如何监控阻塞队列长度以优化线程池性能?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

三氧化真

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值