so_rcvbuf和so_sndbuf直接决定tcp内核缓冲区大小，是java nio吞吐量的“卡脖子”参数：缓冲区过小会触发tcp窗口收缩或write阻塞，导致吞吐骤降；合理值应≥带宽×延迟（bdp），如千兆局域网需约64kb，常设128kb（131072字节）并须在bind前配置。
SO_RCVBUF 和 SO_SNDBUF 直接决定每个 TCP 连接在内核中收发数据的缓冲能力，对 Java NIO 的吞吐量影响非常显著——不是“有影响”，而是“卡脖子”级的关键参数。
为什么这两个参数会限制 NIO 吞吐量
Java NIO 本身不处理底层数据搬运，它依赖操作系统内核的 socket 缓冲区完成实际 I/O。一旦缓冲区太小：
- 接收缓冲区（SO_RCVBUF）填满后，TCP 会通过窗口通告机制通知对端“别再发了”，导致发送方停等，吞吐骤降
- 发送缓冲区（SO_SNDBUF）过小，应用层 write() 或 channel.write() 调用容易阻塞（即使非阻塞模式下也会频繁返回 0），ChannelOutboundBuffer 积压加剧，触发 Netty 的水位告警甚至 OOM
- NIO 的 Selector 轮询效率再高，也救不了被内核“掐住喉咙”的连接
合理设置值的依据：带宽 × 延迟（BDP）
理论最小值 ≈ 网络带宽（字节/秒）× 往返时延（秒）。例如：
- 千兆局域网（125 MB/s），RTT=0.5ms → BDP ≈ 64 KB
- 公网服务（10 MB/s），RTT=50ms → BDP ≈ 500 KB
实践中建议从 128 KB 起步（注意：这是字节数，不是 KB 数值直接写 128），再根据压测调整。Netty 中常用写法：
.option(ChannelOption.SO_RCVBUF, 131072) // 128 * 1024 .option(ChannelOption.SO_SNDBUF, 131072)
设置时必须注意的细节
Linux 内核会对应用设置的值自动翻倍（并取上下限），所以设 128 KB 实际可能变成 ~256 KB；但更重要的是：
- 必须在 channel 创建后、绑定前 设置，否则无效（如 ServerSocketChannel.open() 之后，bind() 之前）
- UDP 的 DatagramChannel 只有 SO_RCVBUF 生效，SO_SNDBUF 无意义（UDP 不缓存发送数据）
- 配合 TCP_NODELAY = true 使用，否则小包攒批+缓冲区小=双重延迟恶化
- 高并发场景下，总内存占用 = 连接数 × (SO_RCVBUF + SO_SNDBUF)，需防止内存溢出
如何验证是否调优到位
不能只看代码写了没，要观察运行态指标：
- 用
ss -i查看单连接实际生效的 rcv_ssthresh / snd_cwnd，确认窗口未长期处于极小值 - 监控 netstat -s 中 “segments retransmited” 是否异常升高（缓冲区小易丢 ACK 导致重传）
- 应用层统计 channel.isWritable() 为 false 的频率，持续高于 5% 就说明 SO_SNDBUF 或业务写法有问题
- 对比压测 QPS 和平均延迟，缓冲区从 64K→256K 若无提升，说明瓶颈已转移（如 GC、序列化、线程争用）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
