happy最紧要1. 现象描述：线上服务内存异常飙升，pprof却查不出东西
先说个真实场景。某天下午，我负责的一个Go网关服务突然被监控告警轰炸：RSS（实际物理内存占用）在半小时内从2GB一路飙到11GB，QPS没涨多少，CPU也没异动，服务本身还能用，但内存就是下不来。当时第一反应是拿go tool pprof抓heap，结果让人非常困惑——堆内存（HeapAlloc）只有1.5GB，远远配不上11GB的RSS。更别提goroutine数量、channel堆积、协程泄漏这些常规怀疑对象，检查了一圈全是正常的。
如果你也遇到过类似情况：pprof的heap采样数值正常，但系统监控里的RSS居高不下，重启后短暂恢复，过段时间又涨上去，那大概率不是你的业务代码在泄漏，而是你的Go程序在跟操作系统内核的内存管理机制较劲。这个“元凶”就是THP，全称Transparent Huge Pages，透明大页。
THP这个名字，很多人可能听过但没深入研究过。它是Linux内核默认开启的一个特性，在大多数发行版上默认状态是madvise或always。但恰恰是它，跟Go的运行时内存管理方式存在一处隐蔽的冲突，会在特定负载下让RSS像滚雪球一样膨胀，表面看起来就是“内存异常”。
这篇文章我会把这个问题的来龙去脉拆开讲清楚：THP到底是什么、为什么会和Go运行时冲突、如何用实验复现确认、生产环境怎么修，以及如果有需要，怎么在不改代码的前提下缓解问题。全程都是可验证、可复现的思路和命令，希望帮你少走弯路。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. THP与Go运行时：一次“分配不透明”引发的冲突
2.1 THP是个什么东西
虚拟内存是现代操作系统的地基。进程以为自己拥有一整片连续地址空间，实际上地址只是映射，背后的物理内存可能零散分布。内核负责维护这段映射关系，每次把虚拟地址指向物理地址的动作叫“缺页分配”，一个小粒度的内存页通常是4KB。
THP的思路很直接：把传统的4KB小页合并成2MB的大页，这样TLB（快表，缓存虚拟地址到物理地址映射的硬件结构）能覆盖更大的内存范围，缺页次数变少，大内存场景下整体性能会有明显提升。这本身是个很好的优化手段，尤其适合数据库、大型JVM应用这类大块连续内存分配的使用方式。问题在于这个“透明”——它默认对所有进程生效，不需要应用感知，也不需要应用主动配合。
在支持的架构上，当一个进程申请了一块内存区域并开始写入时，内核的khugepaged后台线程会尝试扫描这些内存区域，把连续的、相同状态的4KB小页合并成2MB大页。注意这里的“合并”是内核单方面做的，应用自己毫不知情。对Java这种动辄申请几个GB堆内存、且偏爱大容量连续内存的程序来说，THP是加分的。但对Go来说，情况就不一样了。
2.2 Go运行时的内存管理模式
理解冲突根源前，需要先知道Go运行时是怎么跟操作系统打交道的。Go的runtime自己实现了一套内存分配器，在这套分配器里，Go并不会每分配一个小对象就调用一次mmap向操作系统申请内存，那样系统调用开销太大。它的做法是：从操作系统一次性申请大块的内存池（通常以arena为单位，每次mmap申请几MB到几十MB），然后把这块内存池细分成大小不同的空闲列表，供内部的小对象分配使用。
这个设计让Go的分配器极快，相比之下申请/释放都发生在用户态，基本上不触发系统调用。但代价是：Go向操作系统申请来的内存，在归还策略上是比较保守的。当程序不再使用某块内存时，Go运行时并不会立刻把这块内存还回操作系统，而是留着复用。这种策略叫madvise的两种模式之争：一种是把内存标记为MADV_FREE，意思是“这片内存我没用了，但物理页先别急着回收，留着以后再用”；另一种是MADV_DONTNEED，意思是“这片内存我不需要了，物理页你随便回收”。Go在一个版本更新里改变了默认行为——从MADV_FREE改为MADV_DONTNEED，为的是能及时归还内存给操作系统，避免RSS虚高。
这里有一个容易忽略的核心机制：物理内存到底释放到哪一步，并不完全由Go进程说了算，内核有它的“自主决定权”。如果你的机器上THP处于always或madvise模式，内核会在后台努力把你进程里的4KB页面合并成2MB大页。合并看似美好，但在释放阶段，问题就来了——大页的拆分和释放逻辑要复杂得多，尤其是当一个2MB的大页里只有一部分页面是真正被释放的，另一部分仍然被使用时，内核无法把这个大页整体拆分回去归还给伙伴系统。结果就是，进程物理上占了这块内存，但Go运行时那边已经认为这些内存被释放可复用了，两边的“记账”产生了落差。
打个比方：你把一整盘水果（物理内存）放在桌上说给朋友吃（进程使用）。朋友只拿走了其中几颗（部分释放），但你看到盘子空了，就认为整个盘子都能给别人用（RSS里的对应页回收）。实际上盘子还留在桌上占着位置（物理内存没归还），后果自然是桌上越来越满——RSS越飙越高，可pprof看到的“堆内存”却根本不匹配。
2.3 为什么pprof查不出这个坑
好，回到最初那个问题：pprof的heap采样里HeapAlloc只有1.5GB，RSS却到了11GB。这个数字悬殊的解释，正是因为pprof测量的是Go运行时自己记账的“Go侧视角”：它只统计当前还在被Go堆持有、尚未释放回去的对象。而那些已经通过free操作放回Go的空闲页，如果底层物理页还因为THP大页的关系被内核扣着，就完全不会出现在pprof里。
更进一步，Go runtime还有一部分内存是“非堆内存”，比如栈、mheap的管理结构、MMAP地址空间的预留部分，这些同样不进pprof的heap采样范畴。如果你只看pprof，就会得出一个结论：“内存正常，没有泄漏”。可实际上物理内存被内核THP扣了一大块，产生了表面无法解释的RSS膨胀。
这类问题最头疼的是隐蔽性强、排查路径长。很多人花了大量时间在业务代码分析上，甚至怀疑是第三方库泄漏，但真正的根源在运行时与内核交互的边界上。
3. 实操排查：从pprof到系统指标，一步步定位THP
3.1 第一步：确认RSS虚高可不代表heap真实占用高
以我当时的网关服务为例，内存异常的排查不能一上来就猜是代码泄漏。第一步永远是数据收集，把不同视角的数据摆在一起对照，最基本的几类数据如下：
- 系统视角：
/proc/[pid]/status里的VmRSS（实际物理内存占用），以及/proc/[pid]/smaps里的内存区域明细 - Go视角：
go tool pprof http://localhost:6060/debug/pprof/heap抓出来的heap profile - 运行时视角：
runtime.ReadMemStats里的HeapAlloc、HeapSys、HeapReleased等字段
一旦发现HeapAlloc正常但RSS快速增长，就要把注意力从“业务代码有没有泄露”转向“Go运行时和系统内核之间的内存协作是否异常”。此时推荐用GODEBUG=madvdontneed=1重启进程，观察RSS是否还继续涨。这个环境变量会强制Go在释放内存时使用MADV_DONTNEED明确告知内核“这页我不需要了”，后者能规避THP相关的释放走样问题。如果加了之后RSS曲线明显变平，那几乎可以锁定问题就出在“内核没有及时回收Go已经释放的页面”。
注意：Go 1.16之前，runtime默认用的是
MADV_DONTNEED，从1.16起改为MADV_FREE以降低释放内存时的损耗（因为DONTNEED每次释放都要做一次页表清空），代价就是上面说的RSS虚高问题。这个环境变量在较新版本仍然有效，但官方也说后续版本可能移除。
3.2 第二步：看smaps里的大页分布
只靠RSS和heap对比还不够，还需要更实锤的证据。这一步要直接看进程地址空间里到底发生了什么：
bash复制grep -i "thp" /proc/[pid]/smaps | head -20
如果/proc/[pid]/smaps里有大量AnonHugePages: 2048 kB这样的记录，说明这个大页确实被THP合并过。更直观的是看整个进程进程地址空间里大页占了多大范围：
bash复制grep -E "AnonHugePages|VmRSS" /proc/[pid]/status /proc/[pid]/smaps
另外可以叠加一个指标：单次迭代的内存占用变化趋势。比如跑固定压测流量十分钟，每30秒记录一次RSS和HeapAlloc，绘制曲线。如果RSS一直涨但HeapAlloc保持平台，说明“Go认为空闲、系统没有回收”的内存越来越大，这是THP冲突的典型特征。数据能帮你更清楚地还原问题，方便后续跟同事沟通。
还有一个值得看的文件是/proc/vmstat里的thp_collapse_alloc、thp_split_page等计数器，内核每次把普通页合并成大页或拆分大页时都会累加计数。如果在压测过程中这些计数在快速增加，说明THP活动频繁。不过这个文件是整个系统的全局统计，不能只靠它判断单个进程，需要结合前面的数据综合理解。
3.3 第三步：实验复现，用最小代码重现问题
有时候线上环境复杂，想确认是不是THP只能做对照实验。一个我自己写过的最小复现程序，就把问题拉到可控条件下做得非常清晰：
go复制package main
import (
"fmt"
"os"
"os/signal"
"runtime"
"syscall"
"time"
)
func main() {
// 分配一个比较大的切片，模拟业务里的大块内存使用
var data [][]byte
for i := 0; i < 1024; i++ {
buf := make([]byte, 2<<20) // 2MB
for j := 0; j < len(buf); j += 4096 {
buf[j] = 1 // 触发缺页，实际占物理内存
}
data = append(data, buf)
}
fmt.Println("Allocated, sleeping 30s...")
time.Sleep(30 * time.Second)
// 释放内存，只看不持有引用
runtime.GC()
data = nil
fmt.Println("Released, sleeping 60s...")
// 检查当前RSS
readMemStatsOnce := func() {
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Printf("HeapAlloc=%dMB HeapSys=%dMB HeapReleased=%dMB RSS=%dMB\n",
m.HeapAlloc/1024/1024, m.HeapSys/1024/1024, m.HeapReleased/1024/1024, getRSS())
}
readMemStatsOnce()
time.Sleep(60 * time.Second)
readMemStatsOnce()
time.Sleep(60 * time.Second)
readMemStatsOnce()
c := make(chan os.Signal, 1)
signal.Notify(c, syscall.SIGINT, syscall.SIGTERM)
<-c
}
func getRSS() int64 {
data, err := os.ReadFile("/proc/self/status")
if err != nil {
return 0
}
var rss int64
for _, line := range strings.Split(string(data), "\n") {
if strings.HasPrefix(line, "VmRSS:") {
fmt.Sscanf(strings.TrimSpace(line[6:]), "%d kB", &rss)
return rss * 1024
}
}
return 0
}
这个程序做了三件事：分配一大块内存并实际写入触发物理页分配；释放内存，让Go运行时将内存归还给内部的空闲列表；反复观察RSS是否下降。如果是在THP开启的机器上跑，你大概率会看到RSS长期停留在高位不降，但HeapAlloc已经降到了很小的值。这是验证“THP导致Go内存释放后RSS不回落”的最简单路径。
你可以分别跑两次：一次在启动时加了GODEBUG=madvdontneed=1，一次不加，对比RSS曲线。加了之后，你会发现RSS能相对及时地回落——这从实验层面再次验证了问题根源。
3.4 排查路径速查
| 现象 | 可能原因 | 验证手段 |
|---|---|---|
| HeapAlloc正常，RSS持续高 | THP合并后物理页难以部分回收 | 对照smaps里的AnonHugePages |
| 重启后RSS缓慢爬升，GC后也不降 | runtime与内核的释放语义不一致 | 加GODEBUG=madvdontneed=1对比 |
| pprof堆内存使用率很低但RSS很高 | heap统计范围有限，物理页被内核扣住 | 用/proc/[pid]/smaps和压测曲线做双重确认 |
| 只有压测/高并发时出现，平时稳定 | 大量分配再释放时THP触发频率变高 | 观察vmstat里的thp合并计数 |
4. 解决方案：从根源到应急，三层手段依次做
4.1 优先方案：关闭/调整THP
如果你有生产环境的root权限，最简单的根治方法就是让THP不作用于Go服务。这里有个关键点：THP是系统级配置，会影响所有进程，所以在生产环境全局关掉之前，最好先跟DBA/其他人确认有没有依赖THP的其他应用。
查看当前THP模式：
bash复制cat /sys/kernel/mm/transparent_hugepage/enabled
输出可能是[always] madvise never或always [madvise] never，带方括号的就是当前生效模式。所谓madvise模式，是内核只对“主动调用madvise设置MADV_HUGEPAGE的内存区域”使用大页合并。Go运行时没有调用这个接口，所以在madvise模式下GRUB是安全的。
需要临时关闭，运行：
bash复制echo never > /sys/kernel/mm/transparent_hugepage/enabled
但这是临时改动，重启失效。想持久化，在不同发行版上有两种做法：
- CentOS/RHEL 7+：编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX中追加transparent_hugepage=never，然后重新生成grub.cfg并重启 - Debian/Ubuntu：在rc.local或systemd service文件中启动时执行echo命令，例如写一个oneshot服务
还有一个折中方案：与其全局关闭THP，不如设置一个更细的启动参数——echo madvise > /sys/kernel/mm/transparent_hugepage/enabled。在madvise模式下，Go不主动请求大页，THP实际上不会干预。这种方式对其他程序（比如数据库）的THP加速能力影响较小，推荐优先采用。如果应用本身对延迟不敏感、只求稳妥，never当然也没问题。
注意：改/sys里的文件需要root权限，Kubernetes容器场景下宿主机配置不一定允许你改。在云上托管集群、容器环境里，你需要通过节点池或托管节点组的启动脚本来配置。如果完全没有这个权限，只能靠下面两个缓解手段。
4.2 不改代码的缓解方案：调大环境的MADV释放策略
如果你没有改系统配置的权限，或者在容器里无法触碰宿主机内核参数，可以试试直接给Go运行时“打补丁”。Go官方提供的GODEBUG=madvdontneed=1就是我们前面实验中出现过的方案，它会让Go在释放内存时从默认的MADV_FREE切到MADV_DONTNEED，这样释放请求能更主动地告诉内核：“这页真的不要了，请你回收”。实测下来，在高RSS场景下能显著降低内存尖峰，并且对大部分服务性能影响不大。
使用方法很简单，在当前shell或启动脚本里设置环境变量后启动进程即可：
bash复制GODEBUG=madvdontneed=1 ./your-go-service
不过要说明一点：MADV_DONTNEED相对于MADV_FREE，内存释放时会有额外的页表清理开销，理论上会引入轻微的CPU消耗和延迟抖动。我用网关服务压测时，CPU总体大概增加1%～3%，延迟P99没有明显变化；但如果你是一个极致的延迟敏感型服务，最好在测试环境压一下再决定是否全量启用。
另外还要提醒一个细节：这个环境变量在Go 1.16～1.21版本里都有效。如果后续Go版本官方把它移除或改变行为，需要关注release note。
4.3 改代码侧的兜底策略：控制大块内存分配节奏
如果是自己的服务，且代码结构允许，还可以从业务侧规避THP合并的发生。思路说起来也简单：THP合并是对“连续地址空间+密集写入”的内存区域才能生效，如果让Go的内存分配行为更碎片化，让khugepaged扫描到的大块连续页减少，触发合并的概率就低了。
实操上我验证过两种有效手段：
- 对大切片/大缓冲区的分配，不要一次性申请连续大内存，而是改用小份的池化对象组合。工程实现上可以和
sync.Pool结合，把大块内存拆散复用，既减少连续内存的形成，也多了一层复用保护。 - 对长期缓存的数据，尽量在分配时避免全部“热写入”，比如只写用到的部分。内核判断一页能否合并，取决于整个页是否处于活跃状态，一片内存在分配后马上被整体写入，是最容易促成合并的场景。
不过这个方法属于“躲”，不是“治”。如果业务代码重构成本高，前两种手段应该优先。
4.4 容器的特殊情况
现在很多Go服务跑在Docker/Kubernetes里，THP问题在容器环境中更加隐蔽。原因在于，容器侧看到的/sys/kernel/mm/transparent_hugepage/enabled跟宿主机是一致的——因为它是内核的全局配置，不是cgroup命名空间隔离的。普通用户容器里即便你是root，直接echo never > /sys/kernel/mm/transparent_hugepage/enabled通常也会报Read-only file system，因为/sys默认只读挂载。所以容器环境里THP的实际状态完全由宿主机决定，应用侧只能通过GODEBUG等运行时参数来缓解。
在裸机或传统VM上，更标准的做法是运维配置层面关闭。但在K8s环境里，最佳实践往往是把带有THP问题的服务调度到“已经关闭THP”的节点池里，用节点池的taint/label区分管理，没有这个条件就统一回归到GODEBUG方案。还有一个冷门但值得注意的点：Go 1.22之后，如果设置了GOMEMLIMIT和GOGC配合，runtime会更积极地控制堆的增长，间接减少底层物理内存的申请频率，对RSS虚高也有一定缓解，但本质上不如排除THP影响来得彻底。
5. 经验沉淀：排查这类“Go内存异常”问题的通用思路
5.1 别一见内存高就怀疑代码泄漏
我见过不少人把“RSS高”直接等于“内存泄漏”，然后开始没日没夜地review代码、灌注pprof对比，最后发现一切正常。高RSS很可能由多种原因叠加而成，举几个我遇到过的真实例子：
- cgo调用C库分配的内存，不归Go的堆管理，但会占RSS
- 大量goroutine的栈内存，长期不回收也会占用RSS
- mmap映射文件或共享内存，RSS里能看到，但pprof完全无感知
- Go runtime的备用堆、线程栈底部的预留区域
- THP合并导致页面释放延迟
所以排查的第一步永远是搭建“多维数据对照表”，把系统全局、进程级、运行时级的数据都拉起来看，而不是一头扎进代码里。我个人的习惯是：
- 全局：
free -h、vmstat 1、ps aux --sort=-%mem看谁在涨 - 进程级：
/proc/[pid]/smaps、/proc/[pid]/status的VmRSS/VmSwap，以及grep -A1 VmFlags看特定区域 - Go运行时：pprof的heap、goroutine，以及
runtime/metrics里的/memory/classes/heap/released、/memory/classes/heap/free等指标
当你发现Go侧的指标正常而系统侧RSS异常偏大，再去怀疑内核/运行时层面的交互问题（比如THP），能省下大量无效定位时间。
5.2 用runtime/metrics量化“释放了多少但系统还没回收”
在定位过程中一个很有效的指标是/memory/classes/heap/released。它表示Go已经释放并归还给操作系统的内存量。如果这个值一直很小，即使HeapSys很大，说明“Go不愿意还内存”；但如果你把GODEBUG=madvdontneed=1打开后，这个值明显变大、RSS同步下降，那说明“Go愿意还了，但系统迟迟不接收”。
写个很小的HTTP服务暴露这些runtime指标，再配个Prometheus exporter抓取，能做成长期的可观测性看板。下面是可以直接放在main函数附近的一段示例：
go复制import (
"context"
"fmt"
"runtime/metrics"
)
func printRuntimeMemoryMetrics() {
const n = 4
samples := make([]metrics.Sample, n)
samples[0].Name = "/memory/classes/heap/released:bytes"
samples[1].Name = "/memory/classes/heap/free:bytes"
samples[2].Name = "/memory/classes/heap/objects:bytes"
samples[3].Name = "/memory/classes/heap/unused:bytes"
metrics.Read(samples)
for _, s := range samples {
if s.Value.Kind() == metrics.KindUint64 {
fmt.Printf("%s = %dMB\n", s.Name, s.Value.Uint64()/1024/1024)
}
}
}
5.3 实测覆盖面要广，别只压一个场景
关于压测，想说得再多一些。排查THP问题，容易犯一个错误：只跑冷启动场景或者低QPS压测，结果一切正常，就认为THP不是根因。这是不对的。THP合并行为与内存分配/释放的频度强相关，只有模拟出高频的、连续的大块内存分配和释放循环，khugepaged才有机会大量介入。所以压测方案至少要覆盖：
- 高QPS、短连接/长连接混合场景
- 长时间低峰值（比如24小时稳定性压测）
- 大对象频繁分配的接口（比如文件上传、大报文读取）
- 周期性任务（比如定时大批量拉数据、处理完释放）
在这些场景下持续记录RSS、HeapSys、HeapReleased和thp相关的内核计数器，才有可能把问题从“偶发内存抖动”提炼成“可复现的系统性冲突”。如果压测环境与生产环境内核配置一致，这一步基本就能实锤。
5.4 善用监控看板和告警规则
内存问题往往需要长时间观察才能下结论，因此建议提前做好监控看板。除了常规的容器/宿主机内存使用率之外，针对Go服务建议再加上：
- runtime/metrics里的HeapSys vs. HeapAlloc差值
/memory/classes/heap/released的速率变化/proc/[pid]/status的AnonHugePages值- 进程启动时长与RSS的关系曲线
对于告警，不要只看RSS绝对值，这种阈值告警很容易误伤。更好的方式是做“RSS跟HeapAlloc的差值告警”——两者差超过某个阈值（比如2GB）并持续5分钟，才触发“可能存在THP导致的内存虚高”告警。这能帮你尽早发现这类问题，又不至于被无关的临时峰值打扰。
6. 另一种“内存异常”的延伸：优雅退出与全量释放时机
排查THP的过程中，还发现一个与之相关的取舍值得拿出来单独讲：Go服务在优雅退出时，内存到底要不要主动释放。
很多团队在实现优雅停机时，会做类似“清空缓存、主动调用runtime.GC()”的操作，想着让RSS降下来再退出。说实话，在THP开启的机器上，这个操作通常没什么用。你主动GC只是让Go运行时把内存标记为可复用，但物理页由于THP路径下的释放延迟，不会立刻回到系统。优雅退出时要关注的核心是“不再接受新请求，处理完存量请求”，而不是“把RSS压下来”。
runtime/debug.FreeOSMemory()可以强制把空闲内存归还给操作系统，但它的代价是STW（Stop The World）——全进程暂停，直到所有可释放内存被清理。这个函数在优雅退出阶段调用一两次，或作为低峰期维护窗口的操作，是可以考虑的，但绝不能在请求处理热点上频繁调用，否则延迟会变得不可控。
我在实际项目里见过一个反面案例：有人给服务加了定时器，每隔5分钟调一次debug.FreeOSMemory()来“防止内存膨胀”，结果P99延迟从10ms飙到了500ms以上。原因很简单，大堆释放时会锁页、清页表，并且触发大范围syscall，期间所有goroutine全部冻结。任何主动触发运行时归还内存的手段，都得用性能和指标的收益来衡量，不能出于对RSS的恐惧就乱用。
7. 常见问题速查与避坑指南
把排查和解决过程中最容易踩的坑集中列一下，每条都是实际趟过的。
| 问题 | 原因 | 正确解法 |
|---|---|---|
| 我在容器里执行echo never，提示只读文件系统 | /sys在容器内只读 | 在宿主机或节点初始化脚本中配置 |
| 关闭THP后，Java服务性能下降 | 关闭大页会影响TLB命中率 | 不要全局关闭，改用madvise模式 |
| GODEBUG=madvdontneed=1后CPU涨了 | MADV_DONTNEED有额外页表清理开销 | 对延迟/CPU敏感的服务进行压测评估再上线 |
| 加GODEBUG解决不了RSS高 | 内存可能来自cgo或mmap文件映射 | 用smaps排查，确认内存归属 |
| pprof heap显示正常，RSS却很高 | THP大页导致系统未及时回收 | 用RSS/HeapAlloc差值监控，避免只看pprof下结论 |
| khugepaged CPU飙高 | 系统里大量进程频繁分配释放内存 | 调低/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs或考虑关闭THP |
| 更换了go版本后问题消失 | 新版本runtime调整了释放策略 | 不要依赖版本变更，仍建议按本文方法系统性排查 |
还有一个容易混淆的点，就是THP=always和THP=madvise的区别。always模式下，内核只要发现满足条件的连续内存就会尝试合并，管你应用愿不愿意；而madvise下，只有应用显式声明可以合并的内存区域才会被合并。Go没有显式请求，所以madvise下THP实际上几乎不起作用。这也是为什么很多云厂商推荐“折中修改为madvise”而不是一刀切never的原因。
8. 最后的实践经验
这篇文章写下来，核心就是这几条个人体会：
第一，Go程序的内存问题，视角要放开。pprof只反映Go运行时自己的“记账”，真正的物理内存占用要看系统指标，二者之间的差值恰恰藏着运行时与内核的交互异常。THP是这类问题里最典型的一个，但绝不是唯一一个。
第二，解决问题的时候，优先级应该是：先看能不能用启动参数或环境变量缓解（成本最低），再看能不能调整系统配置（需要权限），最后才考虑动代码重构。盲目改代码很容易浪费时间，反而忽视了真正的坑。
第三，THP这类问题，往往不只在Go里出现，但Go因为有自己的内存池、释放策略，跟THP的冲突表现形式特别明显。对于Java程序，问题往往表现为GC卡顿；对于Go，问题则是RSS虚高、释放延迟。两者的触发机制都是内核的“善意优化”在特定分配模式下变成了“副作用”——理解了这个出发点，你会对这台机器上跑的其他服务有更全面的判断。
最后分享一个实操中觉得很好用的点：搭建监控看板的时候，除了常见的container_memory_usage_bytes和process_resident_memory_bytes指标，可以额外采集一个/proc/[pid]/status里的AnonHugePages指标，如果这个值长期占RSS比较高，就能比其他人早一步嗅到THP相关问题的味道，提前规避一轮线上事故。