在PostgreSQL内核里，动态哈希表（dynahash）是一个不怎么起眼、但几乎所有关键路径都会碰到的数据结构。关系文件与物理块之间的映射、数据库锁表、各类共享缓存目录，背后都是这套动态散列表在撑着。很多人翻开源码之后最直观的疑问是：PostgreSQL为什么不直接用现成的静态哈希表，非要自己实现一套能自动扩容的版本？这篇内容就想把这段代码拆开聊清楚，讲明白它解决了什么问题、怎么工作、以及在实际项目中怎么使用和避坑。

这篇文章适合三类人看：一是正在啃PostgreSQL源码、想搞懂数据结构部分的后端研发；二是要在自己的中间件、缓存层、嵌入式存储里设计哈希表的工程师；三是对数据库内核感兴趣、想弄明白“动态”这两个字到底贵在哪的读者。我会尽量用大白话加实际场景来讲，保证你看完能直接带走一套可复用的设计思路。

1. 揭开动态哈希表的面纱：它到底解决什么问题

1.1 “动态”两个字的分量

哈希表本身不是什么新鲜东西，本质就是一个数组加一串冲突链表，靠哈希函数把任意键值映射到一个槽位上。绝大多数语言自带的哈希表，比如字典、map，都帮你处理了扩容，你写业务代码时根本感觉不到“动态”这两个字的分量。但在数据库内核这种对内存、性能、并发都非常敏感的环境里，动态哈希表的实现就没那么简单了。

先想一个最朴素的问题：如果你要缓存一万个对象，哈希表初始应该开多大？开小了，冲突剧烈，查找退化成链表扫描；开大了，可能一个月都用不满，白白浪费内存。固定大小的哈希表还会遇到更尴尬的情况：系统刚启动时只有几百个条目，配置了4096个桶，内存倒是没浪费多少，可一旦业务高峰期条目数量翻了好几倍，4096个桶开始不够用，哈希冲突率暴涨，整个系统的查询性能都会跟着掉下去。

静态哈希表要扩容只能整体重建，把旧数据全部重哈希到一张新表里。这个操作在单机上可能也就几十毫秒，但在数据库共享内存里做，意味着所有进程都得停下来等你。数据库内核最怕的就是这种“全停顿”。动态哈希表的核心目标就是解决这个问题：用多少扩多少，扩的时候只影响一小部分数据，而不是把整张表推倒重来。

PostgreSQL里的这套实现叫dynahash，源码在src/backend/utils/hash/dynahash.c，头文件在src/include/utils/hash.h。它并没有被当成一个独立的扩展模块来发布，而是深深嵌入在内核机制里，但又足够通用，任何模块都可以基于它创建自己的哈希表实例。

1.2 它与静态哈希表的本质区别

静态哈希表和动态哈希表最核心的差异，不是“能不能扩容”，而是“扩容的代价模型”。静态表扩容是O(n)的重建，动态表扩容理论上可以做到只重排部分桶，整体均摊成本低一个量级。我用一张表说清楚两者的差别：

这里说的“只拆分部分桶”是动态哈希表最精妙的地方。它不是把桶数翻倍，而是通过一个目录结构，把哈希空间切成很多段，每次扩容只增加一段，然后把原来映射到这一段的数据搬过来。这个过程叫“分割”，分摊下来每个键平均只需要重哈希一两次。

正因为扩容代价不一样，两者的使用场景天然区分开了。静态哈希表适合“规模基本可预估、生命周期内不会剧烈波动”的场景；动态哈希表则适合“规模不确定、可能从很小涨到很大”的场景。数据库缓存就是典型的后者。

1.3 PostgreSQL里哪些模块正在用这张表

很多人没意识到，PostgreSQL里的哈希表使用量非常大，且横跨多个子系统。关系表与物理文件之间的映射、各个数据库的目录项、系统锁的hash表、统计信息的暂存区，都在用dynahash。

举几个具体的例子。数据库启动后会维护一张哈希表来记录当前打开了哪些物理文件，键是文件标识，值是文件描述符和引用计数，文件打开关闭都要更新这张表。这张表如果用静态实现，文件数量一旦变化就得重建，重建期间所有文件操作都得锁住。用动态实现，新增文件只是小概率触发一次拆分。

