企业官网建设流程全解析

地址映射表这个词，我最早是在一次性能问题排查里真正重视起来的。当时系统跑得好好的，某个模块一上量就开始出现随机崩溃，日志里全是莫名其妙的地址越界。顺着调用栈往里挖，最后问题落在了一张“地址翻译”的对照关系上——它把外设侧看到的地址和内存侧的地址对不上，中间少了一层映射登记。那之后我才明白，地址映射表看着像是最枯燥的基础设施，但它是所有“我访问 A 却实际落在 B”这类行为的总开关：内存管理里的页表是它，网络转发里的会话表是它，存储分片路由里那张哈希对照表也是它，DMA 场景里的地址翻译表还是它。很多人写业务代码时几乎不会直接碰它，可一旦要处理虚拟内存、零拷贝、内存池、跨设备数据搬运、分片集群路由，绕不开的就是先把这张表设计对。这篇内容我想从最底层的位运算讲起，一直讲到一套可以直接跑的简易多级映射表实现，中间穿插表大小估算、架构选型、缺页与大页取舍，以及我在真实排查里攒下来的坑。不管你是刚接触操作系统概念的学生，还是已经写了几年系统层代码、想把这套东西从头理顺的开发者，都能从这里挑到能直接用的东西。

1. 先搞清楚地址映射表到底在映射什么

1.1 同一个名字，四种完全不同的现场

“地址映射表”这个叫法太通用，通用到容易让人误会。我在不同场合听到它，指的东西至少有这么四类，先分清语境，后面讨论才不会打架。

第一类是虚拟地址到物理地址的映射，也就是页表。进程看到的是连续、独立、从某个基址开始的地址空间，真实内存条上的页框是零散分布、还被多个进程共享的。这张表的核心职责是“翻译”，顺带承担访问权限控制、脏页标记、存在位标记这些附加信息。

第二类是设备地址到内存地址的映射。外设做数据搬运时，它发出的地址可能不是物理地址，需要先经过一张表翻译成物理地址再落到内存。这张表除了翻译，更重要的是做边界约束——设备只能碰表里登记过的区域，越界直接拦住。这里的表项通常是以“区间”为粒度的，不是一页一页的。

第三类是网络会话侧的地址映射。内网一堆主机共用一个出口地址访问外部，返回的报文得知道该还给内网哪台机器、哪个端口。表里存的是一组五元组到另一组五元组的对应关系，带超时老化。

第四类是分布式存储或分片中间件里的路由映射。一个逻辑键该落到哪个分片、哪个节点，靠一张从键区间（或哈希槽）到节点标识的对照表。它不涉及内存地址，但“逻辑标识 → 物理位置”这个结构完全是同一套思路。

我后面主要拿第一类当主线来讲，因为它的位运算最硬、细节最多，把这套啃透了，其余三类基本是同一副骨架换层皮。但选型和排坑的章节我会把另外几类拉进来对照，因为很多设计上的坑是共通的。

1.2 为什么不能直接拿真实地址用

最朴素的想法是：既然最后都要落到物理内存，那干脆全程用物理地址，省掉翻译这一层。这个想法在单任务、无隔离、内存够用的年代确实成立过。但一旦出现下面任何一种需求，就必须插一层映射。

隔离需求。两个进程如果都用物理地址，那它们必须事先商量好各自用哪一段，谁先启动谁占便宜，第三个进程起来就可能没地方待。有了映射表，每个进程都以为自己从零开始拥有一整片连续空间，实际物理页由系统统一发放，互不干扰。

碎片问题。物理内存跑久了必然碎片化，找不到一段足够长的连续空间。而程序加载、栈增长、映射大块缓冲区这些操作，往往要求逻辑上连续。映射表能把零散的物理页拼成一段连续的逻辑区间，这是它最实用的价值之一。

共享与节省。同一份代码段被十个进程加载，物理上只该有一份。映射表可以让十个进程的不同虚拟地址指向同一个物理页框，只在表项里做引用计数。写时复制也是靠这张表实现的：先都指同一页并标只读，谁真写才复制一份。

