大页内存的核心价值是降低TLB缺失率；若TLB miss率持续低于0.5%，启用大页几乎无收益，还可能加剧内存碎片化。
TLB miss率是否真的高
大页内存的核心价值是降低TLB（快表）缺失率。如果当前系统TLB miss本就不高，开大页几乎没收益，还可能因预留大页导致内存碎片化。用perf stat -e tlb-load-misses,tlb-store-misses跑真实负载（比如Oracle实例或Java应用压测），看miss占比是否持续超过0.5%——低于这个值，基本不用考虑大页。
系统是否已预留足够大页内存
Linux不支持运行时动态分配大页，必须提前预留。检查/proc/meminfo里的HugePages_Total是否≥你计划给JVM或Oracle分配的数量。注意：HugePages_Rsvd为0说明虽已预留但尚未被进程锁定，HugePages_Free突然归零而HugePages_Surp上升，说明内核在fallback到小页，大页实际没生效。
JDK是否真能使用大页（而非仅参数生效）
-XX:+UseLargePages只是开关，不保证成功。启动JVM后必须查日志或jstat -gccapacity输出中的NGCMN/NGCMX是否对齐到2MB边界；更直接的是用pmap -x <pid> | grep "huge"</pid>确认堆内存段标记为huge。常见失败点包括：JDK未以root权限启动（cap_ipc_lock缺失）、/proc/sys/vm/hugetlb_shm_group未设为JVM所属组、或使用了OpenJDK但底层glibc版本太老（
不同JDK实现对大页的响应差异极大
HotSpot（OpenJDK/Oracle JDK）和OpenJ9行为完全不同。实测显示：同一CentOS 6.5 + JDK 8u191环境下，HotSpot启用-XX:+UseLargePages后反而比普通页慢10%以上；而OpenJ9同配置下快10%。这不是配置错误，而是两套JVM对TLB利用策略、GC线程内存访问模式的底层差异。别迷信“开了就快”，必须拿你的JDK发行版+真实业务代码压测对比。
最容易被忽略的是：大页只影响堆内存映射，不影响Metaspace、CodeCache、线程栈等区域。如果你的瓶颈在类加载或JIT编译，开大页毫无意义。先用jstat -gc确认GC停顿主要来自Eden区回收，再动手配大页。
