流程控制本质是基于system.nanotime()的节拍化调度逻辑，通过时间锚点实现窗口对齐、桶计数、状态流转与策略变更，所有操作无锁原子、纳秒级完成，不依赖阻塞或轮询。
流程控制本身不直接构建舱壁隔离，真正起作用的是以 System.nanoTime() 为时间锚点的节拍化调度逻辑。所谓“流程控制”，本质是把限流、熔断、分桶、重置等动作编排成可确定执行次序的时间驱动流程，而非依赖线程阻塞或外部轮询。
用 nanoTime 定义窗口生命周期流程
每个时间窗不是靠定时器“唤醒”，而是由请求进入时实时计算归属并触发状态流转：
- 窗口起始时间由
System.nanoTime()对齐计算：windowStart = nanoTime - (nanoTime % windowSizeNs) - 请求到达时，立即算出所属窗口编号：
bucketId = (nanoTime / windowSizeNs) % bucketCount - 检查该桶当前计数是否超限；未超则原子递增并放行，超限则拒绝，不排队、不等待
- 窗口结束不靠“等待”，而靠下一次请求到来时发现
nanoTime >= nextResetTimeNs，即刻重置该桶计数器
舱壁策略变更必须走闭环流程
动态收紧或恢复不是即时生效，而是绑定到窗口边界，通过“统计→决策→生效”三步流程确保平滑：
- 每个窗口结束时，基于本窗内所有请求的
nanoTime耗时数据，计算 P95 延迟、排队占比、显存峰值等指标 - 若连续两个窗口 P95 > 80ms，标记该桶“需降阈值”，但不立刻改；只在下一个窗口开始前，将限流值下调 30%
- 若后续三个窗口 P95 回落达标，则每次窗口切换时恢复 10%，共三次完成回升
- 所有策略变更仅影响新窗口，当前窗口继续按旧规则执行，避免中途切流引发抖动
跨通道资源仲裁需纳秒级流程排序
当多个舱壁共享 GPU、线程池等稀缺资源时，“谁先获得调度权”必须由不可篡改的时间顺序决定：
- 每个请求入队时，用
System.nanoTime()打唯一时间戳，不经过任何中间层加工 - 调度器不按接收顺序或线程ID排序，而是严格按该纳秒戳升序仲裁
- 早到 200ns 的请求，在资源争抢中获得更高权重，哪怕 JVM 调度导致它“逻辑上晚处理”
- 这种流程消除了因 GC 暂停、线程抢占造成的“物理早到、逻辑晚判”不公平现象
避免把流程控制误解为串行阻塞
高并发场景下，流程控制 ≠ 串行化执行。关键在于：
- 所有判断（归属窗口、查桶计数、比对阈值）都是无锁原子操作，耗时在纳秒级
- 重置、降级、熔断等动作不阻塞当前请求，而是标记状态，由下一个窗口自然承接
- 没有 sleep、wait、ScheduledExecutorService 等易漂移组件参与主路径
- 整个流程像节拍器一样自主运行，不依赖外部时钟同步或协调服务
