java nio可通过字节计数+时间窗口或令牌桶算法在应用层实现带宽限流：前者基于滑动窗口统计单位时间字节数并超限暂停读写，后者通过线程安全令牌桶平滑控制速率，结合selectionkey动态调节op_write注册实现反压。
Java NIO 本身不直接提供带宽限流与流量控制功能，但可以通过组合 Selector、Channel 的读写状态控制、配合令牌桶或漏桶算法，再结合时间窗口与字节计数，在应用层实现精准的流量塑形（Traffic Shaping）和速率限制（Rate Limiting）。
基于字节计数 + 时间窗口的简单限流
适用于对单连接或全局吞吐量做粗粒度控制。核心思路是：记录单位时间内已发送/接收的字节数，超出阈值则暂停读写，等待下一窗口重置。
- 维护一个滑动时间窗口（如 1 秒），使用
System.nanoTime()记录起始时间与当前字节数 - 每次准备 write() 前，检查「当前窗口内已写入字节数 + 本次待写字节数」是否超限；若超限，跳过本次写入，注册
OP_WRITE并延后处理 - 在
select()循环中定期检查窗口是否过期，重置计数器 - 注意：需避免因反复注册
OP_WRITE导致 busy-loop，建议配合小延迟（如selector.wakeup()后休眠几毫秒）或使用SelectionKey.interestOps(0)暂时取消关注
结合令牌桶实现平滑带宽控制
比固定窗口更平滑，支持突发流量。每个连接或全局共享一个令牌桶，每次读/写前尝试获取对应字节数的令牌。
- 定义桶容量（如 1MB/s → 每毫秒约 125 字节）和填充速率（
tokens += rate * (now - lastRefill) / 1_000_000） - 封装一个线程安全的
TokenBucket类，暴露tryAcquire(long bytes)方法（返回是否成功） - 在
handleWrite()中：调用bucket.tryAcquire(buffer.remaining())，成功则执行channel.write(buffer)，失败则取消OP_WRITE关注，稍后重试 - 可为每个
SocketChannel绑定独立桶（连接级限流），或共用一个桶（全局带宽控制）
利用 SelectionKey 控制读写节奏
NIO 的事件驱动特性天然适合做反压（backpressure）。关键不是“不让写”，而是“不通知你写”。
- 默认不注册
OP_WRITE，只在连接就绪或有数据待发时才注册 - 当缓冲区写满（
channel.write(buf)返回值 buf.remaining()），说明 TCP 窗口不足，立即取消OP_WRITE，等下一次OP_WRITE就绪再继续 - 读操作同理：如果应用层处理慢（如业务逻辑阻塞），可主动调用
key.interestOps(key.interestOps() & ~SelectionKey.OP_READ)暂停接收，防止内核缓冲区堆积 - 配合
SO_RCVBUF/SO_SNDBUF调优，避免 OS 层缓冲干扰应用层流控精度
进阶：集成 Netty 实现开箱即用的流量整形
若项目允许引入框架，Netty 的 ChannelTrafficShapingHandler 提供了生产级的解决方案：
-
GlobalChannelTrafficShapingHandler：全局总带宽控制（如服务器出口限 100MB/s） -
ChannelTrafficShapingHandler：单连接限流（如每个客户端限 1MB/s） - 支持读/写分别限速、自动计算写空闲时间、支持平滑突发（maxWriteSize）、可动态调整速率
- 底层仍是基于定时任务 + 字节统计 +
channel.config().setAutoRead(false)等机制，但封装完善、线程安全、经大量验证
不复杂但容易忽略的是：限流必须与连接生命周期绑定，避免内存泄漏；同时要区分“网络层拥塞”和“应用层处理瓶颈”，前者靠 TCP 自身机制+合理缓冲区设置，后者才需主动流控。真正落地时，建议先用 Netty 的实现验证策略，再按需定制 NIO 原生方案。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
