队列解耦了生产和消费速度，但不能消除速度差。队列满时的行为必须提前设计。
本文使用JDK 7，示例为方法体或类定义片段。源码学习需要区分语言规则、公共接口约定与某个版本的实现。本文把讨论范围固定在 Java 7，不把后续版本的集合结构或语法写进来。
1. 从现象推到机制
有界阻塞队列用有限容量吸收短时波动，put 可以等待空间，offer 可以立即返回或带超时。消费者变慢后，等待会向生产者传播；如果无限排队，问题则转成内存和越来越长的延迟。
图中的四个节点分别表示任务产生、有限队列、消费执行、背压反馈。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
给每个演示任务附上创建时间，分别记录入队等待和消费耗时。队列对象的线程安全不负责任务失败重试或持久化。
1
2
3
4
5
BlockingQueue<String> queue = new ArrayBlockingQueue<String>(4);
boolean accepted = queue.offer("task", 200, TimeUnit.MILLISECONDS);
if (!accepted) {
// 由调用方选择重试、降级或返回繁忙
}
将片段放入独立的小工程，补齐 imports（导入声明）和调用入口。观察返回值、异常类型及对象状态；并发实验需要重复交错，单次没有出错不能证明线程安全。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 消费者正常处理 | 等待长度围绕有限水平波动 |
| 消费者暂时暂停 | 生产者在容量耗尽后等待或失败 |
| 进程异常退出 | 内存队列中的任务可能丢失 |
对照 1：消费者正常处理
等待长度围绕有限水平波动。观察时记录进入速率与完成速率。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：消费者暂时暂停
生产者在容量耗尽后等待或失败。观察时记录offer 的结果与等待时长。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：进程异常退出
内存队列中的任务可能丢失。观察时记录是否另有持久化记录。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
阻塞不总是合适的流控方式。若生产者持有消费者需要的锁再等待入队，可能造成死锁；等待前应检查依赖方向和锁顺序。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“进程异常退出”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
