企业官网建设流程全解析

🔥个人主页：杨利杰YJlio

❄️个人专栏：《Sysinternals实战教程》 《Windows PowerShell 实战》 《WINDOWS教程》 《IOS教程》

《微信助手》 《锤子助手》 《Python》 《Kali Linux》

《那些年未解决的Windows疑难杂症》

🌟让复杂的事情更简单，让重复的工作自动化

《Windows Internals》10.1.26 Registry performance and optimization：为什么注册表后面的优化重点，已经从“能不能存”变成了“怎样在大 hive、碎片、热键分布和缓存命中之间把启动和运行时性能再往上推”？》

学到《Windows Internals》10.1.26 Registry performance and optimization这一节时，我最大的感受是：

Windows 对注册表的优化重点，早就不是“这棵树能不能放进去”，而是“这棵树怎么放、怎么找、怎么重组、怎么命中缓存，才能让启动和运行都更快”。

前面我们已经知道，注册表不是一个“大文件”，而是一组 hive；hive 内部又不是平铺结构，而是 block、bin、cell、cell map 这种分层存储。继续往下走，Windows 又进一步暴露出一层非常“工程化”的思路：

• hive 会碎片化，所以需要reorganization
• key 的冷热分布不同，所以需要把hot keys / cold keys重新排布
• 安全描述符大量重复，所以需要共享
• key 名称和 KCB 如果都存完整路径，会浪费很多内存，所以要做去重与缓存
• 打开过、刚关闭的 key，如果又被很快重新访问，就没必要每次从零做查找，所以要有cache table和delayed close table。

所以这篇文章，我就把10.1.26 Registry performance and optimization讲透。
这一节最核心的一句话就是：

注册表性能优化的本质，不是“再快一点点”的小修小补，而是把 hive 的物理布局、key 的冷热分布、名称与安全描述符的存储方式、以及 KCB 的缓存命中路径一起优化，最终把启动和运行期的真实访问成本压下去。

1. 先说结论：注册表优化的主线，已经从“能存”变成了“怎么更快地被读到”

如果只用一句话总结这一节，我会这样说：

Windows 后面对注册表做的优化，几乎都围绕一个目标：让真正会被访问的数据，更快、更紧凑、更省内存地被找到。

为什么我会这样理解？

因为书里这部分内容很明显分成两大块：

• Hive reorganization
• Registry optimizations。

前一块解决的是：

• hive 碎片
• 热点 key 分布
• 启动期和运行期读盘成本

后一块解决的是：

• 重复安全描述符
• 字符串存储膨胀
• KCB 路径冗余
• 查找路径过长
• recently closed keys 重开太慢

也就是说：

前者更偏“磁盘布局优化”，后者更偏“内存与查找路径优化”。

2. 为什么 hive 会越来越慢？因为它和真实文件系统一样，也会碎片化

这一节里最值得先理解的，是hive reorganization的出发点。

书里明确说：

• hive 在长期运行中会出现fragmentation problems
• 当 bin 里的 cell 被释放，但又无法连续合并时，就会形成很多零散的 free space
• 如果没有足够连续的空闲空间放新 cell，系统就只能在 hive 文件尾部继续追加新 bin
• 这样一来，旧的碎片空间很少再被高效利用。

这其实和磁盘碎片是一个非常像的逻辑：

• 删除并不会自动让整个布局重新变漂亮
• 新数据往往更容易往后追加
• 结果就是越来越“散”

也就是说，hive 的问题从来不只是“有多大”，而是：

大了以后，它是不是还保持了足够好的连续性和可局部命中性。

3. Windows 8.1 为什么开始做 hive reorganization？因为碎片会直接拖慢真实访问

书里明确提到：

• 从 Windows 8.1 开始

• 每次 Configuration Manager 挂载 hive 文件时

• 都会检查是否需要执行reorganization

• 条件包括：

  • hive 不是 volatile
  • 有有效 log files
  • 距离上次 reorganization 已超过7 天。

这说明微软并不是把 hive reorganization 当成“偶尔人工整理”的附加功能，而是把它正式纳入了系统维护周期。

3.1 为什么不是每次都重组？

因为 reorganization 本身也是有成本的。
所以系统只在满足这些条件时再做：

• 需要有恢复能力保障，也就是 valid logs
• 不能是 volatile hive
• 而且要拉开周期，避免过于频繁。

3.2 重组的两个目标是什么？

书里直接给了两个目标：

• shrink the hive file
• optimize it。

一句话解释就是：

既要把 hive 变小，也要把 hive 变顺。

4. hive reorganization 到底是怎么做的？不是“原地整理”，而是“克隆一份更干净的新 hive”

这一段特别值得记，因为它很能体现 Windows 的工程风格。

书里说得很清楚：

