BufferedOutputStream 本身不能直接减少 TCP 包碎片，关键在于批量写入、合理设置缓冲区大小（如 4096 或 8192）、避免频繁 flush，并在确保应用层攒包前提下协同禁用 Nagle 算法。
使用 BufferedOutputStream 本身并不能直接减少 TCP 包碎片，关键在于控制写入节奏和缓冲区行为，避免小包频繁 flush。
理解 TCP 包碎片的根源
TCP 包碎片（如 Nagle 算法触发的小包、PUSH 标志频繁置位）主要源于：应用层频繁调用 write() + flush()、未填满 MSS、或底层 Socket 启用了 Nagle 但上层未配合。BufferedOutputStream 的缓冲只是第一道防线，若每次只写几个字节又立刻 flush，缓冲形同虚设。
合理配置 BufferedOutputStream 缓冲区大小
默认 8192 字节通常够用，但若业务中常见中等长度消息（如 1–4KB 的协议帧），可显式指定更匹配的缓冲容量，减少因缓冲区过早满而触发的非预期 flush：
- 避免过小（如 256 字节）——容易频繁溢出
- 避免过大（如 64KB）——增加内存占用和延迟，且超出 TCP MSS 无意义
- 建议值：4096 或 8192，与典型单次逻辑消息大小对齐
批量写入 + 显式控制 flush 时机
不要每写一个字段就 write() 一次，更不要每次后跟 flush()。应将完整业务单元（如一条协议消息）序列化到字节数组或 ByteArrayOutputStream，再一次性写入 BufferedOutputStream：
立即学习“Java免费学习笔记（深入）”；
- 构造完整消息体后再调用
bufferedOut.write(byteArray) - 仅在逻辑消息发送完毕、需确保对方立即收到时才
flush() - 避免在循环内反复
write(byte)—— 这会绕过缓冲，直通底层 socket
协同禁用 Nagle 算法（谨慎使用）
若业务对延迟极度敏感（如实时游戏、高频指令），且能保证批量写入，可关闭 Nagle：
socket.setTcpNoDelay(true);- 注意：这不等于“减少碎片”，而是放弃小包合并，转而依赖应用层自己攒包；若应用层仍零散写入，反而产生更多微包
- 仅在确认上层已做好批量写入的前提下启用
本质是让 BufferedOutputStream 发挥真正缓冲作用，而非仅仅掩盖写法缺陷。不复杂但容易忽略。
