自研高性能消息队列：环形队列与无锁化设计实践

1. 为什么我决定自己写一个消息队列，而不是继续用 RabbitMQ

我先交代一下背景。当时我们团队维护的订单服务已经跑了两三年，流量高峰期每秒大概有三五千次写入，RabbitMQ 单机部署，集群方案用的是镜像队列。这套架构看起来挺稳妥，直到某次大促值班夜里，我盯着监控面板看到队列积压从几百条一路飙到几十万条，消费者 CPU 打满，磁盘 IO 报警，然后整个链路开始雪崩式超时。

那次事故排查了很久，根因其实不在消费者代码，而是镜像队列在节点间同步消息时带宽被占满，加上大量确认消息回传导致网络风暴。RabbitMQ 确实很成熟，功能丰富，但它的定位是通用消息中间件，不是为超高吞吐极致优化的。我当时就在想，如果只针对内部订单系统这一个使用场景，砍掉一堆用不上的功能，把每条消息的路径做到最短，是不是能做出一个更轻量、可控性更强的高性能消息队列？

于是就有了这个项目。我花了几周时间，从零实现了一个高性能消息队列，支撑了日常每秒两万条以上的消息吞吐，高峰压测到六万条每秒，端到端延迟中位数在 3 毫秒左右。整个项目代码量不大，核心逻辑可以放在一篇文章里讲清楚，很适合那些想深入理解消息队列底层原理、或者需要在特定场景下做定制化消息组件的人参考。

先声明，我做的不是另一个 RabbitMQ 或 Kafka 的替代品。它解决的是特定场景下的特定问题：单机部署、内存优先、允许少量消息丢失、需要一个极简的消息路由机制。如果你的需求是复杂路由、消息持久化、事务消息、延迟队列这些企业级功能，直接用现成的中间件更合适。但如果你想理解消息队列高性能的底层逻辑，或者想在嵌入式、边缘计算这类资源受限的环境中塞一个轻量消息组件，这篇文章应该能帮到你。

我会从整体设计思路讲起，然后拆解队列存储结构、高并发读写优化、消费与确认机制这几个核心模块，最后会分享我做压测时的数据和踩过的坑。全程以实际代码和实测数据说话。

2. 设计取舍：高性能消息队列的架构边界

动手写之前，我先把需求边界划清楚了。一个高性能消息队列，不能上来就追求大而全，否则性能一定做不上去。性能优化的第一步永远是砍需求，确定哪些功能不做，比确定哪些功能要做更重要。

2.1 先确定使用场景：我的消息队列服务什么

我的核心场景是订单系统内部的事件流转，比如订单创建后通知库存服务扣减库存、通知积分服务发放积分、通知物流服务创建运单。这类消息有几个特点：

• 消息量峰值高：大促时每秒几万条是常态。
• 消息体积小：一条订单事件大概一两百字节，最多不超过 4KB。
• 允许少量丢失：如果服务崩溃，最坏情况下丢失几秒内的消息是可以接受的，因为订单状态本身在业务数据库里，重启后可以做对账补发。
• 路由规则简单：基本就是按事件类型分发几个队列，不需要复杂的 Topic 层级和通配符匹配。

基于这些特点，我直接放弃了持久化到磁盘的完整方案，选择内存优先 + 异步批量落盘兜底的模式。这和 Kafka 的设计有本质区别：Kafka 为了保证大吞吐和持久性，使用磁盘顺序写，但代价是引入了页缓存、批量刷盘、副本同步等一整套机制，代码量和复杂性成倍增加。我只是单机内部使用，不需要跨机器的副本复制，所以把这些机制全部去掉。

2.2 高性能的核心原则：零拷贝路径、无锁设计、批量操作

定了场景之后，我给自己列了三条性能铁律，整个实现都是围绕它们展开的。

第一条是数据路径上不要有无关操作。每条消息从生产者调用到消费者拿到，中间只允许经过必要的几道工序：写入队列、通知消费者、读取消息。不做过多的序列化转换，不做持久化等待，不做复杂的路由匹配。

第二条是能无锁就无锁，必须加锁就把锁的粒度降到最小。高并发场景下锁竞争是最大的性能杀手之一。我用环形队列加原子变量替代了传统的链表加互斥锁，用内存屏障处理生产者与消费者之间的同步，把锁竞争彻底从消息路径上移除。

