前言

上周。我在消息日志场景用多线程踩了坑：推送消息时频繁出现重复、漏推问题，高峰期还会导致程序卡顿甚至无响应。

你是否也曾在高并发业务中遇到差不多“同一条消息被多次处理”或“部分任务根本没执行”的痛点？”的规则，让多线程有序获取消息并处理不仅解决掉了上述问题。还实现了程序解耦，

一、什么是队列

队列是一种特殊的线性表其操作被严格限定：仅允许在一端进行数据插入，在另一端进行数据删除。它遵循先进先出的原则。其中，允许删除数据的一端称为队头允许插入数据的一端称为队尾。

二、阻塞队列

阻塞队列是 java.util.concurrent 包下的主要数据结构。它提供了**线程安全的阻塞式队列操作**：

• 向队列插入元素时若队列已满。线程会阻塞等待，直到队列有空闲位置；其实，
• 从队列获取元素时若队列为空。线程会阻塞等待，直到队列中有数据可取。

juc 包中许多高级同步工具类，其底层都是基于 BlockingQueue 实现的。

与普通队列的区别

• 普通队列: 只保证 FIFO 顺序，不处理并发；满了 / 空了直接报错或返回特殊值，不会阻塞线程。
• 阻塞队列: 在基础上增加并发安全 + 阻塞等待机制。满则阻塞写入,空则阻塞读取——正是生产者-使用者模型的主要实现。

三、BlockingQueue 接口细节

接口源码摘录

public interface BlockingQueue extends Queue {
boolean add;不过，// 立即加入
boolean offer;// 立即加入,若无空间返回 false
void put throws InterruptedException;
// 必要时等待
boolean offer throws InterruptedException;E take throws InterruptedException;// 必要时等待
E poll throws InterruptedException;int remainingCapacity;boolean remove;其实，boolean contains;int drainTo，}

常用方法对比表格

四、使用场景实例化——从痛点到方法

1️⃣ 线程池任务调度

"当任务提交量超出可同时执行数时新任务会被放入任务池里排等候。"这正是生产者把任务投递到 BlockingQueue，而工作线程作为使用者不停地取走并执行。若你曾遇到过「提交大量任务后程序瞬间崩溃」的问题，这正是因为缺乏可靠的堵塞机制导致工作线程竞争资源失衡。通过将主要任务放进 LinkedBlockingQueue 或 ArrayBlockingQueue 并配置合适的容量，你可以让工作线程自然进入空闲状态而不是奔溃。"

2️⃣ 消息推送 - 使用者优先级提高