当堆内存使用率连续3次≥92%且老年代占比上升>3%/分钟时触发限流，分层降级非核心接口、限制批量并发、关闭预热任务，并自动执行jmap诊断与分级恢复。
当堆内存使用率逼近 92%（低于紧急阈值 95%，但已触发重要告警 ALM-23004），系统不应被动等待 OOM 或 Full GC，而应主动限流保命。核心逻辑是：把内存水位当作实时业务压力信号，而非仅运维指标。
内存水位作为流量开关的判定依据
单纯看“当前占用率=92%”不可靠，需结合趋势与上下文确认是否真实承压：
- 连续 3 次采样（间隔 10 秒）均 ≥92%，且老年代占比同步上升 >3%/分钟 → 视为有效临界信号
- 若同时伴随 Young GC 频次突增（如每分钟 >15 次）或平均停顿 >100ms → 加速触发限流
- 排除瞬时毛刺：单次飙升后 5 秒内回落至 85% 以下，不触发动作
分级切断大流量的具体执行方式
不是一刀切拒绝所有请求，而是分层干预，优先保护核心链路：
- 降级非核心接口：自动将 /report、/export、/search-suggest 等高内存消耗路径返回 429 或兜底静态响应
- 限制批量操作并发数：通过内部令牌桶动态将 batch-size 从 100 压至 20，防止一次请求加载千级对象
- 关闭预热与缓存穿透防护：临时禁用热点 key 自动预热、布隆过滤器后台刷新等后台任务
触发后必须配套的自检与恢复机制
限流只是手段，目标是争取时间定位根因并释放内存：
- 立即触发一次 jmap -histo:live PID，提取 Top 10 对象类及实例数，写入诊断日志
- 若 2 分钟内内存使用率回落至 80% 以下，自动恢复被限接口；否则每 3 分钟再采样，持续限流
- 若连续 3 次限流后仍无法缓解，升级为触发 JVM dump 并通知值班人，避免静默恶化
这套机制不依赖外部调度，全部在 JVM 进程内闭环完成，响应延迟控制在秒级。关键在于把内存指标真正变成业务策略的输入源，而不是监控看板上的一个数字。
