最大频率栈详解：双哈希表与频率桶的O(1)实现方案

上周我在刷题群里看到有人把 LeetCode 895 直接丢给 Kimi，Kimi 很快给了一版看起来特别标准的“双哈希表 + 频率桶”解法。第一眼确实漂亮，但那个人照着敲完，把测试用例一拉长，发现 pop 的结果开始对不上了。问题出在哪？出在它对最大频率降低时的处理太想当然，甚至没想过同一个值可能在多个频率桶里同时留下记录。

所以我决定把这题从头到尾掰开揉碎讲一遍，尤其讲清楚那些 AI 不会主动告诉你的边界条件。LeetCode 895 的全名叫 Maximum Frequency Stack，中文社区一般叫“最大频率栈”。它要求你设计一个 FreqStack 类，实现两个方法：

• push(int val)：往结构里压入一个元素。
• pop()：弹出并返回当前出现频率最高的元素；如果最高频有多个，则返回距离栈顶最近的那个，也就是最近一次 push 进去的那个。

这是一道典型的数据结构设计题，难度是 Hard，但它不需要任何高级算法。真正卡人的地方是：你能不能想到用“两个维度”去管理元素，以及能不能把同频元素之间的先后关系处理干净。

1. 我最初对题目的误读：最大频率栈到底在弹谁

刚看到“栈”这个字的时候，我下意识以为能用一个普通数组模拟。毕竟栈的特性就是后进先出，pop 直接弹尾部就行。但仔细读题，这个栈的 pop 规则其实分成了两步：

1. 先找到当前出现次数最多的元素。
2. 如果出现次数最多的元素不止一个，再在这些元素里找最近 push 的那个。

也就是说，它要比较两个关键字：第一关键字是频率，第二关键字是“时间新鲜度”。普通栈只比时间新鲜度，不比频率，所以普通栈根本处理不了这个需求。

这里我放一个反例，你可以体会一下普通栈方案的崩溃过程：

按顺序 push 1、push 2、push 1、push 2、push 3。此时元素频率是：

• 1 出现了 2 次
• 2 出现了 2 次
• 3 出现了 1 次

如果按最大频率栈的规则，第一次 pop 应该返回谁？1 和 2 频率并列最高，都是 2 次，要比“最近 push”。2 的最后一次 push 发生在第 4 步，比 1 的最后一次 push（第 3 步）晚，所以答案应该是 2。

但普通栈的栈顶是 3，你只能先把 3 弹出来，再弹 2，然后考虑怎么把 3 放回去。放回去还能保持原来的相对顺序吗？普通栈做不到，因为你已经改变了栈顶。更麻烦的是，后续如果还要按频率规则继续 pop，所有被临时弹出的元素都需要一个临时空间暂存，复杂度直接失控。

这个例子说明了一件事：你不能把所有元素堆在一个主栈里，因为 pop 的目标不一定在主栈的栈顶。你必须在压入元素的同时，就把“频率”和“同频率下的时间顺序”这两部分信息提前组织好。

还有一个很容易被忽略的点：pop 之后，元素的频率会动态变化。比如刚才第一次 pop 返回的是 2，弹完之后 2 的频率降到 1。这时候下一个 pop 又该返回谁？不是凭感觉，而是要看更新后的频率分布。这也是为什么题目本质上是设计一个“实时维护动态频率序列”的结构，而不是一个静态排序问题。

很多新手会掉进另一个坑：以为频率最高的元素就永远是那几个“老面孔”。不是的。元素频率会随着每次 push 和 pop 实时变化，任何缓存了“全局最高频元素”而不关心频次变化的方案，都会在多次操作后失效。

所以我在动手写代码之前，先把题目里的排序规则拆成了两条清晰约束：

• 频率高者优先；
• 频率相同，最后到达者优先。

这两条约束一旦明确，数据结构的选择就很自然了：直接用哈希表记录元素频率，再用一组“频率桶”来维护同一频率下的元素顺序。这就是我们常说的双哈希表方案。

2. 双哈希表的分工原理：一张频率账本，一组历史栈

先直接给结论，这个方案维护三个核心变量：

• 哈希表 cnt：记录每个元素当前出现了几次。
• 哈希表 groups：key 是某个出现次数，value 是一个栈。groups[f] 里按 push 顺序存着“当某个元素被 push 成第 f 次时”的那个元素记录。
• 整数 maxFreq：记录当前所有元素里的最大出现次数。