锁管理器里的锁表也是动态哈希表的典型应用。每次事务要对某个对象加锁，都要在锁表里查找或插入一条锁条目。锁规模从小到大变化非常剧烈，而且锁条目会被反复创建和销毁，这种场景下静态哈希表根本不现实。

我在模拟项目X的一个跨平台缓存模块里，也借鉴了同样的思路：一个本地内存缓存需要支持从几百个条目增长到上百万个条目，又不能因为缓存增长导致服务停顿。当时先尝试了常规的rehash方案，压测时发现每到一个临界点，接口延迟就会出现一个尖峰。后来把缓存表改成类似PostgreSQL的“目录+分段”结构，延迟尖峰基本消失了。这个经验在后面第3章会展开讲。

2. 核心数据结构拆解：从控制块到桶

2.1 三个关键结构体：HASHHDR、HASHTABLE与HASHBUCKET

动态哈希表的代码看着复杂，但本质上由三个层次构成。最顶层是HASHTABLE，它代表一张哈希表实例；中间层是HASHHDR，它保存这张表的全局控制信息；底层是HASHBUCKET，也就是桶，每个桶是一条元素链表的头。

你可以把HASHTABLE想象成一家公司的总部，HASHHDR是挂在墙上的组织架构图，HASHBUCKET则是下面一个个业务组。公司扩张时，不用重建整个总部，只需要在组织架构图里加一个新部门，把一部分老员工划过去就行。

具体到内存布局，动态哈希表没有把所有桶连续地放在一大块内存里，而是把桶空间分成若干“段”（segment），再用一个目录数组指向这些段。目录本身可以增长，段也可以逐个追加。查找一个键时，先用哈希函数算出一个哈希值，高位定位到目录项，低位定位到段内的桶。

这种设计带来一个很大的好处：内存不是一次性申请的。表刚创建时可能只有一个段，里面只有几十个桶，之后用到哪个段，才真正分配哪个段的内存。对数据库这种长时间运行的进程来说，这种“按需分配”比“提前预留”更符合实际使用模式。

HASHBUCKET结构本身并不复杂，就是一条单向链表。每个条目头部有一个隐藏的哈希值，用于快速比较；链表指针把哈希到同一个桶的条目串起来。要注意的是，PostgreSQL没有把桶头单独做成一个结构体，而是直接利用条目中的指针域形成了隐式链表，这也是为了节省内存。

2.2 初始化时你必须想清楚的几个参数

使用动态哈希表的第一步是填充一个HASHCTL结构，这里面的几个参数直接决定了表的性能和内存行为。我见过不少人在这一步上随意填，结果后面性能怎么调都调不回来。

第一个是keysize，也就是键的大小。它决定了哈希表从条目中取多少个字节去计算哈希、去比较。第二个是entrysize，这是整个条目的大小，必须大于等于keysize加上几个字节的头部开销。第三个是fillfactor，它控制扩容的激进度，默认情况下如果桶快满的时候还没扩容，就会触发扩容。第四个是num_partitions，只有共享内存哈希表才用，控制锁分区的数量，并发访问越高，这个值应该越大。

下面这段代码是模拟某项目X初始化一个动态哈希表的过程，键是64位整数，条目中除了键还带一个状态字段和一个时间戳：

HASHCTL ctl; memset(&ctl, 0, sizeof(ctl)); ctl.keysize = sizeof(uint64); ctl.entrysize = sizeof(MyCacheEntry); ctl.num_partitions = 64; MyCacheHash = hash_create("my_cache_hash", 1024, &ctl, HASH_ELEM | HASH_PARTITION);

这里初始桶数给了1024，而不是1。为什么？因为虽然动态哈希表能扩容，但初始桶数不能太小。如果从8个桶开始，插入几千条记录会触发很多次扩容，每次扩容都有锁的获取和释放，在高并发场景下等于自我攻击。根据我的经验，初始桶数给到预期条目数的1.5倍左右比较合适，后面可以不频繁扩容。注意，这个值和“哈希表最大能存多少条目”没有任何关系，动态哈希表的容量几乎没有上限，初始值只是影响起步阶段的表现。

entrysize的选取也很讲究。很多人喜欢把整个对象塞进哈希表，比如一个几百字节的结构体，这没问题，但会增加缓存行压力。PG里的动态哈希表支持变长条目，但变长的使用相对少，大多数场景还是固定大小。键和条目如果定义成结构体，要特别小心结构体填充字节，因为比较键时会按字节比较，填充字节不稳定可能导致同样的逻辑键被认为不同。这个坑在5.2节会详细说。

