Netty高性能之道——FastThreadLocal、HashedWheelTimer与无锁队列

摘要

Netty 的高性能不仅来自 EventLoop 的单线程模型和 ByteBuf 的内存池，还来自它对 JDK 标准库中若干关键组件的替代性实现。这些替代实现往往针对特定场景做了极致优化，在 Netty 的使用模式下比对应的 JDK 实现快数倍甚至数十倍。本文聚焦三个核心工具类：FastThreadLocal——通过数组下标替代哈希表，将 ThreadLocal 的 get/set 操作从 O(n) 的哈希冲突检测降为严格的 O(1)；HashedWheelTimer——用时间轮算法将大量定时任务的调度从 ScheduledThreadPoolExecutor 的 O(log n) 降为 O(1)，专门针对”大量任务、精度要求不高”的网络超时场景；MpscQueue（多生产者单消费者无锁队列）——JCTools 提供的 CAS 无锁队列，相比 LinkedBlockingQueue 消除了锁竞争，在 EventLoop 任务提交场景下吞吐量提升显著。理解这三个组件，不仅能掌握 Netty 性能的”最后一公里”，也能将这些思路应用到自己的高性能系统设计中。

第 1 章 FastThreadLocal：比 ThreadLocal 快的线程本地变量

1.1 JDK ThreadLocal 的性能瓶颈

在 Java 中，ThreadLocal 是实现线程本地变量的标准机制。每个 Thread 对象内部有一个 ThreadLocalMap，其中存储了该线程所有 ThreadLocal 变量的值。

理解 ThreadLocal 的性能问题，需要先看 ThreadLocalMap 的实现。ThreadLocalMap 是一个定制的哈希表，以 ThreadLocal 对象本身作为 Key，以变量值作为 Value：

// JDK ThreadLocalMap 内部结构（简化）
static class ThreadLocalMap {
    // Entry 数组（哈希表，使用线性探测解决冲突）
    private Entry[] table;
    
    // 哈希计算：使用 ThreadLocal 的 threadLocalHashCode
    // threadLocalHashCode 是一个递增的 ID，步长为 0x61c88647（黄金比例哈希）
    private int nextIndex(int i, int len) {
        return ((i + 1 < len) ? i + 1 : 0);  // 线性探测：找下一个位置
    }
    
    // get 操作
    private Entry getEntry(ThreadLocal<?> key) {
        int i = key.threadLocalHashCode & (table.length - 1);  // 计算哈希位置
        Entry e = table[i];
        if (e != null && e.get() == key) {
            return e;  // 命中
        } else {
            return getEntryAfterMiss(key, i, e);  // 发生哈希冲突，线性探测
        }
    }
}

ThreadLocalMap 使用开放地址法（线性探测）解决哈希冲突：如果 key.threadLocalHashCode & (len-1) 位置已被占用，就线性向后找下一个空位。这意味着：

哈希冲突发生时，get() 需要多次数组访问才能找到正确的 Entry；
Entry 是 WeakReference——在探测过程中还需要清理已被 GC 回收的 Key 对应的 Entry（stale entry 清理），增加了额外开销；
在同一个线程使用了大量 ThreadLocal 时（Netty 的 EventLoop 线程正是如此），冲突概率增加，性能下降。

1.2 FastThreadLocal 的设计思路

Netty 的 FastThreadLocal 采用了完全不同的思路：不用哈希表，改用数组下标直接寻址。

每个 FastThreadLocal 实例在创建时，从一个全局原子计数器获取一个唯一的、单调递增的整数下标 index：

public class FastThreadLocal<V> {
    // 全局下标分配器
    private static final AtomicInteger nextIndex = new AtomicInteger(0);
    
    // 每个 FastThreadLocal 实例的唯一下标
    private final int index;
    
    public FastThreadLocal() {
        // 在构造时分配固定下标，之后不变
        index = nextIndex.getAndIncrement();  // 0, 1, 2, 3, ...
    }
}

每个 FastThreadLocalThread（Netty 对 Thread 的子类，EventLoop 线程就是这种类型）持有一个 InternalThreadLocalMap，其核心是一个 Object[] 数组：

public final class InternalThreadLocalMap {
    // 实际存储数据的数组
    // 数组下标就是 FastThreadLocal 的 index
    Object[] indexedVariables;
    
