Ru果把内存比作桌面你的笔记本电脑只Neng放下几本书，却又要随时翻阅整个书柜。怎么把Zui常用的那几本留在手边，而把不常kan的扔到仓库？这正是缓存淘汰策略要解决的问题。

现代服务往往在几百兆甚至上 GB 的内存里跑高速缓存。可是硬件不是无限的，一旦满了就会出现两种尴尬：

写入被拒绝——业务瞬间卡住。

旧数据被随意覆盖——命中率骤降，查询成本飙升。

所以在容量受限的前提下以某种规则主动清理空间成了必不可少的环节。

Zui直观的Zuo法：谁先进入，就谁先走。实现时只需要一个队列。

优点：代码极简，几乎没有额外开销。

缺点：完全不考虑访问频次一次性扫描就Neng把热点全部踢出去——这就是所谓的“FIFO 异常”。

假设“刚被访问的东西hen快还会再用”，于是每次访问后把对应条目搬到链表尾部；链表头部就是Zui久未触碰的候选。

实现技巧：

HashMap + 双向链表: O 定位 + O 移动。

哨兵节点Ke以免除空指针检查，让代码geng干净。

统计每个键过去被访问了多少次频率Zui低者先走。对热点分层明显的业务尤为友好。

坑点：

新加入的数据频次为 1，容易被误杀。

历史热点即使不再热，也会因为累计次数高而久留，需要衰减机制来“老化”。

2Q 把入口分成冷区+ 热区. 第一次出现只进冷区，第二次才晋升热区；这样一次性扫描的大批无价值请求会被锁在冷区，不会污染热区。

ZFS 与 Oracle dou在用，它同时维护四个列表：T1/T2+ B1/B2. 当系统检测到访问模式偏向频率还是时间局部性时会自动调节 T1 与 T2 的比例，无需手工调参。

数据是否有 TTL？
├─是 → 选择 volatile‑* 系列
│   ├─需要精细控制 → volatile‑lfu
│   └─gengkan实时性 → volatile‑lru 或 volatile‑ttl
└─否 → allkeys‑* 系列
    ├─热点明显 → allkeys‑lfu ★
    └─一般场景 → allkeys‑lru ★默认
Ru果业务绝对不Neng丢失关键键 → noeviction 

温馨提醒：AWS ElastiCache 与 Redis 的默认dou是 allkeys-lru, 大多数项目直接沿用即可。Ru果发现热点占比超过 70% 再考虑切到 LFU，会kan到命中率飙升 10%~20%。

public class LRUCache {
    private static class Node {
        K key; V val;
        Node prev, next;
        Node{key=k;val=v;}
    }
    private final int cap;
    private final Map map = new HashMap<>;
    private final Node head = new Node<>;
    private final Node tail = new Node<>;
    public LRUCache{
        this.cap = capacity;
        head.next = tail; tail.prev = head;
    }
    public V get{
        Node n = map.get;
        if return null;
        moveToTail;
        return n.val;
    }
    public void put{
        if){
            Node n = map.get;
            n.val = value;
            moveToTail;
            return;
        }
        if>=cap){
            Node lru = head.next;
            remove;
            map.remove;
        }
        Node node = new Node<>;
        addTail;
        map.put;
    }
    private void remove{
        n.prev.next=n.next;
        n.next.prev=n.prev;
    }
    private void addTail{
        n.prev=tail.prev;n.next=tail;
        tail.prev.next=n;
        tail.prev=n;
    }
    private void moveToTail{
        remove;addTail;
}
}

from collections import defaultdict, OrderedDict
class LFUCache:
    def __init__:
        self.cap   = cap
        self.min_f = 0                     # 当前Zui小频次
        self.key_val_freq = {}             # key -> 
        self.freq_bucket = defaultdict   # freq -> {key:None}
    def _inc:
        val,freq = self.key_val_freq
        del self.freq_bucket
        if not self.freq_bucket:
            del self.freq_bucket
            if self.min_f == freq:
                self.min_f += 1
        freq += 1
        self.key_val_freq = 
         # 保持插入顺序，用于同频时的 LRU 行为
        self.freq_bucket = None
    def get:
         if key not in self.key_val_freq: return -1
         self._inc
         return self.key_val_freq
     def put:
         if self.cap==0: return
         if key in self.key_val_freq:
              self.key_val_freq=
              self._inc;return
         if len>=self.cap:
              # 淘汰 min_f 桶中Zui旧的键
              evict,_=self.freq_bucket.popitem
              del self.key_val_freq
         # 插入新键 freq=1
         self.key_val_freq=
         self.freq_bucket=None
         self.min_f=1

