面向对象通过拆解职责为可组合对象实现纳秒级动态舱壁隔离：timewindow封装窗口计算，bulkheadunit绑定窗口并管理资源，adaptivepolicy基于实测数据动态调整，arbiter用nanotime驱动跨舱壁公平调度。
面向对象本身不直接构建动态舱壁隔离，它只是组织 nanoTime 驱动的舱壁逻辑的合理方式。关键不是“用类封装时间”，而是把时间窗、配额、熔断、仲裁这些职责拆解为可组合、可替换、有明确边界的对象，让纳秒级节拍控制真正落地。
时间窗对象：封装窗口对齐与生命周期
- 不用 static 工具类硬编码 windowSizeNs，而是定义
TimeWindow类，内部持有windowSizeNs和offsetNs（用于对齐起始点） - 提供
belongs(long nanoTime)判断某次请求归属哪个逻辑窗口 - 提供
nextResetAt(long nanoTime)返回该请求所属窗口的精确重置纳秒时间戳，避免轮询或 sleep - 窗口不保存状态，只做计算——状态由舱壁实例自己维护，符合单一职责
舱壁单元对象：绑定时间窗并管理本地资源
- 每个
BulkheadUnit对应一个业务维度（如租户ID、模型类型、优先级等级），内部持有一个TimeWindow实例和一组原子计数器（如LongAdder requestsInWindow,AtomicLong totalGpuMsUsed） - 入口方法
tryAcquire(Request req)中：先调用window.belongs(req.nanoTime())定位桶，再在对应桶内做无锁限流检查 - 拒绝策略、降级动作、指标上报等行为通过策略接口注入（如
RejectionHandler,FallbackExecutor），不写死在类里
动态策略对象：基于窗口实测数据演进规则
- 定义
AdaptivePolicy接口，实现类如P95LatencyBasedPolicy或QueueWaitRatioPolicy - 每个舱壁单元在窗口结束时调用
policy.onWindowEnd(metrics)，传入本窗 P95 延迟（用 nanoTime 计算）、排队占比、显存消耗等 - 策略对象返回
AdjustmentCommand（如DecreaseLimitBy(30%)、EnableFallbackFor(2 windows)），由舱壁单元异步应用到下一窗口 - 策略变更不影响当前窗口执行，实现平滑升降级
跨舱壁仲裁器：用时间戳驱动公平调度
- 当多个
BulkheadUnit的请求竞争同一 GPU 或线程池时，不靠锁排队，而是由NanoTimestampedRequest包装原始请求，自带arrivalNanoTime -
Arbiter类接收所有待调度请求，按arrivalNanoTime升序排序（纳秒级精度），早到 100ns 就优先获得资源 - 排序不依赖系统时钟，全程使用 nanoTime；也不依赖全局队列，可做成每个资源池独立的轻量仲裁器
对象之间只通过窄接口协作，比如舱壁单元不关心策略怎么算，只管执行命令；策略不关心舱壁怎么存储计数，只管输出调整指令。这样，当需要支持新指标（如显存抖动率）或新熔断条件（如连续窗口内 GC 时间超阈值），只需新增策略实现类，无需改动舱壁核心逻辑。