拿生活场景打个比方。你可以把 cnt 想象成每个人的“打卡次数账本”，每来一次记一笔。groups 则像一排领奖台，1 次奖台、2 次奖台、3 次奖台……每个奖台前有排队通道，通道按到达顺序排列，先到先排队。

当有人打卡次数达到 f 时，他就会被放进第 f 层奖台的队伍末尾。pop 时我们永远先看最高那层奖台 maxFreq，从队伍末尾拉一个人出来。这样既保证了高频率优先，也保证了同频率下时间最近优先。

很多人第一次接触这个方案时会卡在一个很关键的地方：同一个值，会不会在多个 groups[f] 里同时出现？答案是会，而且必须会。

举个例子，连续 push 三个 5：

• 第一个 5 push 时，5 刚出现 1 次，于是往 groups[1] 里放一个 5。
• 第二个 5 push 时，5 已经出现 2 次，于是往 groups[2] 里放一个 5。
• 第三个 5 push 时，5 已经出现 3 次，于是往 groups[3] 里放一个 5。

此时 5 这个元素在 groups[1]、groups[2]、groups[3] 三个桶里都各有一条记录。你可以把这些记录理解为“历史流水账”：每一条都代表着一次真实的 push 操作。第三次 push 进去的那个 5，如果将来被 pop 出来，它只代表“第二次 push 后新出现的那份数据被移除了”，但第一次、第二次 push 产生的数据还在结构里，依然有效。

想明白这一点，后面处理频率降低时的逻辑才能不绕晕。

接下来追问第二个问题：为什么 groups[f] 里要用栈而不是队列？因为题目说了，同频率下要返回“最近 push”的那个。栈天然满足后进先出，groups[f] 的栈顶正好是达到第 f 次频率时最新被 push 的元素，所以用栈是最顺手的。

如果用队列，同频下返回的就是最早 push 的那个元素，那对应的是另一道变种题。我们后面讲扩展时再展开。

最后一个看似平凡但其实很重要的点是：cnt 中记录的是“当前时刻每个元素的总出现次数”，而 groups 中记录的是“历史 push 序列”。两者并不一一对应，cnt[val] 等于所有还没被 pop 的 groups[f] 里 val 的记录条数。如果你在调试时发现一个元素明明只出现 2 次，却在 3 个频率桶里都有记录，不要慌，这说明其中有记录对应的 push 已经是一个“历史事件”了，只是还没到被弹出的时机。

理解了这两层分工，就可以写代码了。写代码本身不难，难的是把所有边界条件都照顾到。

3. push 与 pop 的核心代码，以及最容易写错的三个细节

Python 实现看起来非常简单，官方题解和 AI 给的版本基本长这样：

python复制from collections import defaultdict

class FreqStack:

    def __init__(self):
        self.cnt = defaultdict(int)
        self.groups = defaultdict(list)
        self.max_freq = 0

    def push(self, val: int) -> None:
        self.cnt[val] += 1
        f = self.cnt[val]
        self.groups[f].append(val)
        if f > self.max_freq:
            self.max_freq = f

    def pop(self) -> int:
        val = self.groups[self.max_freq].pop()
        self.cnt[val] -= 1
        if not self.groups[self.max_freq]:
            self.max_freq -= 1
        return val

核心逻辑只有十几行。但如果你真拿去跑，会发现几个容易踩坑的地方，这里逐个展开。

第一个坑是 max_freq 的下降逻辑。很多人会在 pop 后写一个 while 循环，试图一层一层往下找非空桶。其实完全不需要。你只需要在 groups[self.max_freq] 变空时把 max_freq 减 1，就是正确结果。为什么？因为这次 pop 只把一个元素的频率从 max_freq 降到了 max_freq - 1，其他元素的频率都没变。如果原本 max_freq 这层还有其他元素，那这层桶不会为空，最大值不会变；如果这层桶为空了，说明没有其他元素还停留在 max_freq，那么整个结构里出现次数最高的元素最多只可能是 max_freq - 1。所以一步到位，不需要循环。

第二个坑是 cnt[val] 减到 0 后要不要删掉。如果使用 Python 的 defaultdict，不删也没问题，因为下次再 push 同一个 val 时会从 self.cnt[val] += 1 自动把 0 变成 1。但如果你自己手写普通 dict，需要注意先判断 key 是否存在。很多人写完 elif self.cnt[val] == 0: del self.cnt[val] 这类逻辑，反而在后续 push 时把 key 不存在的情况忘了，导致 KeyError。