按需分配。程序声称要申请 1GB 内存，实际摸到的可能只有几十 MB。映射表可以先把这 1GB 的地址区间登记成“存在但未分配”，真访问到某页时才去要物理页。这种“先承诺后兑现”的做法，是整个内存超额分配机制的基础。

权限控制。代码段可读可执行不可写，数据段可读写不可执行，这些属性全挂在表项里，由翻译硬件在每次访问时顺带检查。少了这一层，任何一次野指针都能改写代码段。

一句话概括：映射表不是为了“翻译地址”而存在，翻译只是它的手段；它真正的职责是把一段连续、独立、可控制的逻辑空间，嫁接在离散、共享、有限的物理资源之上。

理解了这一点，后面所有的设计取舍就都有了判断依据——每种结构选择，本质上都是在“表本身要占多少空间”“查表要几步”“修改表要多大代价”这三者之间做权衡。

2. 拆开一张映射表：位宽、粒度与表项

2.1 地址是怎么被切开的

映射表的最小单位是“页”（或者叫页框、块，叫法不同）。之所以不按字节映射，原因很直接：一个字节一个表项，表会比内存本身还大。以常见的 4KB 页为例，每 4096 字节才需要一个表项，压缩比是 1:512，这已经是很克制的开销了。

假设我们的逻辑地址是 48 位，页大小 4KB，那么地址天然被切成两段：

• 页内偏移：低 12 位。因为 2^12 = 4096，12 位刚好能索引一页里的每个字节。
• 页号：高 36 位。因为 48 - 12 = 36。

翻译过程就是：拿高 36 位去表里查，查到一个物理页框号，把物理页框号左移 12 位，再或上原来的低 12 位，得到物理地址。

这个偏移量永远不变，是映射表设计里最重要的一条性质。它意味着映射只改变“页”这一级，页内的相对位置原封不动。也意味着无论表做多少级、用什么结构，页内偏移都直接透传，不参与任何查表计算。

2.2 表项里塞了些什么

一个表项至少要有物理页框号，但实际落地时远不止这一项，通常还包括：

位宽之所以常常凑成 8 字节（64 位），一是为了对齐，二是 64 位里塞完上面这些还有富余，富余部分在实际系统里经常被软件层借用来存自定义信息，比如反向映射用的索引、页所属的内存区域编号。我在自己写的简易实现里就借用了几个保留位来存“这张页属于哪个内存池”，回收时不用再查别的结构。

这里有个容易忽略的点：表项宽度直接决定了表的大小。同样是 2^20 个表项，8 字节表项占 8MB，4 字节表项占 4MB。在页表这种每个进程都要一份的结构上，这个差距会被进程数放大。所以早期 32 位系统用 4 字节表项是有现实压力的，不是随手定的。

2.3 表到底会占多大：算一遍就心里有数

这是我在做方案评审时必做的一步。很多设计出问题不是逻辑错了，是从来没算过空间账。

以 48 位逻辑地址、4KB 页、8 字节表项、单级结构为例：

• 页号位数 = 48 - 12 = 36 位
• 表项数 = 2^36 ≈ 687 亿个
• 表大小 = 2^36 × 8B = 2^39 B = 512 GiB

结论很清楚：单级表在 64 位地址空间下完全不可行。512 GiB 只是一个地址空间的开销，每个进程都来一份，机器直接报废。这就是多级表存在的唯一理由——不是因为多级更优雅，而是因为单级在数学上就撑不住。

换成四级、每级 9 位索引的结构：

• 4 × 9 = 36 位，正好覆盖页号
• 每级表项数 = 2^9 = 512 个
• 每级表大小 = 512 × 8B = 4096B = 4KB，刚好一页

这个“每张表正好一页”不是巧合，而是设计时刻意凑出来的，目的是让表的分配和回收能复用物理页分配器，不必为页表单独搞一套内存管理。

