Java NIO防御超大报文需四层设限：连接层限并发、帧解析层用MaxFrameLength或LengthFieldBasedFrameDecoder、缓冲区手动校验remaining、协议层前置校验长度字段；HTTP须用HttpObjectAggregator控制体长，多层流控与监控协同实现纵深防御。
Java NIO 本身不自动拦截超大报文，防御必须靠主动设计：在数据进入业务逻辑前，就从连接层、帧解析层、缓冲区使用和协议语义四个层面设限，否则攻击者可轻易用单个巨型帧打爆堆外内存或触发频繁 GC。
用 MaxFrameLength 拦截超长帧（Netty 场景）
这是最直接有效的第一道防线，但仅适用于有“帧”概念的协议（如 WebSocket、自定义二进制协议），对 HTTP 无效：
- 必须配合
LengthFieldBasedFrameDecoder或WebSocketFrameDecoder使用，单独设置无意义 - 值需按业务定，常见起点是
1024 * 1024（1MB），太大失去防护作用，太小误杀合法大文件 - 捕获
TooLongFrameException后必须立即调用ctx.close()，不响应、不写日志、不重试 - 注意：HTTP 协议没有帧，此处限制不生效；HTTP 请求体大小要用
HttpObjectAggregator.maxContentLength控制
手动校验 ByteBuffer 剩余空间（原生 NIO 场景）
别依赖 BufferOverflowException 做控制逻辑——它是保护反馈，不是防御开关：
- 每次写入前调用
buffer.remaining()，与待写数据长度比对，不足则拒绝或拆分 - 网络读取后，先检查
read()返回值是否为 -1（连接关闭）或 0（无数据），再判断是否填满 buffer - 对不可信来源，可用
buffer.asReadOnlyBuffer()创建只读视图，提前拦截非法修改 - 避免在
position == limit后继续put()，这必然抛异常且已属设计失误
在协议层前置校验报文头与长度字段
真正安全的解析，永远发生在反序列化或业务处理之前：
立即学习“Java免费学习笔记（深入）”；
- 若协议含长度前缀（如前 4 字节表示 body 长度），先读出该字段，校验是否 ≤ 预设上限（如 5MB）且 ≥ 0
- 校验通过后再分配或复用
DirectByteBuffer，不直接用固定大 buffer 接收所有数据 - 对 JSON/XML 等文本协议，在解码前先统计原始字节数：
if (bytes.length > 5 * 1024 * 1024) throw new IllegalArgumentException("Payload too large") - 避免使用
ObjectMapper.readTree()直接加载整个报文树，改用流式 API（JsonParser）边读边校验节点深度与数量
结合连接与请求级流控形成纵深防御
单点防护容易被绕过，需多层协同：
- 连接层：用
AsynchronousServerSocketChannel+AtomicInteger限制并发连接数，超阈值直接close() - 单连接内：用
Semaphore控制未确认数据块数量（如最多 3 块在途），防内存堆积 - 后端写入：异步落盘时维护全局写队列，超长则返回
503 Service Unavailable并带Retry-After头，把压力反馈给客户端 - 全链路监控：记录每条连接的平均帧大小、最大深度、解析耗时，突增即告警并熔断