第三条是能批量就批量。单条消息的操作效率永远上不去，因为每一次系统调用、每一次内存拷贝都是有固定开销的。我在生产者端加了批量发送缓冲，在消费者端加了批量拉取，让固定开销被摊薄到一批消息上。

这三条原则听起来简单，实际执行过程中每一步都有不少细节。下面几节我会展开讲具体怎么落地。

2.3 架构图：生产者、队列核心、消费者三层模型

从模块划分上看，这个队列可以分成三大部分：

• 生产者 SDK：提供异步发送接口，内部包含批量缓冲区和发送线程。
• 队列核心引擎：负责消息的存储和索引，内部是一个定长环形缓冲区，配合读写指针和信号量实现。
• 消费者 SDK：提供拉取接口，支持批量获取消息，也支持简单的发布订阅模式。

这三层都在同一进程内存空间中（本项目中我用的是嵌入式模式，直接在一个 JVM 进程里跑，后续也拆了一个独立的 TCP 服务端版本，但那版主要为了验证网络端的性能损失，不是主角）。嵌入式模式下，生产者和消费者直接操作同一块内存区的数据结构，性能是最大化了的。

3. 核心存储结构：用定长数组环形队列替代链表队列

我先把消息队列最核心的存储结构说清楚。大多数初学者写消息队列，第一反应是定义一个 List 或者 LinkedList，然后往里面塞消息对象。这个做法在低并发、小数据量时没问题，但一旦数据量大起来就开始暴露问题：内存碎片、GC 压力、节点指针膨胀。

3.1 为什么不直接用链表队列

链表队列的每一条消息，至少需要一个节点对象，这个节点里除了消息数据外，还要存指向下一个节点的指针（可能是 next 引用，也可能是偏移量）。以 Java 为例，一个节点对象额外占用 16 到 24 字节的头信息，加上引用，意味着每条消息至少浪费三四十字节。如果消息本身就是一两百字节，这个浪费比例是很大的。

更大的问题在于内存分配频繁。每入队一条消息就要创建一个新节点，产生一次内存分配；出队之后节点失去引用，又要等 GC 回收。在高吞吐场景下，每秒几万次的内存分配和释放，会让 JVM 的 Young GC 变得极其频繁，表现为整条链路的轻微停顿和 CPU 飙高。

还有一个隐蔽的缺点：链表节点在内存中分布是不连续的，遍历时 CPU 缓存命中率很差。现代 CPU 每秒能处理几十亿次指令，但如果数据不在缓存里，从主内存加载数据的延迟是缓存命中时的几十倍。这个问题在链表结构下基本无解。

3.2 环形队列的读写指针设计

我的选择是使用一个定长数组实现的环形队列。核心代码简化如下：

java复制public class RingBuffer<T> {

    private final Object[] buffer;
    private final int capacity;
    // 先不考虑扩充，队列满时直接丢弃新消息或阻塞，根据配置决定
    private final AtomicLong writeIndex = new AtomicLong(0);
    private final AtomicLong readIndex = new AtomicLong(0);

    public RingBuffer(int capacity) {
        // 这里确保容量是2的幂，方便取模
        this.capacity = tableSizeFor(capacity);
        this.buffer = new Object[this.capacity];
    }

    public boolean offer(T item) {
        long wIndex = writeIndex.get();
        long rIndex = readIndex.get();
        if (wIndex - rIndex >= capacity) {
            // 队列已满
            return false;
        }
        buffer[(int) (wIndex & (capacity - 1))] = item;
        writeIndex.lazySet(wIndex + 1);
        return true;
    }

    @SuppressWarnings("unchecked")
    public T poll() {
        long rIndex = readIndex.get();
        long wIndex = writeIndex.get();
        if (rIndex >= wIndex) {
            // 空队列
            return null;
        }
        T item = (T) buffer[(int) (rIndex & (capacity - 1))];
        if (item != null) {
            buffer[(int) (rIndex & (capacity - 1))] = null;
            readIndex.lazySet(rIndex + 1);
        }
        return item;
    }

    private int tableSizeFor(int cap) {
        int n = cap - 1;
        n |= n >>> 1;
        n |= n >>> 2;
        n |= n >>> 4;
        n |= n >>> 8;
        n |= n >>> 16;
        return (n < 0) ? 1 : n + 1;
    }
}

注意到几个关键细节：