再看实际占用。一个典型进程，代码段 2MB、堆 8MB、栈 8MB、若干共享库加起来 20MB 左右，总共约 40MB 逻辑空间。但它分散在地址空间的不同高处和低处，按四级结构算，顶层表 1 张必建（4KB），每覆盖一段 512GB 的区域才需要一张二级表，每覆盖 1GB 才需要一张三级表，每覆盖 2MB 才需要一张四级表。40MB 实际触及的区域通常只需要十几到几十张下级表，总占用在几十 KB 到几百 KB 量级。

从 512 GiB 到几百 KB，这就是“按需分配 + 多级索引”带来的差距。稀疏访问模式下，多级结构的空间效率是压倒性的。

提示：做任何映射表设计前，先列出三个数——地址位宽、最小映射粒度、表项字节数。这三个数一乘一除，可行不可行立刻就清楚了，别等写完代码才发现表比数据还大。

3. 结构选型：单级、多级、反向、哈希怎么挑

3.1 单级直接索引：简单到极致，也浪费到极致

单级表就是拿页号直接当数组下标，一次访存就能拿到表项。查找复杂度 O(1)，没有任何多余计算，实现起来二三十行代码。

它的适用边界非常明确：地址空间小，或者映射密度极高。比如一个 32 位嵌入式系统，地址空间 4GB，页大小 4KB，页号 20 位，表项 4 字节，一张表 4MB。如果这个系统里映射基本是满的，4MB 的表换 O(1) 查找是很划算的。但如果只映射了 8MB 内存，为了这 8MB 掏 4MB 的表，性价比就崩了。

我见过一个更极端的反例：某次做一个数据采集模块，地址空间只有 16 位，有人照搬了通用做法用了两级表，结果每次采样都要多走一次访存，中断响应时间被拉长了。这种小空间、全映射的场景，单级反而更对。

判断标准很简单：表项数 × 表项大小 是否接近 实际映射数据量。接近就用单级，差着数量级就上多级。

3.2 多级索引：用访存次数换空间

多级表的核心思想是把一个大数组拆成树。顶层表项的“物理页框号”位置存的不是数据页，而是下一级表的地址。只有某一级真的被用到了，才去分配下一级。

代价是查找路径变长。四级表在一次翻译里要串行访存四次，如果每次都打到物理内存，延迟会非常难看。这也是为什么真实系统一定要配一个缓存来兜住这几步——后面第 5 章细讲。

级数怎么定？常见的做法是让每级索引位数大致相等，且每张表正好一页。上面算过，48 位地址、4KB 页、8 字节表项下，4 级 × 9 位是自然解。如果页大小改成 16KB，页内偏移 14 位，页号 34 位，那可能就变成 4 级但索引位数不均，或者换成别的组合。级数不是拍脑袋定的，是被“每张表一页”这个约束反推出来的。

有一个折中做法值得提：不要求每级等宽。可以让顶层索引位数少一些（比如 4 位，16 个入口），下面几级多一些。这样顶层表只有 128 字节，进程一多，省下来的顶层表空间很可观。代价是某些分支会更深，但实际访问模式往往集中在少数区域，收益通常大于损失。

3.3 反向映射与哈希表：为“反查”而生

前面两种都是“逻辑地址 → 物理地址”的正向结构。但有一类需求是反过来的：物理页被换出时，得知道有哪些虚拟地址指着它，好把这些表项全部失效。正向表做这件事要遍历整个地址空间，代价不可接受。

反向映射表就是为此设计的：以物理页框号为索引，每个页框挂一条链，链上记录所有指向它的虚拟地址。换出一个页，顺着链走一遍就能精准失效。

缺点也很明确：正向查找变慢了，因为不能直接用页号索引，得靠哈希。所以反向映射很少单独使用，常见的组合是正向用多级表保证查找速度，反向用哈希链保证换出效率，两套结构并存，靠表项里的一个字段互相指向。

