核心是减少socket系统调用与上下文切换，通过合理配置4KB～16KB缓冲区、避免双重缓冲、使用批量读写、确保单连接单实例及及时flush/close来优化吞吐量。
用缓冲流优化网络传输的字节数据吞吐量，核心是减少 socket 层的系统调用次数、降低上下文切换开销，并让 JVM 更高效地处理小包数据。Java 中主要靠 BufferedInputStream 和 BufferedOutputStream 包装网络流（如 Socket.getInputStream() 和 Socket.getOutputStream()），但关键不在“用不用”，而在于“怎么配”和“怎么用”。
选对缓冲区大小：网络场景推荐 4KB～16KB
网络传输受带宽、延迟、MTU、TCP窗口大小等影响，不像本地文件那样稳定。默认 8KB 缓冲区（8192 字节）在多数 HTTP 或自定义协议场景下表现均衡，但可按需微调：
- 高延迟、低带宽链路（如移动网络）：用 4KB，避免单次填充等待过久，提升响应灵敏度
- 局域网内大流量通道（如微服务间 gRPC 数据流）：可设为 16KB，更充分摊薄 write() 调用频次
- 不建议超过 64KB——TCP 协议栈本身有分段机制，过大的缓冲区不会提升单次发送效率，反而增加内存占用和 GC 压力
避免双重缓冲和隐式 flush
网络流本身（如 SocketOutputStream）底层已由 TCP 栈做了一定缓冲；再套一层过大的 BufferedOutputStream 可能造成冗余，甚至因未及时 flush 导致数据滞留：
- 不要对已缓冲的流重复包装（例如：把
BufferedOutputStream再套一次BufferedOutputStream） - 写完关键数据后主动调用
flush()，尤其在非阻塞或半双工通信中；close()会自动 flush，但不能依赖它来保证实时性 - 若使用
PrintWriter或ObjectOutputStream等高级流，注意它们内部是否已含缓冲，避免叠加
配合批量读写模式，少用单字节操作
read() 和 write(int) 这类单字节方法会严重削弱缓冲效果——每次调用都可能触发缓冲区检查与重填逻辑，实际性能接近无缓冲流：
- 改用
read(byte[] b)或read(byte[] b, int off, int len)批量读取，让缓冲区真正发挥作用 - 写入时优先用
write(byte[] b)，而非循环调用write(int) - 示例：接收一个完整消息体时，先预估长度（如通过 header 解析），再分配对应大小的 byte[] 一次性读满
注意线程安全与资源生命周期
BufferedInputStream 和 BufferedOutputStream 的所有 public 方法都是 synchronized 的，共享实例在高并发网络连接中易成锁瓶颈：
- 每个 socket 连接应持有独立的缓冲流实例，不要跨线程复用
- 确保在连接关闭时正确调用
close()（建议用 try-with-resources），否则缓冲区残留数据可能丢失，且底层 socket 不释放 - 对于长连接高频通信场景，可考虑 NIO 的
SocketChannel+ByteBuffer替代传统流，获得更细粒度控制和零拷贝潜力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
