水位感知必须依赖独立采集线程+MXBean指标，分支结构仅消费预置状态并联动异常趋势决定降级；需融合内存水位、异常频次、GC间隔等多维信号，分级响应且支持动态开关。
不能靠分支结构“感知”水位，它只是做判断的开关；真正感知必须靠独立采集线程+MXBean指标。分支结构的作用是：在业务方法入口处，轻量、快速地读取已准备好的水位状态，并联动异常统计结果，决定是否执行降级逻辑。
水位指标必须独立采集，不能塞进分支里
分支结构（if/else）本身不采集数据，它只消费数据。JVM内存水位（如老年代使用率、堆外内存占用、GC频次）需通过MemoryPoolMXBean、GarbageCollectorMXBean等主动轮询获取，建议：
- 启用单独监控线程，每3–5秒采样一次，计算滑动窗口平均值（避免毛刺误判）
- 将结果写入线程安全变量，例如：
AtomicInteger memoryLevel = new AtomicInteger(0)，0=正常，1=预警（≥75%），2=高压（≥90%且持续2个周期） - 禁止在if条件中实时调用
getUsage().getUsed()——这会引入同步开销，还可能因MXBean锁导致分支卡顿
分支结构要融合两类信号，而非只看内存
单靠内存水位容易误降级（比如缓存预热时短暂冲高）。真实可用的分支逻辑应同时参考运行时异常趋势：
- 封装一个轻量判断工具，例如
Decide.shouldFallback() - 内部组合条件：memoryLevel.get() ≥ 2 OR TimeoutException近60秒发生≥4次 OR Young GC间隔＜200ms且连续3次
- 再叠加业务路径白名单：支付、下单等核心链路直接跳过降级，非核心接口才允许返回兜底数据
循环不是用来“反复降级”，而是控制清理节奏
当分支判定需降级后，真正的资源释放动作由while循环驱动，但该循环必须与业务请求解耦：
- 触发条件不是“每次请求都跑一遍”，而是由水位跃升事件唤醒（如
memoryLevel.compareAndSet(1,2)成功时启动） - 循环体内只做三件事：淘汰LRU缓存尾部项 → 清空WeakReference缓存 → 调用
System.gc()提示（不强制）→ 重新采样 → 满足退出条件则break - 每次循环末尾加
Thread.yield()或LockSupport.parkNanos(10_000)，防止抢占CPU影响主业务线程
降级出口要分层，避免一刀切
分支结构最终落地的降级动作，应按水位等级和异常类型分级响应：
- Level 1（预警）：关闭非关键日志、降低采样率、返回本地缓存（非过期）
- Level 2（高压）：跳过二级缓存直查DB、禁用异步发消息、RPC调用超时缩至300ms
- Level 3（临界）：全部返回预置兜底JSON、拒绝新连接、仅保留心跳与健康检查端点
- 所有降级动作必须带可动态开关（如Apollo配置项），支持秒级回滚
