对于L2缓存来说，
第一次获取数据 a11（“1”）的时候其实是没有数据的，所以会耗时去把 a11，a12，a13（“1，2，3”）都取回来缓存起来。
当第二次取 a12、a13的时候候就直接从L2缓存取了。这样 cache 命中率就是 66.7%.
对于L3的情况类似。
这样的遍历方式对于CPU来说是一个很友好且高效的。
C代码块 就是这种横向优先的访问方式。
A代码块 里面对 arrays_A 的方式是横向优先遍历的，但是在处理 arrays_B 的时候就是纵向遍历的（也就是下面即将提到的方式）。
B代码块 所有的访问都是纵向的（不友好的遍历方式）。因为发挥不出CPU缓存的效果，所以性能最差。
2.2.2 不友好的遍历方式
从上到下，再从左到右。
为啥这是一个不好的遍历方式呢？
这个得结合上一节Java的二维数组的存储结构一起看。再来回顾一下：
从上面的存储的结构图来看，其实 a11，a12，a13 与 a21，a22，a23 行与行之间并不是连续的。所以对于L1、L2、L3缓存来说很有可能是不能一起被缓存的（这里用了可能，具体得看L1、L2、L3的容量和数组的大小）。虽然是可能，但是通常都不会一起出现。
有了这个知识之后，我们再来看，先从上到下，再从左到右的顺序的缓存命中率。
第一次，获取 a11，但是缓存里面没有，找到 a11 之后就把 a11，a12，a13 缓存下来了。
第二次，获取 a21，但是缓存里面没有，找到 a21 之后就把 a21，a22，a23 缓存下来了，假设有CPU有两行的缓存空间。
第三次，获取 a31，但是缓存里面没有，找到 a31 之后把 a31，a32，a33 缓存下来，并且把 a11，a12，a13 替换掉（缓存的空间有限，虽然具体的替换策略有很多种，并且还和数据本身的Hash有关系，这里就假设把第一次的结果覆盖了）。
后面的逻辑重复之前的步骤。最后得到的缓存命中率就是 0% 。
结合文章开头的缓存速率表格，我们就不难发现，如果我们每次都不命中缓存的话，那么延迟带来的耗时将会相差一个数量级。
