企业官网建设流程全解析

数据局部性和缓存调度策略，是算法优化里那种“人人都知道很重要，但很少有人真去逐行抠”的领域。我见过太多工程师，花大把精力调算法复杂度，结果性能提升还比不上把一组循环交换内外层来得明显。原因很简单：现代CPU的算力早就溢出，瓶颈往往在内存和缓存的数据搬运上。这篇文章不聊空洞的理论，就聊怎么从数据局部性入手，结合缓存调度策略，把算法的实际运行时间降下来。

我习惯把这类优化分成两个层次看。第一层是空间局部性和时间局部性的挖掘，本质上是在调整数据访问的“时空分布”；第二层是配合硬件缓存机制，选择合适的调度策略，比如让数据尽量留在缓存里不被打出去。这两件事是互为表里的。单纯做循环展开，不考虑缓存行大小，效果可能很有限；单纯换一套替换策略，数据布局一团糟，调度算法也无力回天。所以真正有效的做法是先从数据布局下手，再配合调度策略做针对性调整。

适用这篇内容的读者，我默认是那些有一定算法基础、想在工程实践中榨出性能的开发人员。如果你是刚接触系统优化的新手，也没关系，我会尽量把缓存工作原理讲得通俗一些，但前提是你至少能看懂伪代码和基本的循环结构。

1. 内容整体设计与思路拆解

一段算法的运行时间，粗略可以分成两个部分：CPU实际执行指令的时间，以及等待数据的时间。现代CPU的频率已经很高，但内存的访问延迟大概在几十纳秒量级，而CPU周期通常是零点几纳秒。也就是说一次内存未命中，可能要浪费几百个周期。缓存的存在，就是为了弥合这个速度差。但缓存不是无限的，L1通常只有几十KB，L2几百KB，L3几MB到几十MB。数据一旦装不下，就必须换出部分旧数据，这就是替换策略的用武之地。

所以在设计层面，我的整体思路是：先明确数据的生命周期和访问模式，再决定如何组织数据结构，最后才谈用哪种缓存调度策略。很多人把顺序弄反了，先去折腾什么LRU、LFU参数，结果数据结构本身访问太离散，什么策略都救不了。

这里有一个关键认知：缓存调度策略的上限，取决于数据局部性的挖掘程度。你可以把数据局部性理解成“数据访问的可预测性”。如果程序访问数据像翻书一样按顺序翻，硬件预取器能轻松预测；如果访问数据像无头苍蝇一样乱跳，任何调度策略都会疲于奔命。所以算法优化中，第一步永远是分析访问模式，第二步才是选择调度策略。

举个例子，矩阵乘法是个经典问题。朴素的三重循环写法，如果内层循环访问列元素，那每一次乘加都要跨行取数，空间局部性极差。即使你把LRU换成更复杂的策略，效果也远不如把循环顺序调整一下，让内层循环按行访问来得实在。这说明什么？说明策略要服务于局部性，而不是相反。

在这个前提下，我会分几个部分来展开：核心原理的梳理、实操中怎么调整布局和循环、怎么选用调度策略、以及最后常见的坑怎么避。

2. 核心细节解析与实操要点

2.1 数据局部性原理的直观理解

时间局部性指的是：如果一个数据现在被访问，那么不久的将来它很可能再次被访问。比如循环计数器、递归中的栈顶变量，这类数据要尽量留在缓存里。空间局部性指的是：如果一个地址被访问，那么它附近的地址也很快会被访问。比如数组的顺序遍历，读第一个元素时，缓存行会同时加载相邻的十几个元素，下次访问就不用再去内存了。

这两条规则看起来简单，但放到真实代码里，稍不注意就会破坏掉。我见过一个很典型的例子：一个结构体数组，里面每个元素包括一个ID字段和一个很长的文本描述字段。程序经常做的事情是遍历所有ID做统计。如果你直接遍历结构体数组，那么每次读ID都会把整条很长的文本描述也加载到缓存行里，占用了大量宝贵的L1空间。更合理的做法是把ID抽出来单独放在一个连续数组里，遍历时只触碰ID数据。这就是数据结构设计的局部性思维。

实际排查中，我习惯先用工具确认“是不是真的存在缓存问题”，再动手改代码。比哪用某性能分析工具看硬件计数器，如果L1缓存未命中率超过一定比例，说明局部性可能很差。如果未命中率很高但总体运行时间还能接受，那说明CPU还有很多余量；如果未命中率高而且运行时间明显拖慢，那就值得专项优化。