    // 获取当前线程的 InternalThreadLocalMap
    public static InternalThreadLocalMap get() {
        Thread thread = Thread.currentThread();
        if (thread instanceof FastThreadLocalThread) {
            // FastThreadLocalThread 直接持有引用，O(1)
            return ((FastThreadLocalThread) thread).threadLocalMap();
        } else {
            // 普通线程：通过 JDK ThreadLocal 获取，有哈希表开销
            return slowGet();
        }
    }
}

FastThreadLocal.get() 的实现：

public final V get() {
    // 获取当前线程的 InternalThreadLocalMap（O(1) 字段访问）
    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
    // 用固定下标直接访问数组（O(1) 数组寻址，无哈希计算，无冲突）
    Object v = threadLocalMap.indexedVariable(index);
    if (v != InternalThreadLocalMap.UNSET) {
        return (V) v;
    }
    // 首次访问：初始化默认值
    return initialize(threadLocalMap);
}
 
public final void set(V value) {
    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.get();
    // 直接数组写入，O(1)
    threadLocalMap.setIndexedVariable(index, value);
}

1.3 性能差异的量化分析

FastThreadLocal 相比 JDK ThreadLocal 的性能优势体现在：

操作	JDK ThreadLocal	FastThreadLocal
`get()`（无冲突）	哈希计算 + 1次数组访问	1次字段访问 + 1次数组访问
`get()`（有冲突）	哈希计算 + N次线性探测	同上（永远无冲突）
`set()`	哈希计算 + 寻址 + 可能扩容	数组写入（可能扩容）
内存布局	稀疏的 Entry 链（WeakReference 包装）	紧凑的 Object 数组

在 Netty 的 EventLoop 线程中，FastThreadLocal 使用频率极高（PoolThreadCache、Recycler 对象池等都依赖它），即使单次 get() 的性能差异只有几十纳秒，在每秒处理数十万次操作的场景下，积累效应也是可观的。

普通线程使用 FastThreadLocal

如果当前线程不是 FastThreadLocalThread（如业务线程池使用了普通 Thread），FastThreadLocal 会退化为通过 JDK ThreadLocal 存储 InternalThreadLocalMap，失去性能优势。

解决方案：使用 DefaultThreadFactory 创建线程，它会生成 FastThreadLocalThread 子类线程，从而使 FastThreadLocal 生效。

1.4 内存泄漏防护：removeAll()

JDK ThreadLocal 有一个众所周知的内存泄漏问题：使用线程池时，线程会被复用，但 ThreadLocalMap 中的 Entry 如果没有显式 remove()，会一直存在于线程的生命周期中。

FastThreadLocal 通过一个全局 Set 记录了所有在当前线程中被设置过值的 FastThreadLocal 实例，在 Netty 内部（如 EventLoop 关闭时）调用 FastThreadLocal.removeAll() 一次性清理所有值：

// FastThreadLocal 内部的清理机制
public static void removeAll() {
    InternalThreadLocalMap threadLocalMap = InternalThreadLocalMap.getIfSet();
    if (threadLocalMap == null) return;
    
    try {
        // 遍历所有在本线程中设置过值的 FastThreadLocal，逐一清理
        Object v = threadLocalMap.indexedVariable(variablesToRemoveIndex);
        if (v != null && v != InternalThreadLocalMap.UNSET) {
            Set<FastThreadLocal<?>> variablesToRemove = (Set<FastThreadLocal<?>>) v;
            FastThreadLocal<?>[] variablesToRemoveArray = 
                variablesToRemove.toArray(new FastThreadLocal[0]);
            for (FastThreadLocal<?> tlv : variablesToRemoveArray) {
                tlv.remove(threadLocalMap);  // 调用每个 FastThreadLocal 的 onRemoval 钩子
            }
        }
    } finally {
        InternalThreadLocalMap.remove();  // 最终清理整个 Map
    }
}

这个机制确保 EventLoop 线程关闭时，所有线程本地变量都被正确清理，不会造成内存泄漏。

第 2 章 HashedWheelTimer：O(1) 的定时任务调度

2.1 网络编程中的大量定时任务

在网络服务器中，定时任务无处不在：

连接超时检测（如 30 秒内无数据则关闭连接）；
心跳定时发送（如每 10 秒发送一次 Keepalive）；
请求超时（RPC 调用在 3 秒内未收到响应则失败）；
重连定时器（连接断开后 5 秒重试）。

