为什么Logback的AsyncAppender选择ArrayBlockingQueue而非LinkedBlockingQueue

答案 #

Logback 选用 ArrayBlockingQueue 而非 LinkedBlockingQueue 核心是匹配日志异步打印的场景特性，主要原因有3点：

• 优先保障低延迟的核心需求：日志打印是嵌入业务代码路径的操作，对单次操作的延迟稳定性要求远高于队列极限吞吐量。ArrayBlockingQueue 基于数组实现，入队出队仅修改数组下标、设置引用即可完成，无需额外创建/销毁节点对象，单次操作延迟更低且波动更小，完全契合日志打印不拖慢业务逻辑的核心要求。
• 内存占用可控，GC 负担更低：ArrayBlockingQueue 会预分配固定容量的数组空间，内存占用固定且无额外对象开销，同容量下内存占用比 LinkedBlockingQueue 低30%~40%（后者每个元素都需要封装成带前后指针的Node对象，有对象头、指针的额外开销）。而且日志场景队列元素进出非常频繁，LinkedBlockingQueue 频繁创建销毁Node对象会带来明显的Young GC压力，这对于追求稳定性的基础组件来说是不可接受的。
• 双锁优势在单消费者场景完全无法体现：LinkedBlockingQueue 队头队尾双锁的设计，只有在多生产者+多消费者的场景下才能发挥出吞吐量优势，但Logback异步Appender是典型的单消费者模型（从提供的消费逻辑源码也能看到只有一个工作线程从队列取消息），双锁的收益完全不存在，反而 ArrayBlockingQueue 单锁的实现逻辑更简单，没有多余的锁开销。

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