2.2 缓存替换与调度策略的分类

缓存调度策略，简单说就是决定“哪些数据留在缓存里，哪些数据被踢出去”。最常见的替换策略有这么几种：LRU（最近最少使用），把最久没被访问的数据换出；LFU（最不频繁使用），把访问次数最少的数据换出；FIFO（先进先出），最早进入的数据换出；以及一些随机策略和适应策略。每种策略在不同场景下表现差异很大。

LRU在局部性较强的场景下表现很好，因为它天然适应“近期访问过的数据很可能再次访问”的规律。但LRU有一个比较麻烦的问题：它对偶发的扫描型访问不友好。比如你有一段代码会顺序扫一遍很大的数组，这个过程中所有数据都只访问一次，但LRU会把缓存里原本有用的热点数据挤出去，造成污染。这种情况下，LFU反而更能抵抗扫描干扰，但它需要维护访问频率计数，开销更大。

然后是预取策略。硬件预取器会尝试预测程序接下来要访问的地址，提前把数据从内存搬进缓存。对顺序访问，硬件预取往往很有效；但对随机访问，预取器基本是瞎猜。所以我们写代码的时候，尽量把访问模式变成可预测的，这比买更高级的CPU更实在。

写策略也影响调度效率。写回策略把写入操作先放在缓存里，等缓存行被换出时才写回内存，能减少内存写次数。直写策略则每次都同步写内存，简单但性能差。在绝大多数场景下，写回是默认的好选择，但要注意多处理器环境下的缓存一致性开销。

2.3 为什么局部性优化是策略调度的前置条件

这个关系很好理解。缓存大小是有限的，调度策略只能决定“在同一批竞争缓存的数据里谁去谁留”，但无法决定“哪些数据该进入缓存”。你能决定进入缓存的数据集大小和顺序，这才是局部性优化的作用。

拿一个搜索类算法来说，如果你把热门的键值数据放在一个哈希表里，哈希表本身的空间局部性就不好，因为键经过哈希函数映射后，在内存里分布得很随机。这种情况下，即使用最聪明的调度策略，缓存命中率也上不去。但如果换成一种局部性友好的哈希结构——比如把哈希桶组织成连续内存块，或者用开放寻址法代替链地址法——访问路径就变得更加紧凑，调度策略才能真正发挥作用。

我做一个性能对比实验时常常这样设计：同一份业务逻辑，A版本只调整数据布局，B版本只更换调度策略，C版本两者都做。结果往往显示，A版本的提升本身就比B版本明显，C版本达到最优。这个经验让我后来在工作里养成了习惯：先谈数据布局，再谈调度策略，最后才是微调参数。

3. 实操过程与核心环节实现

3.1 以矩阵乘法为例的局部性优化实战

我一直觉得矩阵乘法是讲缓存优化的最好例子，因为它的数据访问模式很容易凸显局部性问题。假设我们有两个N×N的矩阵A和B，计算A乘以B的结果矩阵C。朴素的三层循环一般长这样：

// 未优化版本 for (int i = 0; i < N; i++) { for (int j = 0; j < N; j++) { float sum = 0; for (int k = 0; k < N; k++) { sum += A[i][k] * B[k][j]; } C[i][j] = sum; } }

这个版本的问题在于B[k][j]的访问。内层循环变化的是k，所以B是按列访问的。对C语言这种按行优先存储的语言来说，列访问意味着每次都要跳到很远的地址，每一行可能只有几个元素在同一条缓存行里，空间局部性非常差。结果就是每次读B元素都大概率缓存未命中，性能惨不忍睹。

一个常见的优化是调整循环顺序，把i、j、k的顺序换成i、k、j，让最内层循环遍历B的一行：

// 初版优化 for (int i = 0; i < N; i++) { for (int k = 0; k < N; k++) { float r = A[i][k]; for (int j = 0; j < N; j++) { C[i][j] += r * B[k][j]; } } }

这一版中，B是严格按行访问，空间局部性改善明显。但还有一个问题：最内层循环对C[i][j]做连续更新，C的行也能被缓存行覆盖，整体效果已经比朴素版好很多。可这还谈不上最优，因为当N特别大时，A和B的尺寸都远远超过L2甚至L3缓存，导致循环中反复从内存取值。

