Java NIO高效序列化关键在于与非阻塞、零拷贝、缓冲区生命周期对齐：弃用ObjectOutputStream，统一使用DirectByteBuffer+自定义序列化器；帧头分离、预分配buffer、lazy解析与对象池化。
Java 在 NIO 网络通信中实现高效序列化协议，关键不是选一个“快”的序列化库，而是让序列化与 NIO 的非阻塞、零拷贝、缓冲区生命周期等机制对齐。否则再快的序列化器（如 Kryo、Protobuf）也会因 ByteBuffer 拷贝、堆内存分配或同步写入而拖垮整体吞吐。
用 DirectByteBuffer + 自定义序列化器替代 ObjectOutputStream
ObjectOutputStream 是 BIO 时代的产物，它强依赖 OutputStream，会强制将数据刷入堆内存再 write()，无法复用 NIO 的 DirectBuffer 和 transferTo。应彻底弃用：
- 序列化入口统一收口到 ByteBuf 或 DirectByteBuffer：例如 Protobuf 的
message.writeTo(OutputStream)改为message.toByteArray()后拷入 DirectBuffer —— 但更优解是用UnsafeByteOperations或CodedOutputStream直接写入堆外 buffer - 避免
toByteArray()：它生成新 byte[]，触发 GC；改用writeTo(CodedOutputStream)，配合预分配的DirectByteBuffer和Unsafe写入 - 对齐 buffer 容量：序列化前估算最大长度（如 Protobuf 的
getSerializedSize()），提前 allocate 合适大小的 DirectByteBuffer，避免扩容和复制
帧头分离 + 元数据零拷贝透传
序列化数据本身不包含路由、校验、偏移等语义，这些必须作为独立控制信息处理，否则每次反序列化都要解析完整对象才能取元信息：
- 设计二进制帧结构：4 字节魔数 + 4 字节 payload length + 1 字节 codec id + 1 字节 compress flag + payload（即序列化后原始字节）
- Header 与 Payload 分开写：Header 固定 10 字节，用小 DirectBuffer 预分配；Payload 直接从序列化器写入大 buffer，两者通过
CompositeByteBuf（Netty）或ScatteringByteChannel（原生 NIO）合并发送，不发生内存拷贝 - 接收端先 read header（固定长度），解析出 payload length 后，再分配/复用对应大小的 buffer 接收 payload，跳过无效解析
结合 NIO 零拷贝能力绕过 JVM 堆
当源数据已是文件（如日志切片、备份镜像），且协议允许纯透传时，序列化可降级为“逻辑封装”，物理传输走零拷贝：
立即学习“Java免费学习笔记（深入）”；
- 若 payload 是本地文件某一段，不用读入内存序列化：用
FileChannel.transferTo(offset, count, socketChannel)直送网卡，仅在 header 中标注该段的全局 offset 和 checksum - 若需加密/压缩，则无法用 transferTo：改用
MappedByteBuffer映射文件只读段 → 按 chunk 切片 → 加密写入 DirectBuffer → write() 发送；注意 map 大小不超过 2GB，超长文件分段 map 并显式 cleanup - 服务端接收后，若目标是落盘，同样用
FileChannel.write(buffer, fileOffset)直接落盘，避免 heap 中转
反序列化阶段做 lazy 解析与引用计数回收
高并发下频繁 new 对象 + GC 是性能杀手。反序列化要延迟、复用、可控：
- 不立即反序列化完整对象：收到 buffer 后，先提取 header 信息并校验 checksum，业务线程按需调用
parseFrom(buffer)，而非 IO 线程强绑定 - 使用池化对象：Protobuf 支持
Parser+Recycler，Kryo 可配Pool；Netty 场景推荐ByteBufHolder封装，配合ReferenceCountUtil.release()显式回收 - 禁止在 ChannelHandler 中做耗时反序列化：拆成两个 handler——DecodeHandler（仅拆帧+校验+封装 ByteBufHolder）→ BusinessHandler（异步提交至业务线程池解析）
