4. 内存资源调优：内存分配策略、缓存命中率优化、大页内存配置
内存调优这件事，说实话，很多开发同学容易忽视。大家总觉得内存不够就加内存条，或者把 JVM 堆调大一点就完事了。但我在实际项目中踩过不少坑，发现内存调优远不止这么简单。窗口计算这种场景，数据量大、延迟敏感，内存用不好，延迟直接飙升。
这一章，我把自己这些年积累的内存调优经验拆开来讲。从分配策略开始，到缓存命中率，最后聊大页内存。嗯，咱们一步步来。
4.1 内存分配策略：别让 GC 成为你的瓶颈
先问个问题：你的应用频繁 Full GC 吗？如果答案是肯定的，那多半是内存分配策略没选对。
我个人习惯把内存分配策略分成三个层次来看：
- 对象分配：小对象走 TLAB，大对象直接进老年代
- 分代策略：新生代、老年代的比例要匹配业务特征
- 分配速率：单位时间内分配的内存总量，决定了 GC 频率
窗口计算里，数据对象通常是短命的。比如一个滑动窗口，每来一条数据就创建一个事件对象，窗口滑动后又释放掉。这种场景下，新生代如果太小，对象频繁晋升到老年代，老年代一满就触发 Full GC。我见过一个线上案例，新生代只给了 256MB，结果每 30 秒一次 Full GC，延迟从 10ms 飙到 800ms。
核心原则：窗口计算场景，新生代建议占总堆的 40%~50%。如果窗口数据量大，甚至可以给到 60%。
具体怎么配？我一般用这个公式估算：
# 假设窗口大小 1 分钟，每秒 1000 条数据，每条对象 512 字节
# 新生代需要容纳：60 * 1000 * 512 = 30MB
# 加上 GC 后存活对象，建议新生代至少 256MB
-Xmn256m
-XX:NewRatio=2 # 新生代:老年代 = 1:2
-XX:SurvivorRatio=8 # Eden:Survivor = 8:1:1这里有个坑：SurvivorRatio 别设太大。我之前设成 32，结果 Survivor 区太小，对象在 Minor GC 时直接晋升到老年代，老年代涨得飞快。后来改成 8，情况好多了。
小技巧：用 -XX:+PrintGCDetails 观察对象晋升情况。如果老年代增长过快，说明 Survivor 区不够用，或者新生代太小。
4.2 缓存命中率优化：把热数据留在内存里
缓存命中率，说白了就是「你访问的数据，有多少次在内存里直接拿到了」。窗口计算里，缓存主要用在两个地方：
- 窗口状态缓存：比如 Flink 的 KeyedState，或者自己实现的滑动窗口聚合结果
- 中间计算结果缓存：比如去重用的 BloomFilter，或者排序用的堆结构
我优化缓存命中率，一般盯三个指标：
| 指标 | 含义 | 窗口计算场景建议值 |
|---|---|---|
| 命中率 | 缓存命中的次数 / 总访问次数 | > 95% |
| 穿透率 | 缓存未命中 / 总访问次数 | < 5% |
| 失效速率 | 单位时间内缓存失效的对象数 | 尽量平稳，避免突刺 |
怎么提升命中率？我分享三个实战经验：
- 预加载：窗口启动前，把历史数据预加载到缓存。比如做 1 小时滑动窗口，提前 5 分钟把前 55 分钟的数据加载好。
- 淘汰策略选 LRU：窗口计算的数据访问模式通常是「最近访问过的数据，很快还会再访问」。LRU 比 LFU 更适合。
- 避免缓存雪崩：窗口过期时，别一次性清空所有缓存。我习惯用「分段过期」，比如每 10 秒过期一部分。
注意：缓存不是越大越好。缓存太大，GC 压力会剧增。我见过有人把缓存设成 64GB，结果 Full GC 一次 10 秒，业务直接断流。缓存大小建议控制在堆的 20%~30% 以内。
4.3 大页内存配置：减少 TLB Miss 的利器
大页内存，英文叫 Huge Pages。这东西很多同学听说过，但真正用好的不多。
先说说为什么需要大页。操作系统管理内存是按「页」来的，默认 4KB 一页。TLB（页表缓存）能存的页表项有限，如果内存很大，TLB 就会频繁 Miss，每次都要去查页表，延迟就上去了。
大页把页大小从 4KB 变成 2MB 甚至 1GB。同样的内存，需要的页表项少了，TLB Miss 自然就少了。
我做过一个对比测试：
| 配置 | TLB Miss 率 | 窗口计算延迟（P99） |
|---|---|---|
| 默认 4KB 页 | 3.2% | 45ms |
| 2MB 大页 | 0.4% | 22ms |
| 1GB 大页 | 0.05% | 18ms |
延迟降了一半多。嗯，效果很明显。
配置大页分两步：
- 操作系统层面：预留大页内存
- JVM 层面：启用大页并指定使用
Linux 下配置示例：
# 预留 1024 个 2MB 大页（总共 2GB）
echo 1024 > /proc/sys/vm/nr_hugepages
# 查看是否成功
grep HugePages_Total /proc/meminfo
# 输出：HugePages_Total: 1024JVM 参数：
-XX:+UseLargePages
-XX:LargePageSizeInBytes=2m踩坑提醒：我曾经在容器环境里配大页，结果容器没权限改 /proc/sys/vm/nr_hugepages，JVM 启动直接报错。容器环境建议用 -XX:+UseTransparentHugePages，或者直接在宿主机预留好。
透明大页（THP）是个折中方案。它不需要手动预留，内核自动把连续的小页合并成大页。但有个问题：THP 在内存碎片化时，合并操作会卡住进程。我建议窗口计算场景关掉 THP，用手动大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled4.4 知识体系总览
下面这张图，我把本章的核心逻辑串起来了。你可以对照着看，心里有个全局图景。
你看，这三个方面其实是联动的。分配策略决定了内存怎么分，缓存命中率决定了内存用得值不值，大页配置决定了内存访问快不快。任何一个短板，都会拖累整体延迟。
最后说一句：调优不是一锤子买卖。我每次上线新业务，都会用 -XX:+PrintFlagsFinal 把 JVM 参数打出来，再配合 perf stat -e dTLB-load-misses 看 TLB 情况。数据说话，别靠感觉。