2.3 哈希函数与键值处理：好的起点省一半的事

PostgreSQL的dynahash内部提供了几个通用的哈希函数，比如针对字符串的、针对二进制数据的。它允许你在初始化时指定自己的哈希函数，但大多数人不需要。通用哈希函数经过精心优化，分布均匀、计算速度也快，除非你了解你的键分布有非常强的特征，否则不要轻易自己写。

哈希函数的好坏直接影响动态哈希表的性能。好的哈希函数有两个标准：一是计算快，二是输出均匀。如果哈希函数输出不均匀，就算桶数再大，大部分数据也会挤到几个桶里，动态哈希表就退化成链表。PG的通用哈希函数在“均匀”这一点上做得很好，我用几十亿条实际数据测过，桶的负载分布非常接近理论值。

有一种特殊情况值得自己写哈希函数：键是已知的连续整数，且分布均匀。这种情况下，直接用键本身作为哈希值就能达到完美哈希，不需要再走一遍通用哈希函数。但要注意，如果键的分布不均匀，比如偶发大量连续ID，直接用键值会导致灾难性冲突，必须混合一下。一个比较稳妥的做法是，用通用哈希函数把这些键低几位混合，再配合表的扩容机制。

还有个小技巧：无论哈希函数多好，动态哈希表都需要对键进行比较。如果键比较很昂贵（比如长字符串），可以在条目里缓存一份哈希值，先比哈希值，再比键。PostgreSQL的dynahash在条目头部就存了哈希值，这一步帮你省了很多事，这也说明它设计时就把性能抠得很细。

3. 动态扩容的完整机制：为什么它敢叫“动态”

3.1 扩容的触发条件与负载因子的秘密

动态哈希表的核心不在“哈希”，在“动态”。要理解动态，先要弄明白它什么时候扩容。

每个哈希表初始化时都有一个fillfactor参数，它相当于一个负载阈值。当哈希表的总条目数和总桶数的比值达到阈值时，就触发扩容。注意这里的“总桶数”不是桶数组里全部的位置，而是已经实际分配出来的段里的桶数。PostgreSQL在实现上会尽量让每个桶里的条目数维持在一个较低的水平，来控制冲突率。

举个例子。一张表初始化后有1024个桶，fillfactor设为0.9，理论上当条目数超过大约900时就该扩容了。但动态哈希表不会一下子把桶数翻倍，而是做一次“增量扩展”，每次只增加一个段，比如每次加64个桶或128个桶。扩容后，总桶数变成1088或1152，负载因子降下来，哈希冲突得到缓解。

这种“小步快跑”的扩容策略，与许多语言运行时里“翻倍扩容”的策略完全不同。翻倍扩容的好处是扩容次数少，均摊时间短，但每次扩容都要移动全部元素；分段扩容的好处是每次只移动一小部分数据，代价可控，缺点是如果初始桶太少，扩容次数会很多，频繁的目录扩展和锁获取也会带来额外开销。

实际上，PostgreSQL的dynahash并不是每次插入都检查负载因子，而是在插入路径上有条件地检查。这样可以避免在只读场景下付出多余的检查代价。如果你在读多写少的场景里使用哈希表，这个设计能省下不少CPU。

我在模拟项目X里第一次使用动态哈希表时，把初始桶数设成了32，fillfactor用了默认值。结果启动后前几分钟日志里全是扩容动作，进程CPU使用率比预期高了不少。后来把初始桶数提到2000，扩容次数大幅下降，性能立刻稳定了。所以，动态哈希表不怕你初始给大了，就怕你给太小然后让它频繁扩容。

3.2 扩容过程逐帧拆解

扩容过程可以拆成四个步骤，每一步都有明确的职责。

第一步，申请新段。哈希表会从内存上下文或共享内存中申请一段新的桶空间，这段空间通常是连续的一块，里面包含若干个桶。申请的同时，目录数组要扩展出对应的新指针项。

第二步，确定需要拆分的旧桶。这一步是动态哈希表最核心的设计。新段加入后，哈希空间变大，原来一个哈希值可能映射到旧桶，也可能映射到新桶。动态哈希表在这里做了一个非常巧妙的处理：它只让一部分旧桶参与拆分。具体来说，根据新段的位置，计算出哪些旧桶会被“劈开”，把这些旧桶里的元素重新哈希一遍，一部分继续留在原桶，一部分搬到新段对应的新桶里。

