4. 容量阈值设定与动态调整策略
LRU 缓存的容量控制是防止内存泄漏与性能退化的第一道防线。本章将对比 固定容量 与 自适应容量 两种策略，详细说明如何选择最大条目数或内存字节数作为边界条件，并给出触发调整的典型时机与核心算法。
4.1 固定容量 vs 自适应容量
| 对比维度 | 固定容量 | 自适应容量 |
|---|---|---|
| 容量边界 | 静态配置，运行期间不变 | 根据运行指标动态调节上下限 |
| 内存占用 | 可预测，不易超限 | 可能瞬时超出，但会回缩 |
| 实现复杂度 | 低，仅需 LRU + 淘汰 | 高，需要监控、计算与调整逻辑 |
| 适用场景 | 内存预算严格、负载均匀 | 流量波动大、数据热点变化快 |
| 防泄漏能力 | 强（上限硬性切断） | 中（需配合水位预警） |
推荐生产环境使用 固定容量为主 + 自适应策略作为安全阀 的组合模式，避免纯自适应设计导致的震荡。
4.2 最大条目数 vs 内存字节数
容量阈值可基于条目数量或实际内存用量设定，各有优劣：
- 最大条目数：控制简单，淘汰代价固定；但条目大小不均时内存占用不可控。
- 内存字节数：直接限定内存消耗，适合大对象缓存；但需要计算每个条目占用，增加开销。
// 配置示例（Java / Caffeine 风格）
Cache<Key, Value> cache = Caffeine.newBuilder()
.maximumSize(10_000) // 最大条目数
.maximumWeight(256_000_000) // 最大内存字节数（256 MB）
.weigher((key, value) -> computeSize(value))
.build();
当使用内存字节数时，务必在淘汰策略中重新计算单个条目的实际占用（包括 key、value 及其内部结构），避免低估导致 OOM。
4.3 触发调整的时机与算法
自适应容量调整通常在以下时机触发：
- 缓存命中率持续低于阈值（例如 <5% 连续 30 秒）→ 缩小容量以淘汰冷数据。
- 内存压力上升（系统可用内存低于 10%）→ 主动缩减缓存，释放资源。
- 淘汰率异常升高（单位时间内淘汰次数增长 5 倍）→ 可能容量不足，需适当扩大。
- 数据分布漂移（新条目访问频次远高于旧条目）→ 调整容量重心。
常用调整算法：
# 伪代码：基于命中率的自适应算法
def adjust_capacity(metrics):
hit_rate = metrics.hit_count / metrics.total_requests
if hit_rate < HIT_RATE_LOW:
# 命中率过低，缩小容量 10%
new_cap = current_cap * 0.9
elif hit_rate > HIT_RATE_HIGH:
# 命中率理想，尝试扩大容量 5%（但不超过最大上限）
new_cap = min(current_cap * 1.05, MAX_CAP)
else:
# 命中率在正常范围，保持
new_cap = current_cap
# 同时检查内存水位
if system_memory_percent > MEM_HIGH_WATERMARK:
# 内存紧张，立即强制缩减至水位以下
new_cap = int(current_cap * (MEM_HIGH_WATERMARK / system_memory_percent))
return int(new_cap)
自适应调整必须引入 冷却期（例如两次调整间隔不小于 5 秒）和 变化幅度上限（单次调整不超过 20%），防止因指标噪声导致容量震荡。
4.4 容量阈值设定流程
4.5 最佳实践清单
- 固定容量优先：90% 的场景使用固定容量即可满足防泄漏需求。
- 设置安全上限：即使采用自适应策略，也必须定义最大值（例如总内存的 40%）。
- 指标采样粒度：监控周期不宜过短（推荐 1-3 秒），避免高频调整。
- 溢出处理：当内存字节数超过阈值时，应立即触发同步淘汰，而非等待下一次调整。
- 日志记录：每次容量变化、淘汰率、命中率均应输出结构化日志，方便事后分析。