应结合系统内存压力动态调整缓存淘汰阈值，因runtime.ReadMemStats仅反映Go堆内存，不包含OS进程、栈、mmap、CGO及内核缓冲区等关键内存占用，易致OOM；需通过/proc/meminfo或host_statistics获取MemAvailable，并在LRU的Put和后台goroutine中注入内存判断逻辑。
直接结论：不要只用固定容量的 LRU/LFU，而要结合系统内存压力动态调整淘汰阈值——否则在高负载机器上缓存可能成为 OOM 的导火索。
为什么 runtime.ReadMemStats 不足以支撑内存感知淘汰
它只返回 Go 运行时堆内存（Alloc、HeapInuse 等），不包含：
• 操作系统其他进程占用的内存
• Go 程序的栈、mmap 内存、CGO 分配的内存
• page cache、buffers 等内核缓冲区
这意味着即使 ReadMemStats 显示堆只用了 200MB，系统整体可用内存可能已跌破 5%，触发 OOM killer。
实际线上踩坑案例：某服务在压测中频繁被 kill，日志显示 ReadMemStats.HeapInuse 始终低于 1GB，但 /proc/meminfo 中 MemAvailable 长期低于 200MB。
- 正确做法是优先读取
/proc/meminfo（Linux）或host_statistics（macOS） - 用
syscall.Syscall或unix.Syscall直接调用，避免第三方库依赖 - 采样周期建议设为 1–3 秒；太短加重系统负担，太长响应滞后
如何把内存压力信号注入 LRU 缓存结构体
关键不是重写整个 LRU，而是复用已有结构，在 Put 和后台 goroutine 中插入内存判断逻辑。
示例改造点：
- 在
LRU结构体中增加字段：memThreshold uint64 // 单位：字节，如 512 * 1024 * 1024和memCheckFn func() uint64 // 返回当前 MemAvailable -
Put方法开头加检查：if c.memCheckFn() （强制淘汰 30% 最久未用项） - 启动独立 goroutine，每 2 秒调用
memCheckFn并更新memThreshold（例如根据负载动态缩放）
注意：evictByLRU 必须支持按比例淘汰（而非只淘汰 1 个），否则无法快速释放内存。别直接复用原 dl.Back() + Remove 循环——要批量操作并提前 break。
LFU 在内存敏感场景下为何更难用
LFU 要求每个 key 维护 freq 和 lastAccessTime，还要维护频率分组链表（freq → *list.List）。这带来两个硬伤：
- 内存开销翻倍：每个缓存项额外多存 16–24 字节（
int+ 时间戳 + 频率链表指针），对小 value 场景（如 token string）放大效应明显 - 淘汰决策延迟：O(1) 淘汰依赖“最小 freq 对应链表是否为空”，但该链表头节点未必是最久未用——需二次查 LRU 时间，实际变成 O(2)
真实业务反馈：某网关将 LRU 切换为 LFU 后，P99 内存分配延迟从 8μs 升至 42μs，且 GC pause 时间增加 37%。除非你明确需要区分「高频冷数据」和「低频热数据」，否则别在内存受限服务里用 LFU。
真正能落地的混合策略：LRU + 内存水位双触发
生产环境最稳的方案不是纯算法，而是两层触发：
- 第一层：常规 LRU 容量控制（如最多 10 万 key），保证基础性能边界
- 第二层：内存水位软触发（
MemAvailable ）→ 启动 aggressive 淘汰（清空所有 5 分钟未访问的项） - 第三层：内存水位硬触发（
MemAvailable ）→ 强制收缩到容量的 30%，丢弃全部非 sticky 项（可标记 <code>sticky: true的 key 不参与此轮淘汰）
这个设计的关键在于：所有淘汰动作都复用原有 *list.Element 链表遍历，不新建结构、不 rehash map、不阻塞主流程。实测在 50 万缓存项下，硬触发淘汰耗时稳定在 12ms 内。
最容易被忽略的一点：内存检查必须用原子变量缓存上次结果，否则高并发 Get 反复调用 memCheckFn 会把 /proc/meminfo 读成瓶颈——我们见过一个服务因此每秒多出 2000+ syscalls。