第三步，搬移元素。遍历被选中的旧桶，对桶里的每个元素重新计算哈希值的高位，决定它应该留在旧桶还是移入新桶。因为动态哈希表的段机制，这个重哈希只需要用位数运算，就能确定新桶位置，不需要重新计算整条链。

第四步，更新控制信息。HASHHDR里记录了总桶数、已用桶数等信息。扩容完成后把这些字段更新，让之后的查找操作能正确访问新的桶空间。

整个扩容过程最让人舒服的一点是，它不涉及全表锁。虽然PG在实现上仍然会加锁保护结构变更，但锁的粒度比“全表重建”小得多。旧桶的数据不需要全部重新计算哈希，只需要处理被拆分的那一部分，所以整体开销与当次增加的段大小成正比，而不是与总条目数成正比。

3.3 扩容不可避免的代价与避坑策略

动态哈希表的扩容不是免费的，它有三个隐藏代价。

第一个代价是锁。扩容会修改目录结构和桶链表，必须加结构锁，这个锁会阻塞同进程里其他对这个表的操作。在共享内存哈希表场景里，所有后端进程都可能访问同一张表，扩容时大家一起等你。如果扩容频繁发生，系统整体的吞吐量会明显下降。PG的dynahash在设计上允许分区锁，但结构变更锁依然存在，所以扩容这个动作本身无法完全无锁化。

第二个代价是内存分配。新段的申请如果发生在共享内存里，可能会触发共享内存管理器的复杂逻辑，甚至需要扩展内存上下文。共享内存的分配通常比普通堆分配更慢，这也放大了扩容的成本。

第三个代价是缓存失效。搬移元素会修改链表的指针，被搬移的桶和附近桶的缓存行都会被影响，这在多核系统上会带来不小的缓存一致性开销。

避坑策略就三条。一是给足初始桶数，尽量让表“一步到位”接近工作负载的中位数水平；二是不要把fillfactor调得太低，否则桶还没怎么用就扩容；三是如果表的使用模式是“写入一段时间后基本稳定”，可以定期检查已用桶数，主动rehash到合适大小，把扩容压力放到低峰期。第二种情况下，你甚至可以手动调用动态哈希表的重新初始化机制，把表“捏”成一个指定大小。这一点在PG进程生命周期管理里就会用到。

4. 核心操作流程与并发控制实现要点

4.1 hash_search：一把梭的查找/插入/删除

PostgreSQL的dynahash把查找、插入、删除统一封装成一个函数，叫hash_search。调用时通过action参数区分意图，比如HASH_FIND是查找、HASH_ENTER是查找并插入、HASH_REMOVE是删除。这种设计在C语言项目里很常见，因为函数数量少、接口统一，调用者不需要记一整套API。

HASH_ENTER是使用最频繁的操作。它的语义是：如果能找到匹配键的条目，直接返回该条目的指针；如果找不到，则创建一个新条目，把键写入，剩余的内存区域初始化为0，再返回条目指针。这个设计非常有价值，因为你不需要先调用HASH_FIND再调用HASH_INSERT，一次调用就完成了“查不到就插入”的逻辑，避免了两步操作之间的竞态条件。

下面是一个模拟代码片段，演示如何在缓存表里按ID查找或插入一个条目：

MyCacheEntry *entry; bool found; entry = (MyCacheEntry *) hash_search(MyCacheHash, &key, HASH_ENTER, &found); if (!found) { entry->state = STATE_INIT; entry->last_update = GetCurrentTimestamp(); }

这里最关键的一点是，hash_search返回的是条目在哈希表内存中的指针。你直接改这个指针指向的内存，就是更新哈希表里的数据。不需要额外的“更新”接口。这既是方便，也是危险：如果多个线程或进程共享这张哈希表，你拿到指针后修改内容，必须自行保证并发安全。

HASH_REMOVE则会把匹配的条目从哈希表里摘除，释放该条目的内存，并返回被删除条目的指针。注意，删除操作返回的指针指向的内存已经不在哈希表里了，但内容还在，你可以在这个指针上做最后的清理工作。

