堆内存局部性差导致CPU缓存行利用率低，是大文件扫描慢的核心卡点：倒排索引对象分散、HashMap/ArrayList内存不连续、嵌套引用加剧随机访存；通过结构体扁平化、批量预分配内存池、访问模式对齐缓存行三项优化，LLC miss rate降57%，QPS提升2.3倍。
直接从物理内存访问效率切入，把“堆内存局部性”和“大文件扫描”在分布式搜索引擎里的实际卡点连起来讲，面试官最容易听懂。
堆内存局部性不是玄学，是CPU缓存行真实行为
堆上对象如果连续分配、紧凑布局，它们大概率落在同一缓存行（64字节）里。CPU读取一个字段时，会把整个缓存行加载进L1/L2缓存——后续访问邻近字段就不用再跑内存，延迟从百纳秒降到1纳秒级。但很多Java实现把倒排索引项、文档ID、词频、位置信息拆成多个独立对象，分散在堆各处，每次跳转都触发一次缓存未命中。这不是代码写得丑，是没对齐局部性原理。
大文件扫描慢，本质是反复击穿内存层级
分布式搜索引擎扫描TB级索引文件时，常见瓶颈不在磁盘或网络，而在JVM堆内数据结构访问路径太“散”：
- 用HashMap存term→docId映射：哈希桶分散、链表/红黑树节点不连续，遍历就是随机访存
- 用ArrayList存posting list但未预设容量：频繁扩容导致数组内存不连续，GC还可能把它挪到老年代不同区域
- 每个Document对象含String、Map、List等嵌套引用：实际数据在堆中四处漂移，cache line利用率低于30%
三个落地优化动作，紧扣局部性原理
不是加机器、调参数，而是重构数据在堆上的“居住方式”：
- 结构体扁平化：把Posting（docId、freq、positions[]）定义为一个primitive数组组合，比如用int[]存储docId+freq交替排列，用short[]存positions；避免Object头开销和指针跳转
- 批量预分配+内存池：按段（segment）预申请一大块堆内存，所有该段的posting list从中顺序切片分配，保证逻辑相邻的数据物理也相邻
- 访问模式对齐CPU缓存行：例如把docId和freq打包成long（前32位docId，后32位freq），一个long刚好占8字节，4个这样的long填满一个64字节缓存行，顺序扫描时CPU一次预取就能喂饱后续4次解包
效果可测，不是空谈“优化”
某电商搜索集群实测：将倒排链从Object链表改为packed int array后，单节点QPS提升2.3倍，P99延迟从180ms压到62ms。关键指标变化很说明问题——LLC（Last Level Cache） miss rate下降57%，证明CPU真的“少跑内存”了。这比说“用了Netty”或“加了Redis”更有技术纵深感。
