真正可优化的是内层循环访问数据的物理连续性与缓存友好性：倒排链改用紧凑int[]编码并按缓存行对齐，外层按段顺序调度，内层按物理偏移扫描，嵌套维度绑定存储分区，扁平化结构替代嵌套引用。
循环嵌套本身不产生局部性，但嵌套结构暴露了数据访问的天然分层模式——外层按文档段（segment）遍历，内层按词项（term）或倒排链（posting list）扫描。真正可优化的是：让内层循环访问的数据，在内存中物理连续、在存储中顺序排列、在cpu缓存中成块加载。关键不在“怎么写嵌套”，而在“嵌套里扫什么、怎么组织它”。
把倒排链从对象链表压成紧凑数组，对齐缓存行
Java中常见用ArrayList<Posting>或链表存倒排项，每个Posting是独立对象，分散在堆各处。一次遍历触发多次指针跳转和缓存未命中。
- 改用int[]按固定模式编码：docId、freq、posCount、pos1、pos2……交替存放，避免Object头和引用开销
- 把docId（int）和freq（int）打包进一个long（前32位docId，后32位freq），4个这样的long正好填满64字节缓存行
- 扫描时用for(int i = 0; i < arr.length; i += 2)直接解包，CPU预取器能稳定识别步长，L1 cache命中率提升明显
外层按段（segment）顺序调度，内层按词典序+物理块对齐扫描
Lucene段文件天然按block切分，倒排索引的term dictionary和posting数据都按文档序连续写入。若内层循环乱序查term，就破坏空间局部性。
- 外层循环遍历segments列表时，按commit顺序或file size升序排列，确保IO流连续
- 内层不按查询词频排序遍历term，而是按term在.dvd/.dvm文件中的物理偏移顺序读取——Lucene的BlockTree术语字典支持seekTo()快速定位起始位置
- 配合使用DocValues而非stored fields：前者列存、按docID物理连续；后者行存、字段跨文档跳跃，cache line利用率常低于25%
嵌套维度与存储分区强绑定，让“同一批扫”的数据落在同一缓存域
分布式环境下，嵌套逻辑若跨节点跳转，空间局部性直接归零。必须让计算路径收敛到局部资源域。
- 外层循环控制shard粒度：用routing=tenant_id+day保证同一业务天的数据落在同一shard，后续批量扫描天然具备文档序聚集性
- 内层循环处理posting时，启用RocksDB column family隔离热点字段（如status、price），并pin_l0_filter_and_data_blocks_in_cache，把元数据常驻L3 cache
- 在Flink或Spark作业中，设置input.split.location.policy=LOCALITY_AWARE，使map task优先启动在HDFS block所在节点，避免跨机架拉取
用扁平化结构替代嵌套集合，切断无效引用跳转
典型场景：Order包含List<Item>，Item含Map<String, Object>。这种结构在堆中像散弹打靶，每次get()都可能触发一次cache miss。
- 对固定schema数据（如日志事件、商品快照），生成FlatBuffer schema，序列化后mmap到堆外，跳过JVM对象分配
- 用int[]存itemIds、short[]存quantity、byte[]存status，用下标代替对象引用，一次read()喂饱后续多次解包
- 在倒排扫描中，把“term → segment → docId → freq”这个嵌套路径，压缩为“termOffset → segmentBase → packedPostings[]”，消除中间层对象