• 用 AtomicLong 维护读写索引，通过 writeIndex 和 readIndex 的差值判断队列状态。
• 数组容量强制取 2 的幂，这样可以用位运算 index = (wIndex & (capacity - 1)) 替代取模运算，节省一次整数除法。虽然现代 JIT 编译器会把常量取模优化为位运算，但显式写出来的可读性和性能更可控。
• 使用 lazySet 而不是 set，这是一个很低层但很有效的优化点。lazySet 不保证立即可被其他线程看到，但保证了最终一致，它避免了 set 带来的 StoreLoad 屏障，在单生产者和单消费者的场景下是安全的。如果是多生产者多消费者，需要谨慎评估是否仍然安全。

3.3 预分配对象池，彻底解决GC抖动

光有环形队列还不够，因为每条消息毕竟还是一个对象。如果每秒发送五万条消息，入队时 new 五万个对象，出队后被丢弃，GC 压力一样大。

解决方案是把消息对象从入队到出队的整个生命周期内进行复用。我在队列里放的对象池，本质上还是上面的环形结构，但里面存的是一个固定大小的字节数组的引用。

流式消息的构建方式是这样的：

java复制public class MessageEnvelope {
    // 直接复用底层字节数组，避免频繁分配
    private byte[] payload;
    private int length;
    private long timestamp;
    // 其他字段如消息类型、幂等ID等
}

然后队列初始化时一次性创建 N 个 MessageEnvelope 实例，放入一个空闲池中。生产者要发送消息时，从空闲池中取出一个实例，将业务数据写入内部的字节数组，然后把实例交给环形队列。消费者消费完成后，将实例归还到空闲池。

这里有一个非常重要的点：消费者必须确保在归还之前已经完整处理完这条消息。否则，对象被复用到下一条业务消息时，数据就会被覆盖，产生极其诡异、难以排查的线上 Bug。我在消费者 SDK 中设计了一个 release() 方法，要求业务代码在 onMessage 回调返回前调用，或者使用 try-with-resources 风格确保释放。这个设计虽然给使用者增加了一点心智负担，但换来的收益非常明显：压测时 GC 的停顿时间几乎消失，CPU 占用率下降了大概 18% 到 25%。

注意：对象池方案只适合消息内容能够在消费完成后即时释放的场景。如果你的消息处理逻辑里会异步持有消息对象引用，比如丢到一个线程池里慢慢处理，那千万不要用这种复用模式，否则就是自找麻烦。我后来在独立服务版中采用了更安全的批量分配、再批量释放策略，避免了这个风险。

3.4 容量满了怎么办：背压机制的几种策略

环形队列是定长的，这就不得不面对一个现实：队列满了怎么办。我在最初的设计里提供了三种策略，对应不同场景。

第一种是直接丢弃（默认策略），适用于允许丢失的场景。生产者调用 offer 时如果发现队列已满，直接返回 false，上层业务可以选择丢弃还是走 DB 补逻辑。这个策略性能最高，因为没有阻塞。

第二种是阻塞等待，适用于不允许丢失消息的场景。生产者发现队列满时，通过 LockSupport.park() 挂起自己，消费者消费完一条后调用 unpark() 唤醒生产者。这实际上构建了一个简单的信号量机制，相比使用 ReentrantLock 的 Condition，park/unpark 的开销更小。

第三种是覆盖旧消息，适用于实时性要求极高的场景，比如实时监控数据流，新数据永远比旧数据重要。队列满时，写指针直接覆盖最老的未消费消息。

我的建议是：在大多数业务场景中，不要把队列容量设置得过大，也不要依赖丢弃策略来兜底。容量设置成峰值流量下消费者耗时最长时消息数量的两倍左右比较合理。比如消费者单条消息处理耗时平均 5 毫秒，峰值每秒 5000 条，那么队列中最多累积 25 条消息，再放大两倍余量，容量设置为 64 就足够。这也意味着内存占用很小，一个队列几 KB 就搞定了。

4. 高并发优化：无锁化改造与批量缓冲的实测效果

把存储结构定下来之后，接下来要处理的就是并发问题。消息队列本质上是生产者线程和消费者线程之间的数据管道，所以并发模型设计得如何，直接决定性能瓶颈在哪。

4.1 单生产者单消费者场景下的无锁方案

我最初的实现比较保守，生产者和消费者都加了锁来保证线程安全。跑压测时发现，当线程数提升到八个以上，吞吐量出现了明显的下降趋势。用 JFR 抓线程状态后发现，问题出在锁竞争上：虽然生产者的锁和消费者的锁不是同一把，但在锁内部还需要读取对端的索引，这就产生了跨锁的数据竞争。

