ThreadPoolExecutor阻塞队列选型：固定容量LinkedBlockingDeque的优势

在给定的线程池配置（核心线程数1，最大线程数10，队列容量90，拒绝策略CallerRunsPolicy）下，我们来分析使用LinkedBlockingDeque<>(90)的具体优势：

1. 与LinkedBlockingQueue<>(90)的对比优势 #

虽然ThreadPoolExecutor默认将workQueue当作单向队列使用（FIFO逻辑），但LinkedBlockingDeque作为双端队列，能带来以下收益：

• 灵活的任务执行顺序扩展：如果后续业务需要调整任务优先级（比如优先执行最新提交的任务，切换为LIFO模式），无需更换队列实现，只需修改线程池的任务获取逻辑（比如重写getTask()方法调用pollLast()），即可从队列尾部取任务执行。而LinkedBlockingQueue仅支持单向操作，无法直接实现这种需求。
• 更便捷的任务管理：在需要手动清理队列中的任务时（比如系统shutdown前取消未执行任务），LinkedBlockingDeque提供了removeFirstOccurrence()、removeLastOccurrence()等双端移除方法，相比LinkedBlockingQueue的单一remove(Object)，能更高效地定向移除任务。
• 双向迭代支持：若要监控队列中的任务状态（比如统计待执行任务类型），LinkedBlockingDeque的迭代器支持双向遍历，比LinkedBlockingQueue的单向迭代更灵活。

2. 与ArrayBlockingQueue<>(90)的对比优势（忽略公平性） #

不考虑公平锁特性时，选择LinkedBlockingDeque的核心原因在于内存与操作灵活性：

• 动态内存分配：ArrayBlockingQueue需要预先分配整个容量大小的数组内存，即便队列大部分时间处于空闲状态，这部分内存也会被占用。而LinkedBlockingDeque基于双向链表实现，仅在添加任务时才动态创建节点分配内存，内存利用率更高，尤其适合队列元素数量波动较大的场景。
• 避免伪共享问题：ArrayBlockingQueue的数组元素在内存中连续存储，容易引发CPU缓存伪共享——当多个线程同时操作不同数组位置时，可能互相影响缓存行的有效性，降低并发性能。LinkedBlockingDeque的节点分散在内存中，每个节点的缓存行独立，能减少这种性能损耗。
• 无元素移动开销：ArrayBlockingQueue在入队/出队时需要维护队头、队尾的索引指针，当队列循环到数组末尾时，需要执行额外的索引复位操作。而LinkedBlockingDeque的入队/出队仅需修改链表节点的指针，无需移动元素，在高并发场景下操作的常数项开销更稳定。

内容的提问来源于stack exchange，提问作者samshers