真正的无感带宽限流是“随流调阀”，即用动态 permits 机制使信号量实时贴合可用带宽水位；通过采集 tx_bytes/sec 映射许可数、滑动窗口平滑突刺、AtomicReference 原子替换 Semaphore 实例、按 dashboardId 分桶+权重透传、超时熔断双兜底实现。
在拖拽大屏这类实时性高、数据吞吐波动剧烈的场景中，后端计算引擎常面临瞬时带宽打满、下游服务雪崩、WebSocket 连接抖动等问题。单纯靠静态信号量（如 Semaphore(10)）做限流，既无法响应网络带宽变化，也无法适配不同仪表盘的并发查询强度，容易造成“该放行时卡死、该压降时爆满”。真正的无感带宽限流，核心不是“堵”，而是“随流调阀”——用动态 permits 机制让信号量始终贴合当前可用带宽水位。
带宽感知：把网络指标映射为许可数
不能凭经验设固定 permits，而要将实时带宽指标转化为许可上限。关键路径是：
- 采集出口网卡每秒发送字节数（
tx_bytes/sec），推荐用/proc/net/dev或 eBPF 工具持续采样 - 设定基准带宽阈值（如 80 Mbps），对应基础 permits（如 20）；超出阈值即按比例缩容：
currentPermits = max(2, (int) Math.round(20.0 * baseBw / currentBw)) - 对突发流量加缓冲：引入滑动窗口均值（如最近 5 秒 avg tx_bytes），避免单点毛刺误触发抖动
无感切换：原子替换 + 零停顿接管
Java 中 Semaphore 不支持运行时改 permits，硬改会导致计数错乱。必须用引用替换实现热更新：
- 用
AtomicReference<semaphore></semaphore>持有当前生效实例 - 每次 acquire 前先检查：
if (semRef.get().availablePermits() == 0 && !isCurrentLimitMatch())，触发重建 - 新建
Semaphore(newPermits, false)（非公平模式，保障吞吐），再用semRef.compareAndSet(old, new)原子替换 - 旧实例不再有新 acquire，已有线程正常执行完并 release，自然退役
拖拽场景专属适配：按仪表盘粒度隔离+权重透传
大屏拖拽不是全局统一限流，而是每个看板（dashboardId）独立水位。否则一个复杂看板拖垮整集群：
- 用
ConcurrentHashMap<String, AtomicReference<Semaphore>>按 dashboardId 分桶管理 - 前端拖拽请求携带
x-dashboard-weight: 3（表示该看板含 3 个高耗能图表），后端acquire(weight)占用多份许可，释放时也release(weight) - 权重归一化：基础许可按带宽算，权重仅影响单次占用量，不改变总池大小
防雪崩兜底：超时+熔断双保险
即使动态调整及时，下游带宽骤降或丢包率飙升时，仍需快速止损：
- 所有 acquire 必须走
tryAcquire(800, MILLISECONDS)，超时值设为当前带宽下 P95 查询耗时的 1.3 倍（如 650ms → 800ms） - 连续 3 次超时，对该 dashboardId 触发短时熔断（如 30 秒内拒绝新请求，返回
503 Service Unavailable+Retry-After: 30） - 熔断期间仍允许
availablePermits()继续上报，确保带宽恢复后自动解熔