哈希结构在另外三个场景里反而是主力：网络会话映射、分片路由、设备地址区间映射。这些场景的共同点是映射条目数远小于地址空间，且访问无局部性规律。用哈希桶做 O(1) 平均查找，配合链表或开放寻址处理冲突，比树形结构实在得多。

3.4 四种结构的横向对照

选型时我最常问三个问题：映射条目大致有多少？访问是顺序还是随机？有没有反查需求？这三个答案基本就锁定结构了。

举个路由表的具体例子。假设有 1024 个分片槽位，集群节点数在 10 到 100 之间浮动。用数组直接索引（1024 个元素，每元素存节点 ID）是最简单的，占几 KB，查找一次到位。但如果节点数会动态扩缩容，槽位到节点的对应关系需要频繁重算，那就适合在数组之外再维护一张“节点 → 槽位区间列表”，扩缩容时只动区间边界。这时候数组是正向表，区间列表就是反向表，两者配合，扩容时不需要搬迁全量数据，只挪边界附近的一小部分。

4. 动手实现一套可运行的多级地址映射表

4.1 先定参数，再动代码

理论讲完，写一套能跑的东西验证一遍，理解会扎实很多。为了让位运算的过程完全可见，我用 Python 实现，参数选常见的 48 位地址、4KB 页、四级表、每级 9 位索引。真实系统当然是用硬件完成的，这里只是把逻辑摊开。

先把参数和环境定死：

PAGE_SHIFT = 12 # 页内偏移 12 位，页大小 4KB PAGE_SIZE = 1 << PAGE_SHIFT # 4096 INDEX_BITS = 9 # 每级索引位宽 LEVELS = 4 # 四级 PTE_SIZE = 8 # 表项字节数，仅用于空间估算 VA_BITS = 48 MASK = (1 << INDEX_BITS) - 1 # 0x1FF assert PAGE_SHIFT + INDEX_BITS * LEVELS == VA_BITS, "参数不匹配"

那行断言不是摆设。我踩过一次坑：中途把页大小从 4KB 改成 8KB，改了 PAGE_SHIFT 却忘了调级数，结果高位地址直接被截断，映射到了一个完全无关的区域，表现出来就是“写进去了但读出来是旧值”，查了大半天。这种参数之间的耦合关系，一定要用断言钉死。

4.2 地址切分：一行代码说清四级索引

把 48 位地址拆成四段索引和一个偏移，本质上就是反复右移再取低位：

def split_va(va): """返回 (偏移, [l4, l3, l2, l1])，l4 为顶层索引""" offset = va & (PAGE_SIZE - 1) rest = va >> PAGE_SHIFT idx = [] for _ in range(LEVELS): idx.append(rest & MASK) rest >>= INDEX_BITS idx.reverse() return offset, idx def compose_pa(pfn, offset): return (pfn << PAGE_SHIFT) | offset

跑一下看看。取va = 0x0000_7f3a_1b2c_4000：

• 偏移 =0x4000 & 0xFFF=0x000
• 页号 =0x7f3a1b2c4
• 拆出来是[0x1F8, 0x1D0, 0x1EC, 0x2C4]（具体数值以实际运行为准，重点是四段都在 0 到 511 之间）

这四段就是你后续逐层下探的路径。第一段决定顶层表里看哪个槽，第二段决定二级表里看哪个槽，依此类推。这个过程没有任何“位置相关”的魔法，纯粹是位切片，所以它才敢放在每次访存的关键路径上。

4.3 表结构与按需分配

用类来模拟每级表，只在真正需要时才创建下级：

class Table: __slots__ = ("slots", "refcnt") def __init__(self): self.slots = {} # 索引 -> 下级 Table 或叶子 PTE self.refcnt = 0 class AddrMap: def __init__(self): self.root = Table() self.table_count = 1 self.page_count = 0 self.log = [] # 记录映射关系，用于反查 def _walk_create(self, idx): """按索引路径逐级创建表，返回最后一级表""" t = self.root for i in range(LEVELS - 1): k = idx[i] nxt = t.slots.get(k) if nxt is None: nxt = Table() t.slots[k] = nxt self.table_count += 1 self.log.append(("new_table", i + 1, k)) t = nxt return t