后来我借鉴了 Disruptor 环形缓冲区的设计思路，把并发级别拆成了三种情况：

• 单生产者 + 单消费者（1P1C）：完全无锁，依赖 AtomicLong 和内存屏障同步读写索引。
• 多生产者 + 单消费者（MP1C）：多个生产者通过 CAS 循环抢占写索引，消费者无锁。
• 单生产者 + 多消费者（1PMC）：单生产者无锁，多个消费者通过 CAS 抢占读索引。

三种情况下的核心机制是：读线程永远不会写队列中正在被其他线程写的位置，写线程也永远不会覆盖其他线程正在读的位置。这个约束通过读写索引的解耦天然满足。

多生产者下 CAS 抢占写索引的代码行为差不多是这样：

java复制public boolean offer(T item) {
    while (true) {
        long wIndex = writeIndex.get();
        long rIndex = readIndex.get();
        if (wIndex - rIndex >= capacity) {
            return false; // 队列满
        }
        if (writeIndex.compareAndSet(wIndex, wIndex + 1)) {
            // CAS 成功，当前生产者获得了槽位 wIndex
            buffer[(int) (wIndex & (capacity - 1))] = item;
            return true;
        }
        // CAS 失败则重试
    }
}

这个方案的吞吐量比全局加锁提升了大约三倍。原因是 CAS 指令在 x86 上编译为 LOCK CMPXCHG，它只锁定内存总线上的单个地址，而传统互斥锁则可能触发线程阻塞、上下文切换、唤醒等一整套重量级机制，开销完全不在一个量级。

4.2 多生产者多消费者场景的降级策略

多生产者多消费者（MPMC）是最难的并发模型。我测试下来，完全无锁的 MPMC 复杂度太高，对内存模型和 CPU 流水线的理解要求极高，稍不留神就会引入隐蔽的数据竞争。所以在我的实现里，MPMC 场景直接降级为分段加锁，而不是追求理论上的完全无锁。

具体策略是为环形队列增加分段逻辑，把整个环形数组切分成八个分段，每个分段一把锁。生产者写入时先根据写索引定位分段，获取该分段的锁后写入；消费者读取时根据读索引定位分段，获取该分段的锁后读取。当读写发生在不同分段时，彼此之间完全没有锁竞争。只有当读写恰好落在同一分段时，才会短暂竞争。

用八个分段后，压测数据显示，MPMC 场景下的吞吐量比单锁版本提升了约两倍。虽然不如 1P1C 那样锐利，但考虑到 MPMC 场景通常也不需要极端性能（如果真是极端场景，建议直接用 Kafka 这类分布式系统），这个方案在复杂度和性能之间取得了不错的平衡。

4.3 批量发送与批量消费：为什么一次操作要处理一捆消息

对比数据最有说服力。我在同样环境下做了单条发送与批量发送的对比测试，结果如下：

可以看到，批量发送的性能提升非常明显，但从 100 条到 1000 条的边际收益已经很小了。这是因为单条发送的瓶颈主要在方法调用开销、内存屏障、上下文切换等固定成本上，批量化之后这些成本被摊薄。但批量过大时，又会引入额外的缓冲时间和内存拷贝成本。

因此，最终我的生产者 SDK 采用了这样的批量策略：发送接口接收一个消息列表，内部攒够 200 条或者攒够 5 毫秒就触发一次真正的入队操作。这个参数可以通过配置调整，我建议根据实际场景微调，不要盲目追求大 batch，因为大 batch 会增加首条消息的排队延迟。

5. 消费者端设计：推模型的陷阱与拉模型的高效实现

消费者端是消息队列最容易出问题的地方。很多自研消息队列都是拿线程池加阻塞队列来模拟推模型，表面看起来优雅，实际在高吞吐下很容易被积压拖垮。

5.1 为什么不用推模型，而用拉模型

推模型（Push）是指服务端在消息到达时主动调用消费者的处理函数。听起来很及时，但它的致命缺陷是服务端无法感知消费者的实际处理能力。想象一下，生产者瞬间向队列塞入两万条消息，而消费者每处理一条需要 10 毫秒，也就是每秒只能处理 100 条。推模型会瞬间把两千条消息压给消费者线程池，线程池忙不过来，消息堆积在线程池的任务队列里，占满内存。更糟的是这个堆积是"隐形"的，线程池状态看起来很健康，但消费者已经远远落后了。