一个拥有 10 万个连接的服务器，可能同时有 10 万个定时任务处于活跃状态。用什么数据结构管理这些定时任务？

2.2 JDK ScheduledThreadPoolExecutor 的代价

JDK 的定时任务调度器 ScheduledThreadPoolExecutor 内部使用**堆（优先队列）**管理任务，按执行时间排序。

添加任务：O(log n)
取消任务：O(log n)
执行到期任务：O(log n)（弹出堆顶并调整堆）

对于 10 万个任务，每次操作的 log₂(100000) ≈ 17 次比较，在高并发下（大量任务频繁添加/取消）性能会成为瓶颈。

更关键的问题是：网络超时任务通常在触发之前就被取消了。比如 RPC 请求的 3 秒超时定时器——90% 的请求在 100ms 内就收到了响应，超时定时器在触发前被取消。取消操作在堆中同样是 O(log n)，对于大量的”添加后快速取消”场景，ScheduledThreadPoolExecutor 的开销相当浪费。

2.3 HashedWheelTimer：时间轮算法

时间轮（Timing Wheel）算法由 Varghese 和 Lauck 于 1987 年在论文《Hashed and Hierarchical Timing Wheels》中提出，专为大规模网络超时管理而设计。

核心思想是将时间范围”取模映射”到一个环形数组（时间轮）的槽位：

时间轮（512个槽，每槽 100ms）：

     0        1        2        3        ...
  [任务]   [任务]   [任务]   [任务]   ...  [512个槽]
     ↑
  当前指针（每隔 100ms 前进一槽）

轮子大小（ticksPerWheel）：默认 512 个槽；
每槽时间（tickDuration）：默认 100 毫秒；
总覆盖时间：512 × 100ms = 51.2 秒（超过这个时间的任务需要多转几圈）。

添加一个 N 毫秒后执行的任务：

槽位 = (当前指针位置 + N / tickDuration) % ticksPerWheel
剩余圈数 = N / (ticksPerWheel × tickDuration)  （需要转几整圈才到执行时间）

将任务放入对应槽位的链表中，同时记录”还需转几圈”。

时间轮每隔 tickDuration 前进一格，检查当前槽位的任务链表，执行 remainingRounds == 0 的任务（同时将其他任务的 remainingRounds--）。

2.4 HashedWheelTimer 的操作复杂度

操作	复杂度	说明
添加任务	O(1)	计算槽位 + 链表头插入
取消任务	O(1)	标记 `CANCELLED`（不从链表删除，下次推进时跳过）
执行到期任务	O(m)（m 为当前槽中的任务数）	遍历当前槽的链表

相比 ScheduledThreadPoolExecutor 的 O(log n)，时间轮的添加和取消都是 O(1)。对于网络超时这种”大量任务、精度要求不高（100ms 级别即可）、大量任务在触发前被取消”的场景，时间轮的优势极其显著。

2.5 HashedWheelTimer 的实现细节

// HashedWheelTimer 的使用
HashedWheelTimer timer = new HashedWheelTimer(
    100, TimeUnit.MILLISECONDS,  // tickDuration = 100ms
    512                          // ticksPerWheel = 512 个槽
);
 
// 添加超时任务
Timeout timeout = timer.newTimeout(
    t -> {
        // 3 秒后执行（如果没有被取消）
        log.warn("RPC 请求超时！");
        channel.close();
    },
    3, TimeUnit.SECONDS
);
 
// 收到响应时取消超时
timeout.cancel();  // O(1)，只是标记，不需要从时间轮中删除

HashedWheelTimer 的内部运作：

// HashedWheelTimer 核心结构（简化）
public class HashedWheelTimer implements Timer {
    private final HashedWheelBucket[] wheel;  // 时间轮槽位数组
    private final long tickDuration;           // 每槽时间（纳秒）
    private final int mask;                    // = wheel.length - 1，用于取模运算
    
    // 等待添加的任务（来自其他线程的提交，先放队列，由 Worker 线程统一处理）
    private final Queue<HashedWheelTimeout> timeouts = PlatformDependent.newMpscQueue();
    
    // Worker 线程：推动时间轮转动
    private final Worker worker = new Worker();
    
    private final class Worker implements Runnable {
        private long tick;  // 已经推进了多少 tick
        
