应复用缓冲区、优先堆外内存、调优年轻代与gc策略、协议层合并缓冲。具体包括：池化bytebuffer或threadlocal byte[]、用directbuffer避开堆gc、增大eden区并选g1 gc、tcp粘包合并及预分配缓冲。
千兆或万兆网络 I/O 频繁分配临时缓冲区（如 byte[]、ByteBuffer）时，容易在 Eden 区大量创建短生命周期对象，导致年轻代快速填满，触发高频 Minor GC。这不是“GC 本身有问题”，而是对象分配节奏与回收能力失衡——关键在于减少新对象生成、复用已有缓冲、控制分配规模。
复用堆内缓冲池，避免每次 new byte[]
频繁调用 new byte[8192] 或类似操作，哪怕单个不大，累积起来也会压垮 Eden 区。应统一管理缓冲区生命周期：
- 使用
ByteBuffer.allocate()+ 池化框架（如 Netty 的PooledByteBufAllocator），而非裸 new 数组 - 自建轻量级缓冲池：用
ThreadLocal<byte></byte>绑定线程级缓冲，避免多线程竞争；或用 LRU 管理固定大小的缓冲数组池 - 注意：不要无限制扩容池，需设最大缓存数（如最多缓存 50 个 64KB 缓冲），防止内存驻留过久反向挤压 Survivor 区
优先使用堆外内存处理高吞吐 I/O
堆外内存（DirectBuffer）不参与堆 GC，能彻底规避年轻代压力，特别适合万兆网卡持续收发场景：
- 用
ByteBuffer.allocateDirect(65536)替代堆内分配，配合cleaner或显式free()（Netty 中自动管理） - JVM 参数需配合调整：
-XX:MaxDirectMemorySize=512m防止堆外 OOM；-XX:+DisableExplicitGC禁用System.gc()对 DirectBuffer 的误触发 - 注意：堆外内存不受 GC 控制，泄漏会导致进程 RSS 持续上涨，务必确保释放路径完整（尤其异常分支）
按流量特征调节年轻代大小与 GC 策略
网络 I/O 的对象生命周期高度规律（通常一个请求/响应周期内即失效），需让 GC 节奏匹配这一节奏：
- 增大 Eden 区占比（如
-XX:NewRatio=2或直接-Xmn2g），降低 Minor GC 频率；但不宜过大，否则单次 GC 停顿延长 - 选用低延迟 GC：G1（
-XX:+UseG1GC）比 Parallel 更适合 I/O 密集型服务，可设置-XX:MaxGCPauseMillis=50主动约束停顿 - 监控
SurvivorUsage：若 Survivor 区长期接近 0%，说明对象几乎不存活到下一次 GC，可调小 SurvivorRatio（如-XX:SurvivorRatio=8），腾出空间给 Eden
协议层做缓冲合并与预分配
很多高频分配源于协议解析粒度过细（如每收到一个 TCP 包就 new 一次 buffer），应在框架层收敛：
- 启用 TCP 粘包合并：Netty 中配置
LengthFieldBasedFrameDecoder或ReplayingDecoder，批量处理多个逻辑消息，减少 decode 次数 - 对已知长度的消息（如固定头+变长体），预先计算所需 buffer 大小，复用同一块内存解析，避免多次 resize
- 禁用日志级全量 dump：调试时打印 request body 前检查长度，超 1KB 就截断，防止
toString()触发隐式大字符串构造
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