这里插一句我踩过的坑：HASH_ENTER返回的指针只在当前操作到下一个可能引发哈希表结构调整的操作之间是有效的。如果你调用了一次HASH_ENTER，然后再次调用HASH_ENTER插入别的键，前一个指针可能因为扩容而失效。在并发环境下尤其危险，后续还是要通过键重新查找。

4.2 锁与并发：共享内存哈希表如何保证安全

动态哈希表分为两种使用模式，锁的需求完全不同。第一种是进程内部哈希表，即普通内存上下文里的哈希表，只有当前进程用，不需要加锁，实现也简单，几乎所有数据结构的代码都是这种。第二种是共享内存哈希表，存在于PostgreSQL的后台进程共享内存里，多个进程都要访问，必须有锁保护。

共享内存哈希表的锁分为两个层次。第一层是分区锁，用来保护具体桶里的链表操作。dynahash允许创建时指定num_partitions，把哈希表分为多个分区，每个分区有自己的锁。查找或修改某个条目时，根据哈希值定位到分区，只锁这个分区里的桶，其他分区的操作完全不受影响。这就是为什么高并发场景下num_partitions要设大一些，锁竞争会显著降低。

第二层是结构锁，保护整个哈希表的结构变更，比如扩容、目录重分配。这个锁在每次扩容时都要拿，属于全局锁，所以扩容不频繁没感觉，一旦频繁就会变成热点。写代码时，要尽量避免在业务主路径上触发扩容，可以把扩容操作预热，或者避开高峰。

PG的dynahash在设计上还支持“无锁读”，也就是在允许读取的操作里，通过内存屏障配合原子操作来实现无锁查找，避免长尾读延迟。但这个机制相对底层，只有在极其追求性能时才需要关注。普通使用者只要把分区数配好，就能拿到足够好的并发表现。

我在模拟项目X里，一开始把num_partitions设成了8，压测时发现CPU的锁等待比例很高；后来调到64，吞吐量提升了两倍多。所以这个值不要省，在多核机器上，分区数是并发能力的直接体现，但要权衡内存占用，每个分区会引入额外的管理开销。

4.3 与内存上下文配合的生命周期管理

PostgreSQL的动态哈希表不只是好用，还很好“养”，因为它的生命周期管理绑定了内存上下文机制。内存上下文（MemoryContext）是PG里一套统一的内存管理抽象，负责把小块内存的分配、释放打包处理。每个上下文里创建的对象，在上下文销毁时会被统一释放，不需要程序员手工逐个清理。

动态哈希表在创建时，可以指定内存上下文。所有桶、段、目录都是从指定上下文里分配的。如果你在某个事务级上下文里创建一个临时哈希表，事务结束时上下文销毁，整个哈希表一起消失，不会漏内存。这对临时查询、排序、聚合等场景太友好了。

共享内存版的哈希表则不一样，它的内存来自共享内存池，生命周期与数据库实例一致，不能随会话或事务结束而自动清理。所以共享哈希表通常要注册回调函数，负责在停止时会话时清理残留项。

这个设计给应用层的启发是：无论什么语言，做一个缓存库时，最好让哈希表和区域内存池绑定，而不是让使用者在每次对象结束生命周期时手工释放。大多数业务层的缓存内存泄漏，根源就是忘了在生命周期边界释放哈希表里的对象。

在实现自己的哈希表时，我建议在创建对象时自动关联一个区域，区域销毁时自动清理哈希表，而不是暴露一堆destroy接口让调用者记得调用。这个模式在PostgreSQL里已经运行了几十年，经得住考验。

5. 常见问题与排查技巧实录

5.1 频发扩容引发的性能抖动

动态哈希表的性能问题里，最常见的就是扩容触发太频繁。现象是系统平时很稳，但每隔一段时间CPU使用率突然升高，接口延迟出现一个明显的尖峰，峰值过后又恢复。这种抖动如果周期性出现，先查哈希表的扩容次数。

排查步骤很直接。第一步，检查哈希表的初始桶数是不是远小于实际条目数。第二步，观察填充率，看长时间运行后填充率是不是一直在临界点附近徘徊。第三步，如果确认是扩容导致，把初始桶数增大到接近预期条目数1.5倍，并把fillfactor适当调高。

我在一个模拟项目X里遇到过这种情况。某服务启动后缓存表会快速增长，十几分钟内条目数从0涨到几十万，初始桶数给了4096，导致这段时间内几乎每秒都在扩容。后来把初始桶数调到200000，同时预热填充了前几万条数据，性能抖动就没了。