• 重组不是在原 hive 里“原地挪来挪去”
• 它会先创建一个新的空 hive
• 这个 clone 和原 hive 结构一致，但一开始不带任何 cells
• 然后把原 hive 的root key以及它的 values 复制过去
• 接下来再由一个复杂算法去分析 child keys，决定复制顺序。

这意味着：

Windows 这里不是在旧布局上打补丁，而是干脆重建一份更合理的新布局。

这套思路其实特别稳，因为“重建”往往比“原地搬迁”更容易得到真正紧凑的结果。

所以 hive reorganization 的本质，更像“生成一个更好的新 hive”，而不是“给旧 hive 做按摩”。

5. 真正高级的地方：Windows 不是乱排 key，而是按“热度”和“运行阶段”排序

这一节最有意思、也最有价值的内容，我觉得就是hot/cold keys这部分。

书里明确说：

• Configuration Manager 在正常运行期间，会记录某个 key 是否被访问过

• 如果访问过，还会记下它对应的当前运行阶段索引

• 这个运行阶段主要区分为：

  • Boot
  • normal。

然后 reorganization 算法会按顺序复制这些 key：

1. 先复制 normal execution 阶段访问过的 keys
2. 再复制 boot phase 访问过的 keys
3. 最后复制自上次重组以来从未访问过的 keys。

5.1 这意味着什么？

这意味着 Windows 不是在做“平均优化”，而是在做：

基于真实访问模式的布局优化。

也就是说，系统知道：

• 哪些 key 热
• 哪些 key 冷
• 哪些 key 在启动期重要
• 哪些 key 只在正常运行期频繁访问
• 哪些 key 干脆几乎没人碰。

5.2 为什么这会直接影响性能？

因为重组后，书里说得非常明确：

• 不同类别的 key 会被放进big contiguous chunks
• 这样能让boot和runtime阶段读取注册表数据时都更快。

这其实很好理解：

热数据更集中、连续性更高，磁盘和内存访问局部性都会更好。

6. 为什么说这不是“碎片整理”，而是“带访问画像的碎片整理”？

如果只说“reorganization 会减少碎片”，那还没有抓到最值钱的部分。

更准确地说，这是一种：

带访问画像的 hive 重建。

书里明确提到：

• 重建后的新 hive，自然就是非碎片化的
• 因为 cell 会被顺序写入，新的 bin 只会继续追加到文件尾部
• 更重要的是，新 hive 里还会形成明显的hot / cold classes of keys的连续区域。

这说明 Windows 不只是想“把空洞填平”，而是想做到：

• 热 key 聚在一起
• 冷 key 也归在一起
• 真正高频路径读起来更顺。

所以 10.1.26 这一节真正的关键词，不只是 defrag，而是 profile-guided optimization。

7. Defrag 信息为什么会写进HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager\Defrag？

书里在这里还给了一个特别实用的点：

• reorganization 运行结果会被记录到：
  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager\Defrag

• 示例里甚至能看到：

  • 上次重组运行日期
  • 节省了多少 MB 的碎片空间。

这意味着什么？

意味着 Windows 不只是“默默优化”，它还会把一部分结果显式记录下来。
这对学习和排障都很有帮助，因为你至少知道：

• 系统有没有做过 hive reorganization
• 大概什么时候做的
• 这次收益有多大。

这就是很典型的 Windows 风格：内部自动优化，同时给你留下一点可验证痕迹。

8. 注册表优化不只在“布局”，还在“去重”：为什么安全描述符要共享？

到了Registry optimizations这一节，书一开头讲的就是security descriptor sharing。

书里明确说：

• 几乎每个 registry key 都带有安全描述符
• 如果每个 key 都单独存一份完整副本，会非常低效
• 因为同样的安全设置经常会作用在整棵子树上
• 所以 Configuration Manager 会在同一 hive 内维护一个唯一安全描述符池
• 新 key 需要应用安全时，会先查这个池
• 如果已经有一样的，就直接共享
• 这样就保证：
  在同一 hive 内，每一种唯一安全描述符最多只保留一份。

8.1 这说明什么？

这说明 Windows 很清楚：

注册表里很多“看起来是每个 key 自己一份”的东西，实际完全没必要重复存。

这是一种非常典型的空间优化思路：

• 同值去重
• 子树复用
• 降低 hive 体积。

所以安全描述符共享，本质上是在拿“结构上的相似性”换存储效率。

9. 名称存储也在优化：为什么明明是 Unicode 注册表，Windows 还要把纯 ASCII 名字按 ASCII 存？

这一点特别能体现 Windows 的“能省就省”。

书里明确说：