这里有个设计细节值得多说两句。slots用了字典而不是定长列表，是为了省内存——真实硬件里必须用定长数组，因为要靠偏移量直接寻址，不能查哈希。我在这个模拟实现里用字典纯粹是为了让“空槽位不占空间”这件事更直观。真要贴近硬件，应该换成 512 元素的定长列表，未创建时填None。两种写法在逻辑上等价，只是空间模型的差别。

映射与解除映射：

def map(self, va, pfn, flags=0x7): assert va % PAGE_SIZE == 0, "地址必须页对齐" _, idx = split_va(va) t = self._walk_create(idx) leaf = idx[-1] if leaf in t.slots: raise ValueError(f"重复映射: {va:#x}") t.slots[leaf] = {"pfn": pfn, "flags": flags, "va": va} self.page_count += 1 return True def translate(self, va): offset, idx = split_va(va) t = self.root for i in range(LEVELS - 1): t = t.slots.get(idx[i]) if t is None: return None pte = t.slots.get(idx[-1]) if pte is None: return None return compose_pa(pte["pfn"], offset), pte["flags"]

map里那个va % PAGE_SIZE == 0的断言也别省。页内偏移是不参与翻译的，如果允许非对齐地址进表，你等于默认了“页内也能重映射”，逻辑上就自相矛盾了。实际项目里这种宽松处理最后一定会咬人。

4.4 解除映射与空表回收

写操作里最容易漏的是回收。解除映射只删叶子表项，上面几级表如果空了却没释放，跑久了表的数量会单调上涨，表现出来就是“内存一直缓慢增长但业务量没变”。

def unmap(self, va): offset, idx = split_va(va) path = [self.root] t = self.root for i in range(LEVELS - 1): t = t.slots.get(idx[i]) if t is None: return False path.append(t) leaf = idx[-1] if leaf not in t.slots: return False del t.slots[leaf] self.page_count -= 1 # 自底向上回收空表 for depth in range(LEVELS - 1, 0, -1): parent = path[depth - 1] child = path[depth] if child.slots: break del parent.slots[idx[depth - 1]] self.table_count -= 1 return True

回收必须自底向上，一旦发现某级表还有条目就立刻停手。反过来从顶往下删，会把还有内容的子树整个丢掉，这种错误在测试里往往不显现，因为下次访问就直接返回未映射了，看起来像“页没分配”，实际是数据丢了。

验证一下：

m = AddrMap() base = 0x7f3a_1b2c_4000 for i in range(100): m.map(base + i * PAGE_SIZE, 0x1000 + i) print("表数量:", m.table_count) # 4 级下 100 页约需 5 张表 print("页数量:", m.page_count) # 100 print(m.translate(base + 3 * PAGE_SIZE)) for i in range(100): m.unmap(base + i * PAGE_SIZE) print("回收后表数量:", m.table_count) # 应回到 1，只剩顶层

100 页连续映射大约会创建 5 张表而不是 400 张，这就是共享上级路径的效果。连续、连续的访问模式对多级表非常友好；如果改成 100 个散布在地址空间各处的页，表数量会涨到接近 400 张。这一点在做性能建模时很关键：表的内存开销取决于地址的分散程度，而不是映射了多少页。

4.5 加一层缓存和位图管理

模拟硬件缓存（TLB）只需要一个固定容量、带淘汰的字典：