        @Override
        public void run() {
            startTime = System.nanoTime();
            
            do {
                // 等待到下一个 tick 的时刻
                final long deadline = waitForNextTick();
                if (deadline > 0) {
                    int idx = (int) (tick & mask);  // 当前槽位 = tick % wheel.length
                    processCancelledTasks();          // 处理待取消任务
                    HashedWheelBucket bucket = wheel[idx];
                    transferTimeoutsToBuckets();       // 将新提交的任务放入对应槽位
                    bucket.expireTimeouts(deadline);   // 执行当前槽中到期任务
                    tick++;
                }
            } while (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_STARTED);
            
            // 关闭时：将未执行的任务收集起来
            for (HashedWheelBucket bucket : wheel) {
                bucket.clearTimeouts(unprocessedTimeouts);
            }
        }
        
        // 精确等待到下一个 tick 时刻（使用 Thread.sleep 和忙等结合）
        private long waitForNextTick() {
            long deadline = tickDuration * (tick + 1);
            for (;;) {
                final long currentTime = System.nanoTime() - startTime;
                long sleepTimeMs = (deadline - currentTime + 999999) / 1000000;
                if (sleepTimeMs <= 0) {
                    return currentTime;  // 时刻到了
                }
                if (PlatformDependent.isWindows()) {
                    sleepTimeMs = sleepTimeMs / 10 * 10;  // Windows 时钟精度修正
                    if (sleepTimeMs == 0) sleepTimeMs = 1;
                }
                try {
                    Thread.sleep(sleepTimeMs);
                } catch (InterruptedException e) {
                    if (WORKER_STATE_UPDATER.get(HashedWheelTimer.this) == WORKER_STATE_SHUTDOWN) {
                        return Long.MIN_VALUE;
                    }
                }
            }
        }
    }
}

2.6 HashedWheelTimer 的局限性

时间轮并非适合所有定时场景，它有几个重要的限制：

精度有限：时间轮的精度由 tickDuration 决定。默认 100ms 的 tickDuration 意味着定时任务的实际触发时间可能比预期晚 0～100ms。对于需要毫秒级精度的场景，应减小 tickDuration（但会增加 CPU 空转开销）。

单线程推进：所有槽位的任务都由一个 Worker 线程执行。如果某个槽位有大量任务，会导致后续槽位的任务执行延迟。在回调中不要执行耗时操作，否则会阻塞 Worker 线程，所有后续定时任务都会延迟。

不适合少量、高精度的定时任务：对于只有几十个任务的场景，ScheduledThreadPoolExecutor 的 O(log n) 开销完全可以接受，不需要引入 HashedWheelTimer 的复杂性。

生产环境中 HashedWheelTimer 的常见错误

在回调中直接执行阻塞操作（如数据库查询、同步 HTTP 调用）——Worker 线程被阻塞，所有后续定时任务无法执行；

不调用 timer.stop() 关闭定时器——Worker 线程会一直运行，造成线程泄漏；

添加过多任务到同一个槽位——当该槽位被推进时，O(m) 的遍历会变成瓶颈。

第 3 章 MpscQueue：无锁的多生产者单消费者队列

3.1 EventLoop 任务提交的并发模型

EventLoop 的任务队列是一个典型的 MPSC（Multi-Producer Single-Consumer，多生产者单消费者）场景：

多生产者：来自不同线程（业务线程池、定时器线程、外部调用者）同时向 EventLoop 提交任务；
单消费者：只有 EventLoop 线程自己从队列中取任务执行。

JDK 的 LinkedBlockingQueue 使用 ReentrantLock（内部有 takeLock 和 putLock 两把锁）保护并发访问。在 MPSC 场景下，takeLock 只有一个消费者竞争，实际上根本不需要；putLock 在多个生产者之间竞争，是真实的瓶颈。

锁竞争的代价不仅是锁自身的 CAS 操作，还包括：

线程上下文切换（等待锁的线程被挂起，获取锁后被唤醒）；
CPU 缓存失效（锁的内存屏障导致缓存行失效）；
JIT 优化受限（锁使 JIT 难以做激进的优化）。

3.2 MpscArrayQueue：基于 CAS 的无锁实现

Netty 使用 JCTools 库提供的 MpscArrayQueue（有界版本）或 MpscLinkedQueue（无界版本）替代 LinkedBlockingQueue。

MpscArrayQueue 是一个固定大小的环形数组队列，通过精心设计的 CAS 操作实现无锁并发。

核心数据结构：

