前言

在介绍 "Go内存分配器" 如何应对内存碎片中的外部碎片时，我们提到了内存分配器如何通过优先从低地址分配、scavenger优先从高地址回收，来尽可能让高地址的Go Pages以及背后mapped RAM pages 闲置并归还给OS，甚至可能是归还的物理地址连续的RAM pages或者THP呢，从而来压制可能的外部碎片问题 …… 今天我们就来聊聊 THP :)

THP 介绍

THP（Transparent Huge Pages，透明巨页）是 Linux 内核中的一项内存管理技术。要理解它，我们得先聊聊 Linux 默认的内存管理方式。

在 Linux 中，内存是被分割成一块块来管理的，默认的大小是 4KB（称为标准页）。当一个程序（比如数据库）需要消耗几十 GB 甚至上百 GB 内存时，4KB 的页就会带来一个问题：页表（Page Table）变得极其庞大。 

CPU 在查找内存时，需要通过 TLB（Translation Lookaside Buffer，旁路转换缓冲） 缓存来加速。页表太大了，TLB 缓存装不下，就会导致频繁的“缓存未命中”（TLB Misses），CPU 就要花额外的时间去查表，性能随之下降。

为了解决这个问题，巨页（Huge Pages，通常是 2MB 或 1GB） 应运而生。而 THP 的核心就在于那个“透明（Transparent）”。

THP 与传统巨页的区别

在 THP 出现之前，Linux 已支持巨页（静态巨页），但它用起来很麻烦：

传统巨页（HugeTLB）： 需要系统管理员手动预留内存，而且应用程序必须修改代码（调用特殊的 API）才能使用。

透明巨页（THP）： 完全自动化。不需要修改任何应用代码，内核在后台默默地帮你把 4KB 的小页打包成 2MB 的巨页。应用层对此毫无感知，所以叫“透明”。

THP 是如何工作的

THP 的工作流程主要依赖两个机制：同步分配（缺页异常时）和异步合并（khugepaged 线程）。

动态分配（缺页异常时）

当进程触发缺页异常，内核会在以下条件同时满足时，尝试直接分配一个 2MB hugepage：

VMA 标志允许：该虚拟内存区域（VMA）没有被 madvise(MADV_NOHUGEPAGE) 显式禁用。若用 madvise(MADV_HUGEPAGE) 标记，则优先级更高。

申请大小与对齐：缺页地址所在的 VMA 跨度足够大（通常 ≥ 2MB），且地址本身是 2MB 对齐的。

内存可用：系统能找到一块连续的 2MB 物理内存（order-9 页面）。若内存碎片化严重，内核会进行短暂的内存规整（compaction）后重试，但不会无限等待。

系统开关开启：/sys/kernel/mm/transparent_hugepage/enabled 为 always 或 madvise。 只要其中任一条件不满足（尤其是连续物理内存不可用），内核就退回分配普通 4KB 小页，让程序先跑起来，剩下的工作交给 khugepaged。 核心判断逻辑可以理解为四个门：全局开关 → VMA 策略 → 地址对齐 → 物理内存可用性。任意一关不过就退回小页，但第四关失败（内存碎片）会触发 khugepaged 异步补救，而前三关失败则完全放弃本次 hugepage 尝试。

后台合并（khugepaged 守护进程）

khugepaged 定期扫描系统内存。当它发现某段连续的 4KB 小页（恰好 512 个，合计 2MB）已经全部填充、地址 2MB 对齐，且该区域允许 THP 时，就会：

将这 512 个小页锁住（防止并发修改）

分配一个新的 2MB 连续物理页

将数据逐页拷贝进去，更新页表，释放旧的小页 扫描间隔和每次处理的页数可通过 /sys/kernel/mm/transparent_hugepage/khugepaged/ 调整。

巨页拆分（Splitting）

THP 并非一成不变。以下情况会触发将 2MB hugepage 拆分回 512 个 4KB 小页：

• 进程执行 fork()，触发写时复制（CoW）——只需复制 4KB 而非 2MB

• mprotect() 修改了 hugepage 中部分页的权限

• madvise(MADV_DONTNEED) 或 munmap() 释放了 hugepage 的一部分

内存回收器（kswapd）需要回收其中少量页面 拆分的代价是显著的，因此频繁触发上述操作的场景（如大量 fork()）反而可能因 THP 带来额外开销。

为什么 THP 让人“又爱又恨”

听起来 THP 是个完美的银弹，但现实中它在生产环境（特别是数据库领域）经常被吐槽，甚至很多官方文档（如 Redis、MongoDB、Oracle）明确要求关闭 THP。

优点（爱）：

减少 TLB Miss： 极大地提高了 CPU 缓存命中率，对于视频编码、科学计算、大内存的虚拟化（KVM）等连续内存读写密集的场景，性能提升显著。

降低页表开销： 管理更少的页，意味着内核自身消耗的内存也减少了。

缺点（恨）：

延迟毛刺（Latency Spikes）： 后台的 khugepaged 线程在合并小页时，需要对内存加锁。还会申请一个hugepage然后将数据复制过去。如果当时内存碎片严重，合并操作会卡住，导致应用程序出现短暂的卡顿（几毫秒到几秒）。

内存放大/浪费（Memory Bloat）： 假设你的应用只需要修改 4KB 的数据，但因为它们在一个 2MB 的巨页里，内核在执行写时复制（COW, Copy on Write）时，需要再将hugepage拆分为512个4KB的pages，然后再复制写的这几个pages，而不是复制整个hugepage。 另外，在某些比较老的内核版本的代码路径中，如果VMA设置了MADV_HUGEPAGE，COW可能会复制整个 2MB 的hugepage数据。这不仅浪费了内存，还增加了 I/O 负担。

如何查看和控制 THP

你可以通过查看 /sys 目录下的内核参数来了解当前系统的 THP 状态：

cat /sys/kernel/mm/transparent_hugepage/enabled

输出通常有三种状态：

[always]：系统只要有机会，就会对所有进程使用 THP（默认）。

[madvise]：只有当应用程序显式调用 madvise(..., MADV_HUGEPAGE) 时，内核才会对该区域使用 THP。

[never]：完全禁用 THP。 

以我的Windows 11 + WSL为例，我的内核版本是6.6.123.2，THP是always打开状态。 

$ uname -a xxxxx 6.6.123.2-microsoft-standard-WSL2+ SMP PREEMPT_DYNAMIC Wed Mar 18 02:07:16 CST 2026 x86_64 x86_64 x86_64 GNU/Linux$ cat /sys/kernel/mm/transparent_hugepage/enabled[always] madvise never

如果你想临时关闭它（避免数据库被卡顿困扰），可以运行：

echo never > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defrag

本文总结

本文介绍了Linux内存管理技术THP（透明巨页）。它通过将4KB标准页自动合并为2MB巨页，减少TLB Miss与页表开销，提升大内存连续读写场景性能。THP支持缺页时动态分配与khugepaged后台异步合并，也会因写时复制等操作拆分巨页。其优点是提升缓存命中率、降低内核开销，缺点是后台合并可能导致延迟毛刺，拆分与旧内核逻辑易引发内存放大。 文中还说明了通过 /sys/kernel/mm/transparent_hugepage/ 查看和控制THP状态的方法。 

我们从Go内存分配器外部碎片相关优化出发，对与之密切相关的THP进行了介绍，相信大家对Go语言以及Linux内存管理这块的理解更深了 :)