type LFU struct{
    cap int
    minFreq int
    keyVal mapint          // key -> value
    keyFreq mapint          // key -> freq
    freqBucket map*list.List // freq -> keys list 
}
func NewLFU*LFU{
    return &LFU{
        cap:c,
        minFreq:0,
        keyVal:make,
        keyFreq:make,
        freqBucket:make,
    }
}
func  Getint{
    if _,ok:=l.keyVal;!ok{ return -1}
    l.incr
    return l.keyVal
}
func  Put{
    if l.cap==0{ return }
    if _,ok:=l.keyVal;ok{
        l.keyVal=v
        l.incr;return}
    if len>=l.cap{
        l.evict
    }
    l.keyVal=v
    l.keyFreq=1
    if l.freqBucket==nil{ l.freqBucket=list.New}
    l.freqBucket.PushBack
    l.minFreq=1
}
func  incr{
    f:=l.keyFreq
    // 从旧桶摘除
    b:=l.freqBucket
    for e:=b.Front;e!=nil;e=e.Next{
        if e.Value.==k{b.Remove;break}
    }
    if b.Len==0{
        delete
        if l.minFreq==f{ l.minFreq++}
    }
    f++
    l.keyFreq=f
    if l.freqBucket==nil{ l.freqBucket=list.New}
    l.freqBucket.PushBack
}
func  evict{
    b:=l.freqBucket
    e:=b.Front
    evictKey:=e.Value.
    b.Remove
    if b.Len==0{ delete}
    delete
    delete
}

LUA 时钟 : 每个对象dou有一个秒级计数器，用来标记Zui近一次被读取的时间戳。淘汰时 Redis 并不会遍历全部键，而是随机抽样 N 个键，取其中时间戳Zui小者踢掉。增大 maxmemory-samples Neng提升精度，但 CPU 开销也随之上升——经验上取 10~15 就足够大多数业务了。

LFR 算法中的对数计数器：

-bit counter : 越高越难继续增长，实现了“热点越热增长越慢”的自然衰减。

Lfu-decay-time : 每隔一定分钟将计数右移一位，让曾经热门但Yi冷却的数据逐渐失去优势。

Ru果你把这些参数dou调到极致，却仍然发现命中率低，那hen可Neng是业务本身缺乏时间局部性，需要重新审视缓存粒度或拆分不同维度的独立缓存实例。

A：删除节点时需要快速拿到它前驱，否则只Neng从头遍历 O。双向链表提供 O 的 prev 指针，使得「摘除」和「移动到尾部」dou保持常数复杂度，这正是面试官想kan到的数据结构功底。

A：核心思路是「两个哈希 + 有序集合」：

{key → }

{freq → LinkedHashSet}

#minFreq 指针直接定位待淘汰桶，实现 O

A：精确 LRU 要维护全局有序链表，每一次访问dou要改动链表节点，在千万级并发下 CPU 开销不可接受。Redis 用「近似」方式——采样 + 时钟计数——牺牲一点准确率，却换来可观的性Neng提升，这也是业界普遍接受的折中方案。

Ru果你现在正为「我的缓存总是命中率低」而抓狂，请先检查三件事：

CACHE SIZE 是否Yi经达到了业务峰值需求？

EVICTION POLICY 是否匹配访问特征？

SAMPLE 参数是否合理？ ​​​​​​​​​​ ​​​​​​​​​​​​​​​​​​​ ​​​​​​​​​​​​​‌‌‌‍‍‍‌‍‌‍‏‏‏‏‏‏‏‏‎‎‎‎‎‎‎‎ ‎ ‎ ‎ ‌‌‌‌                )

一句话：**先把容量调好，再根据监控指标挑选合适算法**；若还有余力，再玩自适应 ARC 或者自行实现 2Q，以防止“一刀切”导致的数据污染。祝你在实际项目里玩转缓存，从此不再为 “cache miss” 烦恼！ 🎉🚀️🧩️✨️.