拉模型（Pull）则把节奏控制权交给了消费者。消费者根据自己的处理速度，每次从队列中拉取一批消息，处理完成后再拉下一批。服务端不需要维护消费者的能力和状态，天然具备背压能力。

5.2 消费者拉取接口的批量API设计

我的消费者 SDK 暴露的 API 长下面这样：

java复制public class Consumer {

    private final RingBuffer<MessageEnvelope> queue;
    private final MessageHandler handler;

    public void start() {
        Thread worker = new Thread(() -> {
            while (!Thread.currentThread().isInterrupted()) {
                // 批量拉取，最多拉取 100 条
                List<MessageEnvelope> batch = queue.pollBatch(100);
                if (batch.isEmpty()) {
                    // 队列为空，短暂暂停避免空转
                    LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(1));
                    continue;
                }
                for (MessageEnvelope message : batch) {
                    handler.onMessage(message);
                    // 处理完即释放对象
                    message.release();
                }
            }
        }, "message-consumer-worker");
        worker.start();
    }
}

批量拉取的核心在于一次调用返回多条消息，避免逐条通过信号量或锁获取，显著降低了系统调用和同步开销。在我实测中，批量拉取 100 条时的吞吐是单条拉取的 6 倍以上。

有一个细节要注意：如果业务处理是串行的，那批量拉取会放大单条消息的延迟。比如批量拉取了 100 条，第一条消息在第 0 毫秒被处理，第 100 条消息可能要到第 500 毫秒才开始处理。如果业务对单条消息的及时性有严格要求，可以把批大小调小到 10 或者 20。这是吞吐和延迟之间典型的权衡，没有绝对的正确答案。

5.3 消费者线程数的确定方法

消费者线程数的设置没有银弹，但有一个可以参考的思路：先测量单条消息的平均处理耗时 T，然后用 1000 / T 得到单线程每秒可处理的消息数，再除以预期的目标吞吐量，向上取整得到需要的线程数。举个例子，如果单条消息平均需要 20 毫秒处理，单线程每秒只能处理 50 条；目标吞吐是每秒 2000 条，那么至少需要 2000 / 50 = 40 个线程。

实际上因为上下文切换、锁竞争等因素，真实需要的线程数会比理论值高 20% 到 30%，所以要留出余量。我通常在压测环境用递增线程数的方式找到拐点。比如分别测试 4、8、16、32、64 个线程的吞吐量，正常情况下吞吐会先随线程数增长，到某个点后开始趋于平缓甚至下降，那个拐点附近就是最优线程数。

5.4 消费确认与重复消费问题

再聊一个消息队列绕不开的经典话题：重复消费。我的队列使用对象池复用机制，天然要求消费者在回调中同步处理完消息并释放消息对象，所以消息只会在同一个消费者线程内部流转，理论上不存在同一个对象被并发消费的可能。

但这不代表不会重复消费。如果业务处理逻辑在 onMessage 中执行了一半抛出了异常，消费者 SDK 的默认行为是重新把这条消息放回队列头部，让下一条被拉取的机会再次处理。这样如果业务代码本身没有幂等性保证，就可能出现重复处理。

所以我专门要求使用者在业务处理链路中保证幂等性。我的推荐做法是：在消息体中携带一个全局唯一的消息 ID，消费者在业务处理时用这个 ID 去查一次缓存或数据库，如果已经处理过就直接跳过。虽然每次处理多一次查询开销，但换来的语义保障是值得的。实际压测环境中，以 Redis 查询幂等 ID 的开销大约每条 0.5 到 1 毫秒，对整体吞吐影响可控。

6. 对比测试：我的消息队列与主流中间件的性能差异

光说自己快不算是本事，得有对比数据。我在同样的物理机上，用同样的消息体大小（256 字节 JSON），分别对我的队列、RabbitMQ（镜像队列模式）、Kafka（单分区、acks=1）、以及一个基于 Redis List 的简易队列做了压测对比。

6.1 压测环境与配置说明

压测机器配置如下：

• CPU：Intel Xeon Gold 6248R，16 核分配
• 内存：32 GB
• 磁盘：NVMe SSD
• JVM：Java 17，G1 垃圾回收器，堆内存 4 GB
• 压测工具：自研压测客户端，模拟生产者线程并发发送消息