更进一步的优化是矩阵分块。把矩阵分成小块，让小块数据在参与计算时能完整放在缓存里，这样每次加载的数据都能被多次复用，充分利用时间局部性。块大小要根据你的CPU缓存容量来选，一般L2或L3容量的三分之一到二分之一比较合适，既保证块能装进缓存，又不至于因为块太小而增加循环开销。我实际偏好的块大小在32×32到128×128之间，具体要实测。

// 分块优化示意 #define BLOCK_SIZE 64 for (int i0 = 0; i0 < N; i0 += BLOCK_SIZE) { for (int k0 = 0; k0 < N; k0 += BLOCK_SIZE) { for (int j0 = 0; j0 < N; j0 += BLOCK_SIZE) { for (int i = i0; i < i0 + BLOCK_SIZE; i++) { for (int k = k0; k < k0 + BLOCK_SIZE; k++) { float r = A[i][k]; for (int j = j0; j < j0 + BLOCK_SIZE; j++) { C[i][j] += r * B[k][j]; } } } } } }

实际跑下来，这种分块版本的性能相比朴素版通常有翻倍甚至更多的提升。原因就是数据在小块内被反复使用，L1缓存命中率大幅提高，硬件预取器也能很好地识别顺序访问模式。注意我在最内层循环中依然保持了B[k][j]的连续访问，这是空间局部性的核心。

有人可能会问，既然循环换序就能提升这么多，为什么还要分块？因为当矩阵尺寸超过缓存容量时，行序遍历也救不了全部。分块让每次参与计算的数据子集变小，更精准地匹配缓存大小。反过来，如果矩阵本身很小，分块反而会带来额外的循环开销，不如直接循环换序来得简单。实操中我会先测数据规模，再决定要不要上分块。

3.2 数据结构重设计提升缓存命中率

除了矩阵这类数值计算，业务代码里的缓存优化往往从数据结构开始。链表是典型的缓存不友好结构，每个节点散落在内存各处，遍历一次就要走很多次内存访问。我曾经在处理一个日志系统时，把链表改成动态数组加索引的方式，吞吐量直接翻了一倍。原理很简单：动态数组在内存中是连续存放的，遍历时缓存能装进多个元素。

但数组也有缺点，中间插入和删除是O(n)操作。实际工程中要根据读写比例来做取舍。如果读多写少，优先用数组；如果写很频繁而且元素位置变动大，可以用块状链表或者“数组池+空闲列表”的混合结构。数组池的思路是分配一大块内存，节点对象从池里分配，保证同批次创建的数据在物理位置上尽量靠近，遍历时缓存命中率显著提升。

结构体拆分也是我常用的手法。如果一个结构体里包含一个经常需要扫描的短字段和一个很少碰到的长字段，把它们拆成两个平行数组：短字段数组和长字段数组。扫描短字段时，缓存里不会混入很多无用的长字段数据。看起来是字节粒度的调整，但对缓存命中率的影响是数量级的。

还有一个小细节是对齐。CPU加载缓存行是按对齐地址来的，一般是64字节。如果你的关键字段正好跨在两条缓存行边界上，一次读取可能要访问两次内存。解决办法是给结构体增加填充字节，强制让字段对齐到缓存行边界。C语言里可以用对齐属性，Java里可以用填充字段。这个操作从代码上看很蠢，但效果很直接。

3.3 缓存调度策略的工程配置要点

当你确定了数据布局和访问模式后，缓存调度策略就变成参数配置问题了。但这里的“策略”其实不只是替换算法，还包括预取策略、写策略和QoS优先级设置。

在较新的CPU上，很多缓存行为是不需要软件干预的，硬件会自动调整。但嵌入式场景或者实时性要求较高的场景下，配置缓存策略的空间更大。比如有些架构支持按页锁定缓存，让关键的DMA缓冲区留在缓存里不被换出。或者支持设置某个内存区域的缓存属性为不缓存、写通、写回等模式。

对于调度策略的选择，我的经验是：识别你的程序属于哪种访问模式。如果是流式处理，数据只用一次就走，适合开放预取和流式检测，甚至可以把数据标记为“non-temporal”以绕过缓存污染。如果是热数据处理，数据会反复访问，就适合尽量加大缓存的保留时间，防止被其他数据挤掉。