// MpscArrayQueue 核心字段（伪代码，实际有大量 padding 避免 false sharing）
public class MpscArrayQueue<E> extends MpscArrayQueueL3Pad<E> {
    // 生产者序号（多个生产者竞争更新这个字段）
    protected volatile long producerIndex;
    
    // 消费者序号（只有一个消费者更新，无需竞争）
    protected long consumerIndex;
    
    // 环形数组
    protected final E[] buffer;
    
    // 数组大小（必须是 2 的幂，用于取模优化：index & mask）
    private final int mask;
}

生产者写入（offer）：

public boolean offer(final E e) {
    final long mask = this.mask;
    final long capacity = mask + 1;
    
    long producerIndex = lvProducerIndex();  // volatile 读取
    long consumerIndex;
    
    for (;;) {
        // 检查队列是否已满
        consumerIndex = lvConsumerIndex();  // volatile 读取
        if (producerIndex - consumerIndex < capacity) {
            // 队列未满：尝试 CAS 获取写入位置
            if (casProducerIndex(producerIndex, producerIndex + 1)) {
                // CAS 成功：获得了独占的写入位置 producerIndex
                // 将元素写入数组
                soElement(buffer, producerIndex & mask, e);  // ordered store
                return true;
            }
            // CAS 失败：其他生产者抢先了，重试
            producerIndex = lvProducerIndex();
        } else {
            // 队列已满：写入失败
            return false;
        }
    }
}

消费者读取（poll）：

public E poll() {
    // 消费者只有一个，consumerIndex 更新无需 CAS
    final long consumerIndex = lpConsumerIndex();  // plain load（无内存屏障）
    final long offset = consumerIndex & mask;
    
    E e = lvElement(buffer, offset);  // volatile 读取元素
    if (null == e) {
        return null;  // 队列为空（生产者还未写入）
    }
    
    // 清除数组中的元素引用（帮助 GC）
    spElement(buffer, offset, null);  // plain store
    
    // 更新消费者序号（只有一个消费者，无需 CAS）
    soConsumerIndex(consumerIndex + 1);  // ordered store
    return e;
}

MpscArrayQueue 的性能优化中有一个极其精妙的细节——通过大量的 long 字段填充（Padding）消除伪共享（False Sharing）。

现代 CPU 的缓存以”缓存行”（Cache Line，通常 64 字节）为单位管理数据。如果两个不相关的变量恰好在同一个缓存行中，线程 A 修改变量 1 会导致线程 B 缓存的变量 2 失效（即使变量 2 没有被修改），这就是伪共享。

在 MpscArrayQueue 中，producerIndex 和 consumerIndex 是两个独立修改的变量——多个生产者竞争修改 producerIndex，只有一个消费者修改 consumerIndex。如果它们在同一缓存行，对 producerIndex 的频繁 CAS 会使消费者的 consumerIndex 缓存行频繁失效，反之亦然。

解决方案是在两个关键字段前后各填充 7 个 long（56 字节），使每个关键字段独占一个缓存行（64 字节 = 8字节字段 + 56字节填充）：

// JCTools 的 Padding 层次结构（简化）
abstract class MpscArrayQueueL1Pad<E> extends ConcurrentCircularArrayQueue<E> {
    long p10, p11, p12, p13, p14, p15, p16;  // 填充 56 字节
}
 
abstract class MpscArrayQueueProducerIndexField<E> extends MpscArrayQueueL1Pad<E> {
    volatile long producerIndex;  // 独占一个缓存行（8字节字段 + 前后各56字节填充）
}
 
abstract class MpscArrayQueueL2Pad<E> extends MpscArrayQueueProducerIndexField<E> {
    long p20, p21, p22, p23, p24, p25, p26;  // 填充 56 字节
}
 
abstract class MpscArrayQueueConsumerIndexField<E> extends MpscArrayQueueL2Pad<E> {
    volatile long consumerIndex;  // 独占另一个缓存行
}

这个 Padding 技巧在高并发性能优化中被广泛应用，JDK 8 也为此引入了 @Contended 注解（需要 JVM 参数 -XX:-RestrictContended 才能生效）。Netty 使用手动 Padding 而非 @Contended，是为了兼容 JDK 6+。

3.4 MpscQueue vs LinkedBlockingQueue：性能对比

在典型的 EventLoop 任务提交场景（4 个生产者，1 个消费者，队列大小 1024）中，JCTools 的基准测试结果：