所有中间件均使用默认配置，未做额外调优。每个压测场景持续 5 分钟，取稳定期的平均值。

6.2 关键性能指标对比：吞吐量、延迟、内存占用

需要说明的是，这个对比并不完全公平，我的队列跑在嵌入式内存模式下，省去了网络传输、序列化、持久化和副本同步这些中间件的固有成本。RabbitMQ 和 Kafka 的能力边界远超我的实现，比如跨节点复制、持久化保障、复杂路由、多租户隔离，这些都是我在设计时主动放弃或简化的。

但我们也得正视一点：在单机、允许少量丢失、低延迟的内部场景中，通用中间件的性能损失确实大。RabbitMQ 的镜像队列在消息确认和同步上的开销极大，吞吐被压到一万以下非常正常；Kafka 虽然写磁盘是顺序写，但为了持久性做得一些列操作，P99 延迟依然比我的内存实现高出几十倍。

6.3 这个性能结果说明了什么

这个结果给我最直接的启发是：性能往往不是某个单一技术栈的问题，而是整体设计取向的问题。RabbitMQ 需要先保证功能全、语义稳，然后才考虑性能；Kafka 需要先保证可扩展、可持久，然后才考虑单机延迟；而我这个队列，把持久化、复制、路由这些功能全部砍掉，只保留内存中转，性能自然就上来了。

所以做消息队列选型时，不要只盯着某个 Benchmark 看，关键在于梳理你的业务到底需要哪些非功能属性。如果每条消息都价值连城，完全不能丢，那直接选 Kafka，不要尝试用内存队列硬扛。如果消息是辅助性的，性能需求极高，能接受少量丢失，那自研一个轻量内存队列完全合理。

7. 实测中的瓶颈排查与性能调优记录

从第一版实现到最终稳定运行，中间经过了十几轮压测和排查。我挑几个印象比较深的性能瓶颈问题分享出来，这些都是文档里不会直接告诉你的坑。

7.1 隐性问题一：伪共享导致的吞吐量暴跌

第一版压测时，我发现在四核以上环境中，吞吐量不仅没有线性增长，反而在某个线程数之后急转直下。用 perf 排查之后，定位到问题出在 伪共享（False Sharing） 上。

我的队列中 writeIndex 和 readIndex 被定义成相邻的两个 AtomicLong 字段。在多核 CPU 上，这两个变量很可能落在同一个缓存行（Cache Line，通常 64 字节）中。CPU 缓存的最小同步粒度是缓存行，所以即使一个线程只修改 writeIndex，另一个线程读取 readIndex 时也会因为这个缓存行被标记为失效而触发一次内存同步。两个高频访问的变量互相拖累，性能急剧下降。

修复方式非常粗暴但有效，在字段之间填充足够的字节，让它们各自独立占据一个缓存行：

java复制public class RingBufferPadding {
    protected long p1, p2, p3, p4, p5, p6, p7;
    protected volatile long writeIndex = 0;
    protected long p8, p9, p10, p11, p12, p13, p14;
    protected volatile long readIndex = 0;
    protected long p15, p16, p17, p18, p19, p20, p21;
}

填充之后，writeIndex 和 readIndex 不再共享缓存行，吞吐量立刻提升了大概 40%。这个坑非常隐蔽，如果没有性能分析工具辅助，靠肉眼很难发现。

7.2 隐性问题二：对象池归还路径上的锁竞争

对象池设计初期，归还对象时为了保证线程安全，我用了 synchronized 方法。压测时发现消费者线程数从 8 增加到 16，吞吐量反而下降了 15% 左右。用 JFR 一查，发现消费者线程在归还对象时大量阻塞在 synchronized 上。

解决方案是用 ThreadLocal 为每个消费者线程维护一个小型对象缓存。消费者从队列取到消息处理完后，对象优先归还到当前线程的 ThreadLocal 私有池中；当前线程私有池满了，才批量归还到全局共用池。生产者再从全局池取对象时，优先从自己的 ThreadLocal 取，取不到再去全局池竞争。这样一来，绝大多数对象分配和释放都发生在线程内部，全局锁竞争几乎被消除。

7.3 隐性问题三：消费者线程空转导致的CPU跑满

最初消费者线程在没有消息时，直接使用一个 while(true) 循环不断尝试 poll()，代码看起来简洁，但压测时发现 CPU 占用率始终居高不下，即使没有消息推送也占了 100% 的一个核。