替换策略这块，多数CPU硬件已经内置了相当好的算法，比如类LRU的近似实现。普通应用程序很难直接控制硬件用哪种替换算法，但这不代表我们不能做点什么。通过软件预取指令，我们可以提前把数据加载到缓存里，让数据在需要时刚刚好命中。又或者通过缓存分区和锁缓存，实现对关键数据段的“硬件级保护”。

我在一次网络包处理任务里，发现大量连接状态数据被频繁访问，但偶尔也会有超大流量的顺序扫描把缓存冲掉。后来我在更新这些连接时用了一种“boot-loop”式的访问模式优化，把活跃连接按最近活跃时间排序，每次只更新头部的一小部分，既保证了时间局部性，又避免了扫描污染。这本质上就是用软件方式引导硬件调度。

3.4 调优实验设计与性能对比

优化不能靠感觉，必须要有一个可复现的实验流程。我的标准做法是：准备三个版本的实现，一个是基线版（朴素实现）、一个只做数据布局优化、一个布局加调度联合优化。每个版本运行多轮，取中位数而不是平均值，避免偶发调度抖动。

测量的指标至少包括：运行时间、L1缓存命中率、LLC（最后一级缓存）未命中率、分支预测未命中率。我一般会先看LLC未命中率，因为LLC未命中意味着真的要去内存走一趟，这是最痛的开销。如果LLC未命中率已经很低，再优化局部性可能收益有限，不如去查其他瓶颈比如锁竞争或者IO。

一个常见的误区是单独比较“缓存命中率”这个数字。命中率高不一定代表运行时间短，因为不同数据的大小不同，命中L1和命中L2的代价也不同。更科学的做法是结合cycles per instruction和内存停顿周期来看。如果CPI接近理论值，说明内存子系统已经不是瓶颈，就没必要继续折腾缓存参数。

具体到矩阵乘法的调优实验，我会固定N=1024，先用基线版跑一遍，再跑循环换序版，最后跑分块版。记录各自的时间和LLC未命中率。快照下来几乎总是看到：基线版未命中率很高，换序版降低了一些，分块版降到很低。这个实验过程本身就很有教学意义，能直观展示局部性优化的力量。

4. 常见问题与排查技巧实录

4.1 优化后性能反降的典型案例

有时候数据布局优化做完了，性能反而变差，这是很打击人的。我见过不少情况是：为了追求局部性，把代码写得高度复杂，比如做了很细的分块但块之间循环嵌套太深，导致指令缓存（I-cache）压力过大。指令的局部性同样重要，代码体积过大会让预取和分支预测崩溃。

另一个常见坑是过度对齐。前面说对齐字段到缓存行边界能避免跨行访问，但如果每个结构体都填充到64字节，而实际上大部分字段只有十几个字节，那么在缓存里能容纳的对象数量就会大幅减少。缓存行是固定大小的，填充越多，有效数据占比越低，反而降低了有效缓存容量。实际操作中，只有被高频访问且频繁碰边界的字段才值得对齐，不要无脑填充。

性能反降还有一个容易被忽略的原因：多线程下的伪共享。两个线程各自修改不同变量，如果这两个变量恰好在同一条缓存行里，那么每次任何一方写入，都会导致这条缓存行在多个核之间来回失效，性能会急剧下降。解决方式是在变量之间填充隔离，让它们落进不同的缓存行。

4.2 缓存未命中率居高不下的排查流程

遇到缓存未命中率高，我习惯按顺序排查：先看数据是否过大而无法装进任意一级缓存，再检查是不是数据结构导致跳跃访问太严重，接着看有没有被周期性的大批量扫描污染缓存，最后考虑是不是锁竞争让多核缓存同步开销变大。

举个实际案例。一个学生项目里，A同学处理大规模的图数据，用的邻接表结构存储图边。每次遍历某个顶点的邻居时，都需要跳到一个不连续的内存位置，导致缓存命中率很低。他的原始做法是不断优化遍历算法，但效果有限。后来我建议把邻接表改成邻接矩阵的稀疏行压缩格式，即把所有邻居的ID紧凑存放在一个连续数组里，然后再按顶点偏移访问。这样改完之后，遍历邻居的操作变成了顺序访问一段紧凑内存，缓存命中率立刻改善了。这就是典型的“访问模式决定性能天花板”。

4.3 调度策略参数不当导致的隐蔽性能问题

