直接调大-XX:MaxDirectMemorySize仅推迟溢出，真正解决需匹配Netty使用模式：基于连接数、单缓冲大小与并发量估算合理值（如5000连接×2×32KB≈312MB，建议设512MB），并显式配置PooledByteBufAllocator的preferredDirectMemory为该值80%，关闭tiny cache以减少碎片。
直接调大 -xx:maxdirectmemorysize 并不能“解决” netty 堆外内存溢出，它只是把溢出的阈值往后推——真正的控制在于让这个参数与 netty 的实际使用模式匹配，形成可预期、可监控、可收敛的红线。
理解 MaxDirectMemorySize 的真实作用边界
该 JVM 参数限制的是整个进程能申请的堆外内存总量（不包括 JNI 分配、Unsafe.allocateMemory 等非 Netty 路径），但 Netty 自身有一套独立的内存计数器（PlatformDependent.usedDirectMemory()）。当 Netty 分配 DirectBuffer 时，会先检查：
① 是否超过 -XX:MaxDirectMemorySize；
② 是否超过 Netty 内部的 maxDirectMemory（默认等于 JVM 参数值）；
两者任一超限即抛 OutOfDirectMemoryError。
所以它不是“Netty 专用开关”，而是 JVM 层的硬闸门，必须和 Netty 的内存管理策略协同设置。
根据业务流量特征反推合理初始值
不要凭空设 2G 或 4G。应基于典型请求负载估算：
• 单连接平均并发 ByteBuf 数量（如：1 个读缓冲 + 1 个写缓冲 + 可能的解码临时缓冲）
• 单缓冲典型大小（如 HTTP/1.1 常用 8KB～64KB；gRPC 流式场景可能达 1MB+）
• 预期最大连接数（注意：不是峰值 QPS，是长连接保有量）
举例：若单连接稳定占用 2 个 32KB DirectBuffer，最大连接数为 5000，则基础需求 ≈ 2 × 32KB × 5000 = 312MB。再叠加 30% 缓冲余量、协议头膨胀、突发批量写等，建议初始设为 512MB（即 -XX:MaxDirectMemorySize=512m）。
配合 Netty 的 PooledByteBufAllocator 精准对齐
Netty 默认启用池化（PooledByteBufAllocator），其内部 Chunk 和 Page 大小会影响实际内存占用粒度。若 -XX:MaxDirectMemorySize 设得过小，会导致：
• PoolArena 频繁扩容失败，退化为 unpooled 分配，加剧碎片
• 小缓冲反复申请/释放，触发底层 mmap/munmap 开销上升
推荐做法：
• 显式构造 PooledByteBufAllocator，传入 preferredDirectMemory（建议设为 MaxDirectMemorySize × 0.8）
• 关闭 tiny cache（tinyCacheSize=0）若业务无大量 • 调整 pageSize（如设为 8192）与常见缓冲对齐，减少内部碎片
必须配套的可观测手段
仅设参数不监控，等于没设红线：
• 暴露 PlatformDependent.usedDirectMemory() 到 Prometheus 指标（如 jvm_direct_memory_used_bytes）
• 在 Netty ChannelHandler 中捕获 OutOfDirectMemoryError 并记录当前 usedDirectMemory 值与活跃连接数
• 使用 jcmd <pid> VM.native_memory summary</pid> 定期快照，确认是否真由 Netty 主导（排除 JNI 或第三方库泄漏）
• 设置告警：当 usedDirectMemory / MaxDirectMemorySize > 0.85 且持续 2 分钟，即触发预警