原因很明确：空循环 + 不公平锁和内存屏障在高速运转。修复方案是消费者在拉取为空时调用 LockSupport.parkNanos(1_000_000)，也就是休眠 1 毫秒后再尝试。加上这个休眠之后，空闲状态的 CPU 占用率降到了 0.3% 以下，几乎没有影响消息的实时性。如果你追求更低的空闲 CPU 占用，可以把休眠时间拉长到 10 毫秒，但代价是消费者拉取消息的响应时间变长。

7.4 完整压测数据：吞吐量、延迟分布和资源占用

经过优化之后，我最终一版压测数据如下：

延迟分布方面，P50 延迟约 0.8 毫秒，P95 延迟约 1.6 毫秒，P99 延迟约 3 毫秒，P999 延迟约 9 毫秒。整个压测期间没有消息丢失（压测工具端会校验消息计数），CPU 占用率约 65%（受限于压测客户端本身的开销），内存占用稳定在 800 MB 左右，无内存溢出。考虑到消息本身只有 256 字节，这个内存占用已经非常合理了。

8. 进一步扩展：从内存队列到TCP服务端时踩过的坑

嵌入式内存队列跑通之后，我做了一个看似简单的扩展：把队列核心引擎封装成独立 TCP 服务，让多个进程通过网络来生产和消费消息。这一步让性能和稳定性的坑瞬间多了起来。

8.1 网络序列化时的性能损耗

最开始我用 Java 原生序列化传递消息，压测结果惨不忍睹，吞吐直接从每秒五万条掉到不到一万条。原生序列化要写类元信息、继承链、反射调用，效率极低。后来换成 Protocol Buffers，吞吐恢复到每秒两万五千条左右，还是比嵌入式模式差了一半。再后来改成直接传递字节数组的自定义二进制协议，裁剪掉消息头的冗余字段，最终勉强达到每秒三万五千条。

这里要说明，网络传输模式下，序列化和反序列化的开销是刚性的，无论如何优化，都不可能达到纯内存模式的速度。所以如果你的性能要求在每秒五万条以上，我强烈建议不要走独立的 TCP 服务，直接用嵌入式内存模式 + 业务进程内通信。

8.2 TCP粘包拆包与消息边界恢复

另一个经典坑是 TCP 粘包问题。因为 TCP 是面向字节流的，多条消息可能在一次 read 中同时到达，也可能一条消息被拆成两三次 read。如果没有正确的消息定界，解析出来的消息数据就全乱了。

我的方案是自定义一个简单的帧协议：每条消息前面加 4 字节的长度头，接收端先读取长度，再按长度读取消息体。这样无论底层怎么粘包拆包，上层都能正确恢复出完整消息。代码逻辑就是标准的 readLength + readPayload 两阶段读取，配合一个临时缓冲区和半包处理状态机。

8.3 客户端连接管理：心跳、断线重连与消费进度

网络模式下，消费者的连接可能随时断开。如果消费者挂掉之后重新连接，它应该从哪里继续消费？这就需要一个简单的消费进度记录机制。我的做法是：队列中为每个消费者维护一个独立的 ackedIndex，消费者每次拉取消息成功后，定期把最新确认的索引上报给服务端。服务端把每个消费者的进度持久化到本地文件或数据库中，重启后可以恢复。

但这又引入了一个新的问题：如果消费者断线期间，队列已经因为容量不够覆盖了旧消息，恢复进度时就会跳消息。我的解决思路是：消费者断线超过阈值（默认 30 秒）后，服务端将该消费者的消费位点重置为当前最新位点，并记录一条日志。这样虽然会丢消息，但保证了消费者上线后不会因为追不上进度而陷入死循环。在这个场景下，丢消息是可以接受的，因为断线重连本身就暗示着业务可能已经处于异常状态，优先保证服务的可用性会更合理。

9. 高频面试考点对照：重复消费、三大作用与性能分析

写完这个项目之后，我复盘的时候发现它正好能串起消息队列面试里几个高频考点。很多人在面试时能背出标准答案，但没有实际写过队列代码的话，理解会浮于表面。我把这些考点和我的实际设计经验放在一起，这样更有参考价值。

9.1 消息队列的三大作用究竟怎么落到代码里

“消息队列的三大作用”是面试几乎必问的问题：解耦、异步、削峰。标准答案很容易背，但只有真的写过队列才会明白这三点在代码层面意味着什么。