• 注册表是完全 Unicode-capable 的
• 名称规范上也都按 Unicode 定义
• 但如果某个 key 或 value 的名字只包含ASCII 字符
• Configuration Manager 就会在 hive 里按ASCII form存储
• 只有读出来做名字查找时，才在内存里转成 Unicode
• 这么做能显著减小 hive 大小。

9.1 为什么这看起来有点“别扭”却很合理？

因为从逻辑语义上看，Windows 仍然承认：

• 注册表名字是 Unicode 语义

但从物理存储上看，它又很务实：

• 如果你这名字本来全是 ASCII
• 那我就没必要浪费双字节空间。

也就是说：

Windows 这里把“逻辑表示”和“物理存储”再次分开了。

这和前面我们学到的很多设计是一脉相承的：

• 路径逻辑和真实来源可以分开
• 逻辑树和 hive 内部结构可以分开
• 逻辑 Unicode 和实际存储编码也可以分开

10. KCB 为什么不存完整路径？因为那会把内存浪费得非常夸张

这一节里另一个特别值得记住的点，是KCB 路径精简。

书里说得非常清楚：

• 为了最小化内存使用
• key control block（KCB）并不保存完整注册表路径
• 它只引用当前 key 自己的名字
  例如：
  \Registry\System\Control
  对应的 KCB 只会引用Control
• 更进一步，Configuration Manager 还会使用key name control blocks
• 所有同名 key 的 KCB 可以共享同一个名字控制块。

10.1 这说明什么？

说明 Windows 非常清楚，KCB 是高频、常驻、很热的一层对象。
如果每个 KCB 都存一份完整路径，那内存浪费会非常夸张。

所以它做了两层优化：

1. 只存局部名字，不存全路径
2. 同名再做共享。

10.2 为什么这特别重要？

因为 KCB 本身就是后面查找命中和缓存性能的关键。
如果 KCB 又大又臃肿，那缓存本身就会变得更低效。

也就是说，KCB 的瘦身不只是省内存，更是在给后续缓存命中效率做铺垫。

11. 真正决定“快不快”的关键：为什么 Configuration Manager 要上 hash table、cache table、delayed close table？

这一段是整节最有“性能优化”味道的地方。

书里明确提到三层优化：

11.1 key name control blocks 放进 hash table

为了快速查名字，Configuration Manager 会把 key control block names 存进hash table。

这意味着：

• 同名共享不只是省空间
• 还要配合快速查找

11.2 cache table：频繁访问的 KCB 放进热点缓存

书里说：

• 为了快速访问 key control blocks
• Configuration Manager 会把经常访问的 KCB 放到cache table
• 这个 cache table 也是hash table
• 需要查 KCB 时，会先查这个 cache table。

这就是最标准的热点缓存逻辑：

先问缓存，不行再走更重的查找。

11.3 delayed close table：刚关掉的 key 先别急着彻底扔

书里还说：

• Configuration Manager 还有一个delayed close table
• 它专门存放那些应用刚关闭的 KCB
• 这样如果应用很快又重开同一个 key，就能更快命中
• 这个表按最近关闭优先，旧的会被逐渐移走。

这一点特别实用，因为现实里很多程序就是会反复：

• 打开一个 key
• 查几个值
• 关掉
• 很快又打开同一个 key

如果每次都从零做，那就很浪费。

所以 delayed close table 的本质，是把“刚用过、马上可能还会再用”的那批 key 再留一会儿。

12. 为什么这些缓存是“按 hive 分开存”的？因为访问局部性本来就更像 hive 内热点

书里在最后还点了一个非常值得注意的细节：

• 这些 cache tables
  比如 cache table、delayed close table
  都是for each hive存放的。

这说明 Configuration Manager 并没有简单做一个全局大缓存，而是更偏向：

每个 hive 自己维护自己的热点对象集合。

我觉得这特别合理，因为从访问局部性上看，本来就经常是：

• 某类服务主要打SYSTEM
• 某类应用主要打SOFTWARE
• 某个用户行为主要打HKCU对应的 user hive

所以按 hive 划分缓存，更符合真实访问模式。

这再次说明 Windows 在注册表优化里，不只是“会缓存”，而是“按真实访问分布去缓存”。

13. 从桌面支持和系统学习视角，这一节到底有什么现实价值？

很多人会觉得 performance and optimization 偏理论。
但我觉得它特别有现实价值，尤其是下面这些理解。

13.1 它帮我真正理解“为什么大 hive 不一定天然慢”

慢不慢，不只取决于大小，还取决于：

• 是否碎片化
• 热 key 是否集中
• 名称和安全描述符是否重复膨胀
• KCB 缓存是否命中。

13.2 它帮我理解“为什么同样是注册表访问，有时很快，有时很慢”

因为中间可能差了：

• cache table 是否命中
• delayed close table 是否命中
• 路径对应 key 是否已经有 KCB
• hive 本身是不是已经被重组得更利于当前阶段访问。