有些系统允许你配置预取距离或者预取类型，配置不当也会出问题。预取太激进会把大量数据提前搬到缓存里，挤占真正需要的数据；预取太保守又跟不上访问速度。我经历过一个场景：程序在单线程下表现良好，多线程下反而变慢。后来发现是硬件预取器在多线程并行顺序访问不同区域时，频繁做出错误预测，导致缓存行无效颠簸。解决办法之一是让不同线程按更大的间隔分开处理不同的数据段，减少地址交集，给预取器更清晰的信号。

写策略这块，如果启用了非临时写或流式写，但数据实际上会被很快重复读取，那就得不偿失。我调试过一个人工智能推理框架，它在某些权重矩阵初始化时使用流式写入，后面推理阶段却需要反复读取这些权重。结果流式写入让权重根本没留在缓存里，后续每次推理都要重新从内存加载。改成普通写回策略后，整体性能提升非常明显。这告诉我们：调度策略不是越激进越好，关键是匹配数据生命周期。

关于伪共享导致的“看不见的慢”，我再补充一个自己的经历。有一次优化一个计费系统的并发模块，明明把锁拆细了，并发上去了，但总吞吐没提升。反复排查后发现，多个线程计费时频繁更新一个全局状态变量，而这个变量和另一个线程独有的变量被放进了同一条缓存行，两个线程互相拖累，导致缓存行在核心之间不断“旅行”。解决办法就是在变量之间加padding，或者用线程本地变量做合并后再定期同步到全局。这个坑特别隐蔽，没有计数器工具很难发现。

5. 工具选型与方法论沉淀

5.1 性能分析工具和硬件计数器怎么用

工欲善其事，必先利其器。我在定位缓存问题时，最常用的工具是Linux下的perf工具和处理器自带的硬件计数器。perf可以统计cache-misses、cache-references、branch-misses这些硬件事件，还能进一步细分到L1、L2和LLC的未命中情况。用法很简单，类似这样：

perf stat -e cache-misses,cache-references,L1-dcache-load-misses ./your_program

输出会给出每千条指令的未命中次数和百分比，用这些数字就能快速判断缓存瓶颈到底有多严重。如果cache-misses相对于cache-references比例很高，说明程序局部性很差；如果比例还行但总体运行时间很长，可能需要看看是不是其他子系统瓶颈。

除了perf，我也推荐用一些抓取访存轨迹的调试工具，它们能可视化你程序的内存访问模式，直观看到访问是聚集还是跳跃。这类工具适合定位那些数据结构设计糟糕导致的问题，连代码都不太需要看，光看图就能找到访问热点。缺点是插桩会带来很大开销，不适合跑大规模数据，只适合小数据集上的精确定位。

5.2 调优方法论：先约束问题，再动手优化

做了很多年优化后，我总结出一个原则：先做“瓶颈确认”，再做“方案选择”，最后才做“代码修改”。不要一上来就重写数据结构或者调整循环顺序，先搞清楚瓶颈是不是真的在缓存子系统。方法很简单，运行一遍程序，看LLC未命中率和CPI。如果LLC未命中率不高，却仍然觉得慢，那问题可能是锁竞争、系统调用开销或者IO，你再怎么调缓存布局都是白费功夫。

一旦确认缓存是瓶颈，再考虑是局部性问题还是调度策略问题。判断方法也直接：把数据尺寸缩小到能完全放进L2缓存，看性能是否大幅提升。如果是，说明问题是容量主导，优先做数据布局优化减少数据占用；如果不是，说明可能是访问模式太跳跃，重点要放在重组访问顺序上。

这个方法论的核心是“用数据说话”。优化工作最忌讳凭感觉改，改完跑一次觉得快了就觉得成功，其实可能是噪声造成的波动。我每次改动都会固定运行环境，关掉后台任务，多跑几轮取中位值，并且对比被统计的命中率指标。只有在同样的条件下产生了一致性的性能差异，我才会认为这个优化是有效的。

5.3 一些提高局部性的代码审查清单

我把日常写代码时会检查的局部性要点整理成一份清单，每次做技术评审或者自查时都会过一遍。首先，看频繁访问的字段是否在结构体里排列得紧凑，是否可以把大字段拆分出去。第二，看循环的最内层是否在跳着访问数组，如果步长大于缓存行大小，就要考虑布局变换。第三，看是否有大数组被整体扫描后随后又被随机访问，如果有，可以考虑分批处理或者分区缓存。第四，看多线程环境中共享数据的更新频率，防止伪共享。