• 解耦：在我的设计中，生产者和消费者不直接依赖，它们只和队列核心引擎交互。生产者不需要知道库存服务怎么处理消息，消费者也不需要关心消息是谁发的。代码上就是生产者和消费者各自持有一个队列引用，编译期完全隔离。
• 异步：订单服务调用库存服务如果走同步 RPC，那么每一次下单都要等库存接口返回。引入消息队列后，订单服务只需要把事件写入队列就返回，库存服务自行从队列拉取。在我的压测里，异步化之后订单请求的 P95 延迟从 120 毫秒降到了 8 毫秒，提升非常明显。
• 削峰：队列就是一个天然的缓冲池，高峰期消息积压在队列里，消费者按自己的最大处理能力慢慢消耗，不会把下游系统打垮。这就是我在前面背压策略中讨论的队列容量设置，以及为什么不能把容量设得无限大，因为队列本身的内存成本是有限的。

9.2 重复消费问题的工程解法不是单纯去重

面试官一旦问“消息队列消息重复怎么办”，光回答“用消息 ID 做去重”是不够的。关键是要说清楚去重的粒度、存储介质和失效策略。在实际工程中，我的做法是把消息 ID 和业务处理结果绑定，在业务链路中通过 Redis 的 SETNX 实现幂等：消息处理开始时尝试写入消息 ID，如果写入成功则继续处理，否则直接跳过。要注意给这个去重键设置一个合理的 TTL，比如 30 分钟，防止去重表无限膨胀。同时，去重逻辑要在事务边界内，避免消息 ID 已经标记为已处理，但业务事务回滚造成数据不一致。

9.3 面试中的性能分析：如何定位一个消息队列的瓶颈

这是一个综合性较强的面试题，没有标准答案，但考察的就是你能不能把前面的知识点串联起来。我在项目里排查瓶颈时的思路大致如下：

• 先看瓶颈是在生产者端、队列存储端、消费者端，还是网络传输端。
• 生产者端主要看发送是否有阻塞，批量发送是否生效，序列化效率是否够高。
• 队列存储端主要看锁竞争、缓存行失效、GC 压力。
• 消费者端主要看拉取频率、批量大小、处理耗时。
• 网络传输端主要看序列化协议、TCP 选项、消息大小。

定位到某一段后，用工具进一步确认，比如 JFR 看锁和 GC，perf 看 CPU 缓存命中率，iotop 看磁盘 IO。定位之后再针对性优化，而不是盲目加线程或调大小。这个思路比背几个调优参数有价值得多。

10. 项目小结与个人经验复盘

做到这里，这个项目的基本链路已经完整了：从需求分析、存储结构设计、并发优化、消费者模型、压测验证，到网络模式扩展和面试知识点对照。我最后再分享几条个人体会。

第一，性能优化的方向比技巧重要。我见过一些团队做高性能消息队列，一上来就研究利用零拷贝、epoll、CPU 亲和性这些高级技巧，结果整体的数据结构设计不合理，队列还是链表、并发还是全局锁，那这些技巧全是事倍功半。先确定正确的高层架构，再谈低层优化，顺序不能反。

第二，自研基础设施类组件前，一定要想清楚维护成本。消息队列一旦在业务中运行起来，就会有无数场景依赖它。如果出了问题，团队有没有能力快速定位和修复？我建议这类组件只在团队足够熟悉底层原理、并且有明确测试计划的情况下使用。否则老老实实用 RabbitMQ 或 Kafka，节省下来的时间可能远超性能带来的收益。

第三，压测数据要保留运行环境和完整参数，否则很难复现。我在项目早期就吃过亏，压测报告只写了吞吐量曲线，没记录 CPU 型号和 JVM 参数，后续优化时无法判断性能变化到底是环境因素还是代码因素。后来我固定了一套标准压测环境，把 CPU 型号、内存大小、JVM 版本、GC 参数、队列容量、线程数全部记录在压测报告里，这样每次改动都能准确对比。

如果你也想动手写一个轻量消息队列，我建议从 1P1C 的无锁环形队列开始，先把核心存储结构跑通，再逐步加上批量发送、消费者线程池、网络协议这些外延功能，每加一层都要重新压测验证。这个过程可能比较漫长，但每一步都值得，因为消息队列的底层原理会在你实际动手写的这几个星期里真正长进脑子里。