第三个坑是空结构调用 pop。LeetCode 原题保证了不会在空栈上调用 pop，但你要是把这个类拿去做单元测试，没事就 pop 一下，就会遇到 group[0] 不存在的尴尬。严谨的做法是在 pop 开头判断一下结构是否为空，比如判断 self.max_freq == 0，空则抛异常或返回约定值。不过这样一来，groups 和 cnt 里的空 key 管理就要更小心。

我再放一个运行轨迹示例，你可以自己手动推一遍，确保理解没跑偏。

假设执行以下操作序列：

text复制push(1)
push(2)
push(1)
push(2)
push(3)
pop()
pop()
pop()
pop()
pop()

整个过程可以画成一张状态表：

第一次 pop 返回 2，第二次 pop 返回 1，第三次却返回 3。很多人到这里就不理解了：“3 不是只出现了一次吗，为什么能排到 1 和 2 前面？”因为此时 1 和 2 的频率都已经降成 1，场上最高频率就是 1，而 3 是同频下最近 push 的元素，所以它先出。这就是动态频率结构的反直觉之处：某个低频率元素可能在某个时刻成为最高频率层的“代表”。

4. 复杂度、正确性证明，以及堆方案为什么看着香却不够好

这个方案的时间复杂度非常漂亮。push 和 pop 的每一步都是常数次哈希表读写、一次数组尾部操作（列表的 append 和 pop 摊还 O(1)），所以两个操作的平均时间复杂度都是 O(1)。空间复杂度是 O(N)，N 是当前还存活在结构里的 push 次数之和。因为有多个频率桶，但所有桶里的记录总数正好等于当前还没被 pop 的元素个数，不会额外膨胀，除非你不断 push 同一个值，那也只是在每个频率桶各存一条历史记录，总数还是 O(N)。

为什么正确性有保证？我习惯分两点证明：

第一，maxFreq 一定等于当前全局最大出现次数。push 时，只有被 push 的元素频率增加了，maxFreq 取它与旧值较大者；pop 时，被弹出元素的频率从 maxFreq 降到 maxFreq - 1。如果原最高层还有其它元素，则最大频率不变；如果原最高层空了，那所有其它元素的频率都不超过 maxFreq - 1，所以 maxFreq 减一后依然准确。用数学归纳法，每个操作前后这个不变量都成立。

第二，groups[maxFreq] 的栈顶，一定就是本次 pop 应该返回的元素。栈顶的含义是“达到最大频率的元素中，最后一次 push 的那个”。我们需要返回的规则恰好就是“频率最高 + 频率相同则时间最新”，所以它和弹出策略完全对齐。

有些人会觉得这题可以用堆做：维护一个大根堆，堆里每个元素存 (出现次数, 最新时间戳, val)，每次 pop 取堆顶。这个思路也能得到正确答案，因为在时间维度上你用了一个全局递增的时间戳来区分新旧。但问题是，每次 push 或 pop 之后，受影响元素的 (次数, 时间戳) 发生变化，需要重新插入堆或做标记删除，单次操作复杂度会到 O(log N)。LeetCode 的数据范围下当然能过，但如果你在面试里能给出双哈希 O(1) 方案，说明你对"同类元素归组"的理解更深。

堆方案还有一个隐藏问题：你没法直接修改已经放在堆里的旧元素。你只能用一个“懒惰删除”技巧，每次 pop 时先弹出堆顶，如果发现它的频率已经和当前 cnt[val] 对不上，就继续弹出，直到堆顶元素的数据是新鲜的。这代码写起来比双哈希复杂，而且容易在“清理过期堆顶”时把有效元素也丢掉。

如果你一开始想的是“直接遍历找最大频率”，那也不是不行，但每 pop 一次需要扫全部元素，时间复杂度 O(N)。面对原始题的 2×10^4 次操作也勉强能过，但完全没有技术含量。面试官想看的显然是更优的动态维护思路。

双哈希方案最好的地方在于：它不依赖任何排序结构，不用全局时间戳，也不用处理堆里的过期节点。所有信息都被拆成了两个维度的哈希索引，每个维度各司其职。这种设计在系统设计里也非常常见：想要快速回答“谁最大”，就维护一个专门记录最大值的变量；想要快速回答“同档次里谁最新”，就把同一档次做成栈。你需要什么查询能力，就为它建立一个索引。