这份清单不复杂，但每次照着查一遍，基本能找出大部分的性能隐患。我常常和一些开发者交流，发现很多人知道缓存机制，却很少在写代码时主动去检查这些点，等到性能出问题了才回头补救。与其事后调优，不如一开始就养成局部性友好型的编码习惯。更妙的是，这些习惯在代码评审里很容易落地，大家讨论的是具体的数据布局和循环顺序，而不是玄学性能。

有人担心这样写代码会很累，其实习惯之后成本并不高。比如写一个循环之前，先问一句“最内层访问是否连续”，写一个结构体之前，先问一句“大字段会不会影响缓存效率”。成本就这几秒钟，省下的却是后续无尽的性能排查时间。这句话我已经跟很多同事说过，真正养成了习惯的人，后来都不再害怕性能优化任务。

6. 生态联动与后续进阶方向

数据局部性优化不是孤立的技术，它和其他很多方面是联动的。当你把算法的访存模式理顺了，下一步可以考虑向量化优化，比如让数据对齐后使用SIMD指令一次处理多个元素。向量化对数据对齐和连续布局的要求，和缓存局部性的要求是一致的。所以先做数据布局优化，通常也会为向量化铺平道路。

多线程优化也是如此。如果你把数据拆分成连续的分块，每个线程处理一个块，那么不仅缓存局部性得到改善，线程之间的同步开销也自然降低。因为每个线程访问的数据在物理上更为独立，伪共享概率低，缓存一致性协议带来的性能损失也会减少。这种“拆分思想”和数据局部性最优的方法是天然匹配的。

再往后延伸，类似的思想也能应用在数据库索引设计里。聚簇索引就是把逻辑上相邻的记录尽量存储在物理相邻的位置，这本质上就是一种空间局部性设计。而数据库的缓冲池替换策略，也和缓存调度策略非常相似，比如经典的LRU算法在数据库场景下也会遇到扫描污染问题，于是有人提出LRU-K或2Q这类改进策略。理解了数据局部性和缓存调度策略的本质，你会在很多完全不同的技术栈里看到同样的影子。

我在处理大数据任务时，也常常用局部性思维去设计数据管道。比如把同一个批次的数据聚拢在一起处理，而不是全量拉取后再按业务维度去访问，这样磁盘IO和网络IO都能得到明显改善。局部性这个概念，实际上影响的是从CPU缓存、内存、磁盘到分布式系统的整个存储层级。越早形成这种思维，做底层系统优化就越得心应手。

所以别把这篇内容只当成缓存调参的小技巧。它背后的核心思想是：在任何计算机系统里，数据移动的成本远高于计算成本。想要算法性能好，就必须让数据离计算单元更近，并让数据的访问路径尽可能有序。这个思想，在单核CPU有效，在多核CPU有效，在大规模分布式集群里同样有效。

我的实操体会

写到这里，我还是想分享一点比较个人的感受。数据局部性和缓存调度策略这一类优化，很多时候不像算法复杂度优化那样能给出一个绝对的理由，它更像是和硬件打交道，充满了实测和经验法则。同一个优化方案，换一个处理器代数效果可能截然相反。所以不要迷信任何权威结论，包括我上面写的那些经验数字，关键还是形成自己的分析流程和实验习惯。

我在实际做项目时，最管用的方法其实就是把问题标准化：确认瓶颈、设计对比实验、读取硬件计数器、用数据判断。这听起来没那么酷，但比任何花哨的优化技巧都可靠。某种程度上，缓存优化的难度不是做出某个改动，而是确认这个改动到底值得不值得做。

另外，我也强烈建议新手从矩阵乘法这种简单案例入手，亲手跑一遍基线版和优化版的性能对比。当你亲眼看到同一个算法，仅仅因为循环顺序和数据布局不同，运行时间差出一倍多，那种震撼比读任何书都来得深刻。从那一刻起，你写代码时会下意识地去思考数据是怎么流动的，而不是只关心逻辑对不对。

最后说一个小技巧：如果实在无法判断数据局部性好不好，有一个很笨但有效的办法——把程序的数据规模缩小到远小于L2缓存，再跑一次任务，如果性能提升巨大，说明数据完全是在跟容量作斗争。如果性能几乎不变，那就说明瓶颈根本不在缓存，不用白费力气去优化布局了。这个办法简单粗暴，但真的能帮你省去很多无谓的埋头苦干。