队列实现	吞吐量（百万 ops/s）	延迟（99th percentile）
`LinkedBlockingQueue`	~8	~500ns
`MpscArrayQueue`	~80	~50ns

在高并发场景下，MpscArrayQueue 的吞吐量约是 LinkedBlockingQueue 的 10 倍，延迟约为后者的 1/10。

这个差距的来源：

消除了 ReentrantLock 的 park()/unpark() 线程唤醒开销（每次约 200ns）；
CAS 操作在竞争不激烈时只需要一次原子指令（约 30ns）；
消除了 False Sharing 后，CPU 缓存利用率更高。

第 4 章 Recycler：对象池减少对象创建

4.1 为什么 Netty 需要对象池

除了 ByteBuf 的内存池，Netty 还实现了 Recycler——一个通用的对象池。对象池的目标是复用频繁创建和销毁的对象，减少 GC 压力。

在 Netty 中，PooledByteBuf 对象本身（注意区分：对象 vs 内存——内存由 jemalloc 管理，对象由 Recycler 管理）、DefaultChannelPromise、各种 Task 对象等都通过 Recycler 复用。

4.2 Recycler 的线程本地栈设计

Recycler 基于 FastThreadLocal 实现线程本地对象栈：

// 对象池的使用模式
public abstract class Recycler<T> {
    // 每个线程持有自己的对象栈（通过 FastThreadLocal）
    private final FastThreadLocal<Stack<T>> threadLocal = new FastThreadLocal<Stack<T>>() {
        @Override
        protected Stack<T> initialValue() {
            return new Stack<T>(Recycler.this, Thread.currentThread(),
                maxCapacityPerThread, maxSharedCapacityFactor,
                interval, maxDelayedQueuesPerThread);
        }
    };
    
    // 获取对象（从当前线程的栈顶取）
    public final T get() {
        Stack<T> stack = threadLocal.get();
        DefaultHandle<T> handle = stack.pop();
        if (handle == null) {
            handle = stack.newHandle();
            handle.value = newObject(handle);  // 调用子类实现创建新对象
        }
        return handle.value;  // 返回复用的对象（或新创建的对象）
    }
}
 
// 使用示例：PooledDirectByteBuf
private static final Recycler<PooledDirectByteBuf> RECYCLER = new Recycler<PooledDirectByteBuf>() {
    @Override
    protected PooledDirectByteBuf newObject(Handle<PooledDirectByteBuf> handle) {
        return new PooledDirectByteBuf(handle, 0);
    }
};
 
static PooledDirectByteBuf newInstance(int maxCapacity) {
    PooledDirectByteBuf buf = RECYCLER.get();  // 从对象池取
    buf.reuse(maxCapacity);  // 重置状态
    return buf;
}
 
// 对象归还（在 release() 中调用）
@Override
protected final void deallocate() {
    handle.recycle(this);  // 归还到对象池
}

总结

Netty 的高性能不是单一技术的功劳，而是大量精心设计的小优化叠加的结果。本文介绍的三个工具类体现了 Netty 工程师的极致优化思路：

FastThreadLocal 用数组下标取代哈希表，将 ThreadLocal 的 get/set 操作去除了哈希冲突的不确定性，在 EventLoop 线程中（大量使用线程本地变量）效果显著；同时通过 removeAll() 机制防止线程复用时的内存泄漏；
HashedWheelTimer 用时间轮算法将定时任务的添加和取消降为 O(1)，专门针对网络超时场景（大量任务、精度要求 100ms 级别、大量任务在触发前被取消）；单线程 Worker 推进时间轮，回调中绝不能有阻塞操作；
MpscArrayQueue 通过 CAS 无锁化任务队列的多生产者写入，消除了 LinkedBlockingQueue 的锁竞争，配合 Padding 技术消除 False Sharing，在 EventLoop 任务提交场景下吞吐量提升一个数量级；
Recycler 对象池 通过 FastThreadLocal 实现线程本地对象栈，复用 PooledByteBuf 等频繁创建/销毁的对象，减少 GC 压力。

这些优化的共同思路是：针对特定使用模式（单消费者、EventLoop 固定线程、网络超时特征）做专项优化，而非追求通用性。当你在系统中遇到类似的性能瓶颈时，这些思路同样可以借鉴。