还有一个常见优化点：如果你提前知道值的范围很小，可以用数组替代 cnt 哈希表，用二维数组替代 groups。比如题目改成值范围是 0 到 100，那 groups 可以开成 101 个栈，访问速度更快，代码也更直白。但 LeetCode 895 并没有限定范围，所以用哈希表是最通用、最稳的选择。

5. 把这道题的思路迁移到真实系统：变体题和 LFU 的影子

LeetCode 895 不是孤立的。它和缓存淘汰算法 LFU（Least Frequently Used）有很深的血缘关系。LFU 需要淘汰“使用频率最低”的项，如果频率最低的项有多个，再淘汰“最久未使用”的项。你看，这跟最大频率栈是不是很像？只是一个取最大频率，一个取最小频率；一个同频比“最近”，一个同频比“最久”。

LFU Cache（LeetCode 460）的经典实现里有两套哈希桶结构：一套是 key -> 频率，另一套是 频率 -> 一个装着该频率所有 key 的双向链表。这个“频率桶”的设计思路正是从我们今天讲的 groups[f] 演变来的。只不过 LFU 还要求支持 get 和 put 时把 key 从旧频率桶搬到新频率桶，并且淘汰时要从最小频率桶里删掉最不常用的节点，所以双向链表 + 哈希表就成了必需品。

从这道题往外延伸，有三类变种值得思考。

第一类变种：同频条件下，改成返回最早 push 的元素，而不是最近的。这很简单，只需要把 groups[f] 从栈改成队列（双端队列）就行。push 的时候从尾部 append，pop 的时候从头部 popleft。为什么题目原来的默认值是栈？因为要求里写了“距离栈顶最近”，所以 LIFO 是正确的；如果哪天需求方说“频率相同就淘汰最老的那个”，那答案就切换到队列版本。这个改动很便宜，但很多学习者在理解时没有意识到“同一份框架，只换内层容器就能适配不同淘汰策略”。

第二类变种：支持“删除指定值”的操作。这就不简单了，因为栈结构不支持随机删除。你只知道某个值需要删，但它在每个频率桶里的位置是任意的。为了支持任意删除，你需要把每个频率桶里的普通栈替换成“可删除的双向链表”，同时再维护每个值在哪些频率桶里出现了哪些节点。这种复杂的哈希表 + 双向链表结构，基本就进化成了 LFU Cache 的实现。

第三种变种场景是：不要求 O(1)，只要求能快速跑通。比如你手头有 10 万个元素想要随时取得“最高频 + 最近”的元素，用双哈希仍然合适；但如果你还要支持“把某个频率段的元素全部取出来”这种范围查询，那可以考虑再叠加一棵平衡树，key 是 (频率, 时间戳)，每次查询最大值就非常自然。不过平衡树方案单次 O(log N)，而且内存占用比双哈希高，除非需求真的需要范围查询，否则没必要。

在真实项目里，这种结构常用于热词统计、活动打榜、库存热点商品标记等场景。打个比方，一个商城后台要实时找出“被加入购物车次数最多的商品”，如果次数相同则找最近被加购的那个，这就是最大频率栈的完美业务映射。你可以直接用它实现一个非常轻量的实时榜单，不需要上 Redis 的 ZSET，也不需要维护外部分数表。

还有一点值得提：如果你准备把这题写进简历项目或者技术博客，最好补充一个随机对拍测试。写一个暴力版本：维护一个数组，每次 pop 时遍历数组按频率和最新时间选答案；再写一个双哈希版本；然后用随机操作序列对比两次输出。几百次随机操作后如果结果一致，代码的正确性基本就有保障了。这个对拍方法也适用于所有数据结构设计题的调试。

最后再分享一个我自己的经验：面对这种“两个维度排序”的题，第一反应不要急着写代码，先把两个维度分别抽象出来，想清楚每个维度该用什么容器维护。频率维度用哈希表做索引，时间维度用栈或队列等线性结构维护顺序，两个维度通过“每次 push 的频次变化”串联起来。大多数设计题都能用这种“单维度容器组合”的思路解决，LeetCode 895 是其中最容易理解的一个入门范例。

我后来也拿这道题去测试过好几个 AI 代码助手，它们的回复大多能给出双哈希框架，差别只在于边界条件的细节处理。所以如果你想检验一个算法讲解是否靠谱，直接追问它三个问题：maxFreq 到底什么时候减一？cnt[val] 减到 0 要不要删 key？同一个值为什么可以出现在多个频率桶里？能把这三点讲清楚的，才是真的理解了解法，而不是背了一版模板代码。