另一个有效手段是“错峰扩容”。如果你的场景能预测写入高峰，可以提前扩好桶，让扩容发生在低峰期。PG的dynahash内部没有这个调度，但应用层可以感知时机，主动执行一次扩容。缺点是PG没有暴露强制扩容的通用接口，你只能通过创建新表再迁数据的方式实现。所以，最省事的还是把初始值给对。

5.2 哈希冲突过高时的定位与处理

哈希冲突本身不是灾难，灾难是冲突率过高导致单个桶链太长。动态哈希表比静态表更抗冲突，因为它们能扩容，但如果键分布本身很烂，再多的桶也白搭。

定位冲突问题有一个土办法，就是抽样查桶长。在调试环境里，遍历所有桶，统计链长分布。正常情况绝大多数桶的链长应该不超过3，少数桶到5、6也正常，但如果大量桶的链长超过10，基本可以断定哈希函数有问题，或者键被处理的方式不对。

泄露一个PG源码里不太起眼但很重要的细节：动态哈希表的条目里会保存一份哈希值。当两个不同的键映射到同一个桶时，先比较哈希值，如果哈希值不同就直接跳过字符串比较或大整数比较，这样能大幅缩短查找时间。如果你的键是结构体，并且keysize包括了填充字节，比较时可能遇到“同一逻辑键有不同的字节表示”的问题，从而导致看起来是同一个键，哈希表里却出现了两个条目。排查方法是打印每个条目的键字节流，肉眼对比一遍，确认结构体定义里没有隐性填充。

哈希函数的选择也很关键。如果键是类似“user_12345”的字符串，直接让通用字符串哈希函数处理，效果通常很好。如果你自己改写哈希函数，一定要测试它的分布。一个很简单的自测方法是：取一批有代表性的真实键，模拟插入到不同桶数的哈希表里，看最大桶长和平均桶长。最大桶长超过平均桶长5倍就要警惕了。

另外，如果哈希表对外暴露，就要考虑恶意攻击风险。有人可能故意构造大量同哈希值的键，导致某个桶链特别长，这就是哈希洪水攻击。解决方法是给哈希函数加随机种子，让攻击者无法预测哈希结果。PostgreSQL的dynahash支持由创建者在初始化时指定种子，这个机制在生产环境一定要用起来。

5.3 迁移到动态哈希表时的参数推荐

如果你正在设计一个新的模块，想直接借鉴dynahash的思路，我以经验给出一组可落地的参数建议。

这里的初始桶数比例看起来很大，是因为桶本身的内存开销极小，而且PG做了一个优化：桶空间是按需分配的，初始桶数只影响目录和段指针数组的大小，不会一次性把所有桶的条目内存都分配出去。所以不用担心给大了浪费内存。关键是可以避免启动阶段的多次扩容。

fillfactor给0.8和0.9的区别，本质是在内存浪费和扩容频率之间取舍。如果你的数据增长比较平缓，建议0.9；如果数据增长很陡，可以考虑0.7，因为可以更快让哈希表腾出空间，只不过这么做的代价是早期就会触发几次扩容。

如果你要把现有静态哈希表换掉，迁移过程也有讲究。不要直接把静态表的大小参数照搬过来，因为动态哈希表不需要你“预留峰值空间”，你只需要按当前规模给初始桶数，后面的增长让它自己扩。迁移后，观察一周的CPU和内存曲线，重点看有没有周期性尖峰。如果尖峰消失且平均内存占用下降，说明这次迁移是划算的。

动态哈希表不是银弹。如果你的哈希表条目数量非常稳定，几天都不会变，静态哈希表依然是更优选择，因为它没有目录、段这些额外结构，内存布局更紧凑，缓存也更友好。动态的价值只在“规模不确定”时体现，如果不需要这种弹性，就不要付出动态的成本。这也解释了为什么PostgreSQL没有把所有哈希表都替换成dynahash，而是保留了两套方案，按需使用。

在我实际使用这套数据结构的过程中，最深的体会是：设计动态结构时，真正的难点不是“怎么扩”，而是“怎么让使用者感受不到扩的过程”。PostgreSQL做这件事的方式是分散扩容成本，用一点确定性的开销换取整体稳定性，这个思想本身比哈希表更值得借鉴。以后你在自研缓存、中间件或者各种需要动态增长的存储结构时，都可以回到这个设计里找答案。