下一篇将这些组件汇聚到一个实战场景——基于 Netty 设计一个完整的 RPC 框架：序列化方案的选择、服务注册与路由、连接池管理：09 基于Netty的RPC框架设计——序列化、路由与连接管理。

参考资料

io.netty.util.concurrent.FastThreadLocal 源码

io.netty.util.HashedWheelTimer 源码

JCTools MpscArrayQueue 源码

Gil Tene,《False Sharing》, Azul Systems

Varghese & Lauck,《Hashed and Hierarchical Timing Wheels》, 1987

思考题

Netty 服务端启动时，ServerBootstrap.bind() 触发了一系列异步操作：创建 ServerSocketChannel、注册到 BossGroup 的 EventLoop、绑定端口。这些操作都是在 EventLoop 线程中执行的。如果在 bind() 返回的 ChannelFuture 上调用 sync() 阻塞等待，而此时代码运行在 EventLoop 线程上，会发生什么？为什么？

新连接接入时，BossGroup 的 EventLoop 调用 ServerSocketChannel.accept() 获取 SocketChannel，然后通过 ServerBootstrapAcceptor 将其注册到 WorkerGroup。ServerBootstrapAcceptor 是在 BossGroup 还是 WorkerGroup 的线程中执行？将 SocketChannel 注册到 WorkerGroup 的选择策略是轮询（Round-Robin）还是最少连接？

Netty 的 ChannelOption.SO_BACKLOG 设置 TCP 连接队列的大小。当 BossGroup 来不及 accept() 新连接时，连接会排在 OS 的 backlog 队列中。如果 backlog 满了，新的 TCP 连接请求会被拒绝还是丢弃？Linux 的 tcp_abort_on_overflow 参数如何影响这个行为？

汀的知识碎片

文章导航

08 Netty高性能之道——FastThreadLocal、HashedWheelTimer与无锁队列

Netty高性能之道——FastThreadLocal、HashedWheelTimer与无锁队列

摘要

第 1 章 FastThreadLocal：比 ThreadLocal 快的线程本地变量

1.1 JDK ThreadLocal 的性能瓶颈

1.2 FastThreadLocal 的设计思路

1.3 性能差异的量化分析

1.4 内存泄漏防护：removeAll()

第 2 章 HashedWheelTimer：O(1) 的定时任务调度

2.1 网络编程中的大量定时任务

2.2 JDK ScheduledThreadPoolExecutor 的代价

2.3 HashedWheelTimer：时间轮算法

2.4 HashedWheelTimer 的操作复杂度

2.5 HashedWheelTimer 的实现细节

2.6 HashedWheelTimer 的局限性

第 3 章 MpscQueue：无锁的多生产者单消费者队列

3.1 EventLoop 任务提交的并发模型

3.2 MpscArrayQueue：基于 CAS 的无锁实现

3.4 MpscQueue vs LinkedBlockingQueue：性能对比

第 4 章 Recycler：对象池减少对象创建

4.1 为什么 Netty 需要对象池

4.2 Recycler 的线程本地栈设计

总结

On this page

Backlinks

汀的知识碎片

文章导航

08 Netty高性能之道——FastThreadLocal、HashedWheelTimer与无锁队列

Netty高性能之道——FastThreadLocal、HashedWheelTimer与无锁队列

摘要

第 1 章 FastThreadLocal：比 ThreadLocal 快的线程本地变量

1.1 JDK ThreadLocal 的性能瓶颈

1.2 FastThreadLocal 的设计思路

1.3 性能差异的量化分析

1.4 内存泄漏防护：removeAll()

第 2 章 HashedWheelTimer：O(1) 的定时任务调度

2.1 网络编程中的大量定时任务

2.2 JDK ScheduledThreadPoolExecutor 的代价

2.3 HashedWheelTimer：时间轮算法

2.4 HashedWheelTimer 的操作复杂度

2.5 HashedWheelTimer 的实现细节

2.6 HashedWheelTimer 的局限性

第 3 章 MpscQueue：无锁的多生产者单消费者队列

3.1 EventLoop 任务提交的并发模型

3.2 MpscArrayQueue：基于 CAS 的无锁实现

3.3 False Sharing 的消除：Padding 技术

3.4 MpscQueue vs LinkedBlockingQueue：性能对比

第 4 章 Recycler：对象池减少对象创建

4.1 为什么 Netty 需要对象池

4.2 Recycler 的线程本地栈设计

总结

On this page

Backlinks