13.3 它帮我理解启动和运行期为什么都和注册表布局有关系

书里已经明确说，reorganization 之后：

• hot / cold classes 的 key 会被放进大块连续区域
• 这会让boot和runtime两个阶段都更快。

13.4 它帮我建立一个更成熟的系统观

以前可能只会说：

• 注册表是存配置的

现在会更自然地说：

• 注册表还是一个需要长期优化布局、控制重复、提高缓存命中率的专用存储/查找系统

14. 最容易误解的 7 个点，我帮你一次理顺

14.1 误区一：注册表优化就是“清理无用项”

不对。
这节讲的核心不是“删垃圾”，而是布局优化、去重、缓存和查找路径优化。

14.2 误区二：hive reorganization 只是简单压缩文件大小

也不对。
它除了 shrink hive，还会根据 key 的访问热度重新排布，以优化启动和运行期读取。

14.3 误区三：只要碎片少了，启动就一定快

不完全对。
真正更值钱的是：

• 非碎片化
• 热 key 连续
• 运行阶段分类重排
  这三者一起起作用。

14.4 误区四：每个 key 都有自己独立完整的安全描述符副本

不对。
Configuration Manager 会在同一 hive 内共享唯一安全描述符。

14.5 误区五：注册表名字既然是 Unicode，就一定按 Unicode 存

不对。
纯 ASCII 名称在 hive 里会按 ASCII 形式存储，以减小体积。

14.6 误区六：KCB 里一定保存完整路径

不对。
KCB 只引用当前 key 名，而且同名 key 还能共享 key name control block。

14.7 误区七：key 一旦关闭，相关缓存就立刻毫无意义

不对。
delayed close table 恰恰就是为了利用“刚关闭还可能很快再打开”的现实访问模式。

15. 我的学习理解：这一节真正教会我的，是“注册表性能从来不是单点问题，而是布局、热度、去重和缓存共同作用的结果”

我觉得10.1.26 Registry performance and optimization最有价值的地方，不是让我记住几个“优化点”，而是让我真正明白：

Windows 对注册表做性能优化，从来不是抓一个指标猛拧，而是多个层次一起发力。

比如：

• 碎片多了，就重建 hive 布局
• 热 key / 冷 key 分开排布
• 安全描述符重复，就做共享
• 名称全是 ASCII，就别浪费 Unicode 存储
• KCB 别存完整路径
• 热 key 的 KCB 放 cache table
• 刚关掉的 KCB 先放 delayed close table。

这让我越来越强烈地觉得：

注册表不是“配置树”这么简单，它本质上已经是一套会根据真实访问模式不断自我优化的小型专用数据系统。

16. 总结提升

如果让我用一句话总结《Windows Internals》10.1.26 Registry performance and optimization，我会这样说：

Windows 对注册表的优化重点，已经从“能不能把 key 和 value 存下去”，转向了“怎样把 hive 做得更紧凑、把热 key 摆得更顺、把重复信息压得更少、把 KCB 命中路径做得更短”，从而同时提升系统启动期和运行期的真实访问效率。

这篇最值得记住的 10 个结论是：

1. hive 会像文件系统一样发生碎片化，Windows 8.1 起会在挂载时检查是否需要 reorganization。
2. reorganization 的两个目标是 shrink hive file 和 optimize it。
3. Windows 会记录 key 是否被访问，以及访问发生在 Boot 还是 normal 阶段。
4. 重组时会先复制 normal 阶段访问过的 key，再复制 boot 阶段访问过的 key，最后才是未访问 key。
5. 这样会把 hot / cold classes 的 key 放进连续大块区域，从而加快启动与运行期读注册表。
6. 重组结果会记录到HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager\Defrag。
7. Configuration Manager 会在同一 hive 内共享唯一安全描述符，避免为每个 key 存一份重复副本。
8. 纯 ASCII 的 key/value 名称会按 ASCII 形式存储，以减小 hive 大小。
9. KCB 不存完整路径，而只引用当前 key 名；同名 key 还能共享 key name control block。
10. cache table 和 delayed close table 让频繁访问或刚关闭又重开的 key 能更快命中。

我觉得这一节最值得沉淀成自己一句话的理解就是：

注册表性能优化，不是“单纯少点数据”，而是“让真正会被频繁访问的那部分数据，以更紧凑、更连续、更少重复、更高命中的方式存在”。

下一篇预告

《Windows Internals》10.1.27 Windows services：为什么“服务”不是简单的后台 EXE，而是一整套围绕 SCM、账户、启动时序、失败恢复和共享宿主进程组织起来的系统机制？》

这一篇可以继续把：

• service application
• service control program
• SCM
• service account
• autostart
• shared service process
• protected services

全部串起来。

返回顶部