未调用release方法时Netty内存泄漏的成因及相关疑问

最近我特意研究了Netty内存泄漏相关的内容，涵盖了ReferenceCounted对象的原理、手动引用计数的处理规范、缓冲区所有权的边界，还有ChannelOutboundHandler刷缓冲区泄漏这类具体场景的分析。

我目前的核心理解 #

• 我搞清楚了一个关键点：如果应用用完Netty的资源后没有手动释放，虽然JVM的GC最终会回收底层的实际内存，但Netty自身的内存池大小会持续膨胀，进而引发内存泄漏问题。这和普通Java对象的内存回收逻辑差异很大，核心原因在于Netty的内存池复用机制——它不会主动感知GC回收的对象，只认手动调用的引用计数操作。

想请教的几个技术问题 #

• 既然GC能回收实际内存，那Netty内存池里那些“已分配但未手动release()”的缓冲区，为什么不能被内存池自动检测并回收复用？是不是内存池的追踪机制完全依赖手动的release()/retain()调用，和GC的对象回收状态完全脱节？
• 在ChannelOutboundHandler的场景中，当调用flush()之后，缓冲区的引用计数有没有隐性的自动处理逻辑？比如有些场景下Netty会自动帮我们调用release()，但有些场景下必须手动处理，这个判断边界到底怎么界定？
• 对于自定义的ReferenceCounted实现类，有没有通用的最佳实践来避免内存泄漏？比如要不要在finalize()方法里加兜底的release()逻辑？但又听说finalize()会影响性能，这中间该怎么权衡？
• 当内存池因为未释放的资源持续增长后，有没有自我收缩的机制？比如长时间闲置的池化内存会不会被自动清理，还是只能靠手动配置参数来限制内存池的最大大小？

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