我有个下属能力很强，独挡一面，我怕他突然跳槽整个团队得垮掉，我该怎么办？得做些什么防范？网友评论：把位置让给他

LFU 缓存这玩意儿，刚开始听名字感觉像是个电信套餐，Least Frequently Used，翻译过来就是“最不常用的淘汰策略”。哎，想想也挺现实的——凡是你不常用的，总有一天会被系统无情地清理掉。像不像平时你写的功能，一周没被调用，老板立马说删了吧 🙃

我第一次写 LFU 缓存，是因为面试被问爆了，后来我认真实现了一遍之后，才发现这题不光考你对数据结构的熟悉，还真挺考细节能力的。最关键的，是怎么在 O(1) 时间复杂度里完成 get 和 put 操作。你说得轻巧，谁实现谁知道。

讲人话就是，我们要设计一个数据结构，它能记住每个 key 的使用频率，并且当容量满了之后，要优先踢出最少被使用的那个 key。如果有多个 key 使用次数一样少，那就把最早插进去的那个踢掉，简直就是“又卷又讲资历”的世界 😅

我最开始的思路是，哈希表 + 优先队列，听起来蛮对，但写起来很快就暴露问题了：优先队列里频率变了，还得重排，时间复杂度根本扛不住面试官的毒打。

后来翻了点资料，又结合自己想法，搞了个比较靠谱的结构：

classLFUCache {
privatefinalint capacity;
privateintminFreq=0;
privatefinal Map<Integer, Integer> keyToVal = newHashMap<>();
privatefinal Map<Integer, Integer> keyToFreq = newHashMap<>();
privatefinal Map<Integer, LinkedHashSet<Integer>> freqToKeys = newHashMap<>();

publicLFUCache(int capacity) {
this.capacity = capacity;
    }

publicintget(int key) {
if (!keyToVal.containsKey(key)) return -1;
        increaseFreq(key);
return keyToVal.get(key);
    }

publicvoidput(int key, int value) {
if (capacity == 0) return;

if (keyToVal.containsKey(key)) {
            keyToVal.put(key, value);
            increaseFreq(key);
return;
        }

if (keyToVal.size() >= capacity) {
            evictLFU();
        }

        keyToVal.put(key, value);
        keyToFreq.put(key, 1);
        freqToKeys.computeIfAbsent(1, k -> newLinkedHashSet<>()).add(key);
        minFreq = 1;
    }

privatevoidincreaseFreq(int key) {
intfreq= keyToFreq.get(key);
        keyToFreq.put(key, freq + 1);
        freqToKeys.get(freq).remove(key);

if (freqToKeys.get(freq).isEmpty()) {
            freqToKeys.remove(freq);
if (freq == minFreq) minFreq++;
        }

        freqToKeys.computeIfAbsent(freq + 1, k -> newLinkedHashSet<>()).add(key);
    }

privatevoidevictLFU() {
        LinkedHashSet<Integer> keys = freqToKeys.get(minFreq);
intevictKey= keys.iterator().next(); // FIFO within same freq
        keys.remove(evictKey);

if (keys.isEmpty()) freqToKeys.remove(minFreq);

        keyToVal.remove(evictKey);
        keyToFreq.remove(evictKey);
    }
}

这个实现核心逻辑就是用 keyToVal 存值，keyToFreq 存频率，freqToKeys 管理每个频率下的 key 列表，用 LinkedHashSet 保证插入顺序不变。这样踢人时能精确锁定“最早但最少用”的那个。

最难调的地方是频率更新那里。我调这个逻辑时，简直像在玩狼人杀，删掉一个节点后，不知道到底该不该提升频率；一旦提升错了，整个缓存就像开错灯的狼，一夜之间全暴露 

写这个的时候我就感觉，做缓存策略的哥们，肯定都熬夜写过 CRUD 项目，然后意识到，做缓存优化才是自我救赎。

说点现实的吧，现在我们日常开发中，其实不一定要自己造轮子，像 Guava 的 CacheBuilder，或者 Spring 的 @Cacheable，内部都有类似的机制。但一旦你在面试或者高并发场景里要优化点细节，手撸一个 LFU，是个能看出水平的好题。

不过我还是得吐槽一句，如果真的在生产上用自定义 LFU 缓存，出了问题你可得自己背。建议在面试时候写写就好，回头别真上线了一个 bug 多的轮子，老板问你为啥不用 Redis 的淘汰机制时，你说你信仰手撸，那可能会被淘汰的是你 

程序员这行啊，能被频繁调用的总是那几个主力模块，其他的像我写的注释、测试、边角功能……哪天被删了也没人心疼。要不咱也学学 LFU 缓存算法，看看自己是不是快被踢出项目了……

最后，我为大家打造了一份deepseek的入门到精通教程，完全免费：https://www.songshuhezi.com/deepseek

也可以看我写的这篇文章《DeepSeek满血复活，直接起飞！》来进行本地搭建。

-END-

以上，就是今天的分享了，看完文章记得右下角点赞，也欢迎在评论区写下你的留言。