Java NIO过载防护需四层协同：连接层限流（backlog调优、连接频控、延迟accept）、读写层背压（OP_READ开关、TrafficShapingHandler、水位监控）、内存池化（PooledByteBuf、引用计数）、业务熔断（响应时长熔断、线程池负载调控、协议校验）。
Java NIO 本身不内置过载保护机制，但通过合理组合其核心组件与配套策略，可构建出有效的网络过载防护体系。关键不在“加一层拦截”，而在于从连接接入、数据读写、资源分配到流量调度四个环节协同控压。
连接层限流：控制入口洪峰
避免大量连接瞬间涌入耗尽系统资源，需在最外层设防：
- SO_BACKLOG 参数调优：ServerSocketChannel 的 backlog 决定了内核等待队列长度。默认值（如 Linux 通常为 50–128）在高并发下极易丢连接。建议根据预期瞬时建连速率设为 1024 或更高，并配合 net.core.somaxconn 系统参数同步调整；
- 连接频率限制（Connection Rate Limiting）：在 accept 阶段做 IP 或客户端维度的计数器（如用 Guava RateLimiter 或 Redis 计数），超速则直接 close Channel，不进入后续处理链；
- 延迟 accept（TCP_DEFER_ACCEPT）：Linux 下启用该 socket 选项，让内核只在收到第一个数据包后才通知应用层 accept，减少半开连接堆积。
读写层背压：防止缓冲区雪崩
当下游处理不过来时，必须让上游“慢下来”，而不是任由数据积压：
- 非阻塞读写 + 手动控制 OP_READ：检测到当前连接处理积压（如待处理消息队列超阈值），调用 key.interestOps(0) 暂停监听 OP_READ，等业务线程消费完再恢复；
- 使用 TrafficShapingHandler（Netty 场景）：若基于 Netty，可插入该 handler 实现全局/每连接级的写入速率限制（如 writeLimit=1MB/s）、读取节制或总带宽控制，支持平滑削峰；
- 缓冲区水位监控：对每个 SocketChannel 的接收缓冲区（或自定义解码缓冲区）设置高低水位线。达到高水位时暂停读，低水位时恢复——这比固定开关更精细。
内存与资源池化：切断 GC 过载源头
高频新建 Buffer 或 Channel 是隐性过载诱因，尤其易触发 Direct Memory OOM：
立即学习“Java免费学习笔记（深入）”；
- 强制启用池化 ByteBuf：使用 PooledByteBufAllocator.DEFAULT，并按真实请求尺寸分布调参（如主流包体 ≤256 字节，则 pageSize 设为 1024，tinyCacheSize 提至 100+）；
- 严格引用计数管理：每个 PooledByteBuf 必须显式 release()，漏调即内存泄漏；建议在 ChannelInboundHandler#channelReadComplete 或异常分支中统一兜底释放；
- 限制最大并发连接数：在 Selector 循环中维护活跃连接计数，超过阈值（如 5 万）后直接拒绝新 accept，返回 RST 或静默丢弃，避免资源耗尽。
业务层熔断与降级：最后一道闸门
当 IO 层压力传导至业务逻辑时，需有快速止损能力：
- 基于响应时间或失败率熔断：例如用 Sentinel 或 Resilience4j 监控单连接平均处理耗时，超 500ms 且错误率 >30% 时，对该类请求快速失败，返回降级响应；
- 动态调整工作线程负载：IO 线程将任务提交给业务线程池前，先检查队列深度。若满载，可拒绝、降级或延后投递，避免线程池打满导致整个 Reactor 卡死；
- 协议层轻量握手校验：在 decode 阶段前置简单校验（如 magic number、版本、长度字段合法性），非法包立即丢弃，不进入后续解析和业务流程。
不复杂但容易忽略：过载保护不是堆功能，而是分层设计的结果。从 TCP 参数、Selector 调度节奏、Buffer 生命周期，到业务线程池水位，每一环松动都可能让整套机制失效。
