强开THP本身不直接引发OOM，但强开+无回收+大范围扫描三者叠加会加剧内存压力并触发OOM Killer；其根源在于强制分配2MB大页导致memory bloating、碎片化compact消耗CPU、扫描放大零页RSS占用，最终引发缺页风暴与负反馈循环。

强开透明大页（THP）本身不会直接“引发”系统级OOM，但会在特定负载下显著加剧内存压力，最终触发内核OOM killer。关键不在“开”，而在“强开+无回收+大范围扫描”三者叠加——这会绕过内核的常规内存节流机制，把碎片、延迟和膨胀问题集中引爆。

THP强制启用破坏了内存分配的弹性边界

默认情况下，THP是自适应启用：khugepaged只合并那些连续、干净、未被锁住的4KB页；应用申请小内存时，内核仍可回退到普通页分配。但若通过/sys/kernel/mm/transparent_hugepage/enabled强行设为always，就等于关闭了这个安全阀：

• 所有mmap匿名内存（包括JVM堆、malloc大块）优先尝试分配2MB大页，哪怕只用其中1个子页
• 即使物理内存已高度碎片化，内核仍会反复compact内存以拼出2MB连续空间，消耗CPU且延长分配延迟
• 一旦成功分配，该2MB页就“钉死”在RSS中，哪怕实际只用了8KB——这就是memory bloating的源头

堆内存大范围扫描放大THP的零页浪费效应

JVM GC（尤其是CMS或ZGC的并发标记）、glibc malloc的arena遍历、或用户态内存分析工具（如pstack + pmap联动扫描），都会触发对进程地址空间的大范围页表遍历。此时问题暴露：

• 每个被THP覆盖的虚拟地址区间，内核必须加载整个2MB页的PTE（页表项）进入TLB；即便其中510个子页全是零页，也要计入RSS
• 扫描过程本身不释放内存，却迫使内核维持大量“半活跃”大页结构，挤占slab cache和pagevec等关键内存管理元数据空间
• 当多个进程同时扫描（如监控Agent批量采集），各进程的THP bloating叠加，可用内存水位骤降，触发直接回收（direct reclaim）

缺页中断风暴与OOM killer的连锁触发

真正压垮系统的不是静态占用，而是动态竞争：

• THP拆页（split_huge_page）需持有mmap_lock写锁，而大范围扫描常伴随大量mincore()或readv()系统调用，频繁触发缺页——此时锁争用导致页面分配卡顿
• 内核在direct reclaim路径中发现无法快速回收足够内存，开始同步执行thp reclaim（如果开启）；但拆页+归零页回收本身又需要额外内存，形成负反馈循环
• 最终kswapd线程持续失败，/proc/sys/vm/oom_kill_allocating_task为1时，OOM killer直接杀掉正在扫描的进程（如java或python脚本），而非真正吃内存的业务进程

规避方案要从分配源头切入

不建议简单关THP，而是分层控制：

• 对JVM进程：启动时加-XX:+UseTransparentHugePages -XX:+AlwaysPreTouch，让JVM在初始化阶段一次性触达并锁定所需大页，避免运行时分散分配
• 对扫描类工具：禁用其自动madvise(MADV_HUGEPAGE)，改用madvise(addr, len, MADV_NOHUGEPAGE)显式排除扫描区域
• 系统级兜底：启用memcg粒度的memory.thp_reclaim = reclaim，确保OOM前至少回收零页；同时设置/proc/sys/vm/swappiness=1抑制swap倾向，避免THP swap进一步恶化延迟