from collections import OrderedDict class SimpleTLB: def __init__(self, capacity=64): self.cap = capacity self.d = OrderedDict() self.hit = 0 self.miss = 0 def lookup(self, vpn): if vpn in self.d: self.d.move_to_end(vpn) self.hit += 1 return self.d[vpn] self.miss += 1 return None def insert(self, vpn, pfn): if vpn in self.d: self.d.move_to_end(vpn) self.d[vpn] = pfn if len(self.d) > self.cap: self.d.popitem(last=False) def invalidate(self, vpn): self.d.pop(vpn, None)

加进translate之后，命中率立刻能测。我在本地跑一百页顺序访问，64 项缓存的命中率接近 0——顺序访问每一步都是新页号，缓存根本兜不住。换成同一批页反复访问，命中率立刻上到 90% 以上。这就是为什么缓存对大块顺序搬运帮助有限，对热点数据访问帮助巨大，两种负载要用不同的优化思路。

物理页框的分配用一个位图就够了：

class PageAllocator: def __init__(self, total): self.total = total self.bitmap = bytearray((total + 7) // 8) self.next_hint = 0 def _test(self, i): return self.bitmap[i >> 3] & (1 << (i & 7)) def _set(self, i, val): if val: self.bitmap[i >> 3] |= (1 << (i & 7)) else: self.bitmap[i >> 3] &= ~(1 << (i & 7)) def alloc(self): start = self.next_hint for k in range(self.total): i = (start + k) % self.total if not self._test(i): self._set(i, 1) self.next_hint = (i + 1) % self.total return i raise MemoryError("物理页耗尽")

next_hint这个游标看着可有可无，但它把连续分配的复杂度从每次都从头扫，降到了基本 O(1)。我一开始省了这个字段，结果压测时分配函数占了一半的 CPU 时间——每次都从 0 号位开始找空闲位，前面的位全占满了，等于每次都在做无用遍历。加个游标就解决了，这类小优化在内存分配器里非常常见。

5. 周边机制：缓存、缺页与大页的取舍

5.1 缓存不是加速器，是必需品

多级表最直接的代价就是访存次数。四级表意味着一次数据访问要额外走四次表访问，总访存从 1 次变成 5 次，理论性能直接降到五分之一。如果每次翻译都真的去内存取表项，多级结构根本没法用。

缓存的本质是把“最近用过的页号到页框号”这条对应关系存在一个极快的小表里。它的命中依赖地址访问的空间局部性——同一页内的连续访问共用同一个页号，缓存只需要记住一次。一个 4KB 的页，只要访问落在里面，几千次访存只需要一次翻译。

这也解释了为什么页大小对性能影响这么大。页从 4KB 变成 2MB，同样大小的缓存能覆盖的逻辑地址范围扩大 512 倍，命中率会显著提升。代价是页内碎片变多，一个只用了 8KB 的小对象独占一个 2MB 页，浪费接近 2MB。

5.2 缺页处理是一条完整链路

缺页不是错误，是正常流程。一次访问的表项存在位是 0，硬件触发异常，进入处理程序。处理程序要做的事按顺序大致是：

1. 判断这个地址是否合法（有没有超过进程允许的范围）。不合法就是真正的访问越界，直接终止。
2. 判断页是否已经分配但被换出。如果是，从外部存储读回，更新表项的页框号和存在位。
3. 如果是从未分配过的匿名页，取一个空闲页框，清零，建立映射。
4. 如果访问类型是写而页是只读（写时复制），复制一份新页，改映射并置可写。
5. 更新缓存，必要时刷新相关条目，返回用户态重新执行那条指令。

这条链路上最容易出问题的是第 5 步。更新了表项但忘了让缓存里的旧条目失效，程序会继续用旧的翻译结果，出现“数据写到了旧位置”这种极难定位的现象。我踩过一次：页迁移之后忘了失效缓存，读出来的值还是迁移前的，两处数据开始各走各的，最后是靠对比两份内容才定位到。

5.3 大页：什么时候值得用

大页的价值不只是减少缓存压力，还能直接减少表的层数。一个 2MB 的大页，在四级结构里可以让最低一级直接变成叶子，少走一层。

但大页不是万能药，判断标准我通常看这三条：

• 这块内存的访问是长时间连续、大范围的（比如大数组、图像缓冲区、网络收发环形队列）。
• 这块内存的生命周期长且稳定，不会频繁申请释放，否则大页的分配成功率会很难看。
• 系统里大页池有预留，现要现抢往往抢不到。

反过来，小对象密集、频繁创建销毁的场景用大页就是灾难。一个几十字节的临时对象占掉 2MB，几百个这样的对象就把内存吃光了。这种场景老老实实用小页，靠缓存命中率来补。

6. 现场踩坑与排查速查

6.1 五类高频故障的识别特征

把我在实际项目里遇到过的问题归归类，大概能覆盖八成的现场情况。

第一类：越界访问没被拦住。典型现象是程序写坏了一块不属于它的内存，崩溃点却在很远的地方。根因通常是映射表的边界检查缺失，或者表项的权限位没设对。设备侧映射尤其容易出这个问题——翻译逻辑只做了地址转换，没做区间校验。

第二类：翻译结果正确但数据是旧的。十有八九是缓存没失效。判断方法很直接：读一次原始表项，看它和缓存里的值是否一致，不一致就是失效漏了。

第三类：内存缓慢增长。解法是先统计表的数量，而不是先看数据量。如果表数量随运行时间单调上涨、业务量平稳，那就是空表没回收，或者反向映射链上的节点没摘干净。

第四类：映射冲突导致覆盖。两个不同的逻辑地址映射到同一个物理页，一方写另一方被改。这种 bug 的症状是数据“随机”变化，实际上是被确定的一方覆盖了。查法是建立一张物理页到逻辑地址的反向索引，发现一个物理页对应多个不该共享的逻辑地址就能立刻抓到。

第五类：并发下映射状态不一致。一个线程在改表，另一个在查表，中间态被读到。要么加锁，要么用副本替换的整体切换方式。我倾向于后者，因为映射表读多写少，让读路径完全无锁收益很大。

6.2 排查速查表

6.3 几条不那么显然的经验

别在映射表里用动态结构。这话不是说不能用树，而是说表本身的内存布局要尽量固定、可预测。用链表串表项，每访问一次就可能多一次指针跳转，缓存全被跳没了。定长数组加索引，即使浪费一些空间，访存行为也友好得多。

权限位要有缺省值，而且缺省值要是最严的。我习惯让所有新建表项的权限默认全是关闭，由调用方显式打开需要的位。反过来做成默认全开，一次遗漏就是一个可被改写的代码段。

统计信息比断点好用。排查映射问题时，断点几乎帮不上忙，因为问题往往在很早以前就埋下了。我一般常驻几个计数器：当前表数量、映射页数、缓存命中率、缺页次数、回收表次数。这五个数一起看，问题的方向基本能锁定。

用物理页反查代替逐段扫描。需要知道“某块物理内存被哪些逻辑地址引用”的时候，别去遍历整个映射树，维护一张从物理页号到逻辑地址列表的索引，代价是每次映射多一次写入，收益是查询从 O(地址空间) 降到 O(引用数)。这个取舍在内存紧张时可能不划算，可以做成可开关的调试特性，只在排查期打开。

先画出地址布局图再写代码。我现在的习惯是动手前先在纸上把逻辑地址空间按区域切好——代码段在哪、堆从哪长、栈从哪往下降、共享库放在哪一段。地址布局一乱，映射表的表数量会成倍上涨，性能却找不到直接原因。

这个内容后续还能往两个方向延展。一个是把它和真实硬件的翻译机制对上，看看每一级访存在硬件里是怎么被缓存、怎么被并行化的；另一个是把它挪到网络或存储的路由场景，用完全相同的位切片和查表思路去做分片寻址，你会发现除了表项字段不同，骨架几乎是同一套。我自己在做跨设备数据搬运的模块时，就是把内存那套映射抽象直接搬过去，只换了粒度定义和失效策略，省了大量重复设计。