怎么利用 Netty 的 Recyclable 对象池技术实现在超高吞吐环境下对小对象的零 GC 压力

先说结论：Netty的Recycler本身并不能打包票实现“零GC”，但在超高吞吐的场景下，只要用得对，它确实能把小对象的GC压力压到几乎可以忽略不计的程度。前提是什么？你得避开几个坑：跨线程误回收、容量阈值没控好、还有那些本该重置的状态没清干净。

那么，这个池子到底怎么用，才能让GC几乎“绝迹”呢？我们来拆开聊。

Recycler 不是万能的：哪些对象适合池化

想享受池化红利，得先看看你的对象够不够“资格”。满足下面所有条件的，才值得往里扔：

• 生命周期短、创建销毁频率极高——比如每秒几万次的那种。
• 构造开销明显——字段初始化、集合预分配这些操作，每次new一下都挺费劲的。
• 逻辑状态能安全重置——recycle()之前必须把业务字段清干净，否则下次get()出来的就是“脏数据”。
• 不逃逸出创建线程——换句话说，别让其他线程长期持有或共享这个对象。

典型的例子：HttpRequest/HttpResponse的包装器、自定义协议帧的解析器、以及HandlerContext这类辅助对象。反例也有：那些带着外部引用的回调闭包、绑了ThreadLocal的单例包装器、还有忘了重写recycle()的子类——这类扔进池子，不仅没用，还容易出幺蛾子。

必须重写 newObject(Handle) 和 recycle()

直接继承Recycler可不等于自动复用——你得自己动手管状态。关键点就几个：

• newObject(Handle)只管返回新实例，别在里面做任何业务初始化，等首次使用时再搞。
• recycle()必须显式重置所有字段：集合要clear()，引用要置null，不然下次get()拿到的就是上一次留下的脏数据。
• 注意：recycle()里别调用super.recycle()——这个动作Recycler内部已经帮你完成了。

看个例子就清楚了：

public class MyEvent extends Recycler.MyObject {
    private String id;
    private int code;

    private MyEvent(Recycler recycler) {
        this.recycler = recycler;
    }

    public static MyEvent newInstance() {
        return RECYCLER.get();
    }

    @Override
    protected void recycle() {
        this.id = null; // 必须清空
        this.code = 0;
        this.recycler.recycle(this); // 注意：不是 super.recycle()
    }

    private static final Recycler RECYCLER = new Recycler() {
        @Override
        protected MyEvent newObject(Handle handle) {
            return new MyEvent(handle);
        }
    };
}

线程本地栈溢出与 DEFAULT_MAX_CAPACITY

每个线程的Stack默认最大容量是4096（Recycler.DEFAULT_MAX_CAPACITY）。超过这个数，新对象就不再入栈了，直接走new分配——好嘛，GC瞬间就被“激活”了。

• 如果压测时发现P99延迟突然增高，GC日志里频繁出现Allocation Failure，十有八九是栈满了。
• 可以通过-Dio.netty.recycler.maxCapacityPerThread=8192调大上限，但别盲目拉高——内存占用会线性增长，而且缓存局部性也会下降。
• 更靠谱的做法：结合监控，在业务低峰期用Stack.size()（需要反射访问）采样各线程的实际占用情况，按95分位来设定上限。

跨线程回收导致 WeakOrderQueue 积压

当A线程创建的对象，被B线程调用了recycle()，它会进入B线程的WeakOrderQueue，然后等A线程下一次调用get()时才能被“迁移”回栈。如果A线程一直闲着，队列就会越积越多——内存泄漏的风险和回收延迟就这么来了。

• 禁令第一条：绝对不要在IO线程之外（比如业务线程池）调用recycle()。
• 如果实在避不开跨线程释放（比如异步回调的场景），可以考虑改用PooledByteBufAllocator配合ByteBuf.release()——它有一套更健壮的跨线程引用计数机制。
• 还可以通过JVM参数-Dio.netty.recycler.delayedQueueRatio=2来加快迁移频率（默认是每8次get()才触发一次迁移）。

说到底，技术实现本身并不复杂，最难的其实是让团队里的每个人都养成肌肉记忆：每次get()之后别忘了recycle()，而且千万别跨线程乱传对象引用。这事儿，靠文档不如靠代码审查和单元测试来得实在。