Java 数据对齐与缓存位置

从内存中，只能以体系结构的自然字大小读取数据。例如，在32位系统上，数据以4字节块的形式从内存中读取。如果将2字节或1字节的值添加到内存中，它们的读取仍然需要访问4字节的字。（对于2字节值，如果该值存储在字边界上，则可能需要两次4字节访问。）

因此，当需要访问单个字时，访问单个值的速度最快，并且需要最少的额外工作（如屏蔽）。如果我是正确的，这就是虚拟机（如JVM或Android的Dalvik）在

Object

实例中以4字节边界布置成员变量的原因

另一个概念是缓存友好性，即局部性（如L1、L2）。如果许多值必须在彼此之后直接进行遍历/处理，则将它们存储在彼此靠近的位置（理想情况下，存储在连续块中）是有益的。这是空间局部性。如果这是不可能的，至少对相同值的操作应该在相同的时间段内完成（时间局部性——即，在对其执行操作时，该值很有可能保留在缓存中）

就我所见，上述两个概念在某些情况下可能是“矛盾的”，它们之间的选择取决于它们的使用场景。例如，较小数量的连续数据比较大数量（微不足道）的数据更便于缓存，但是如果通常需要对某些数据进行随机访问，则单词对齐（但大小更大）结构可能是有益的--除非整个结构适合缓存。因此，我认为，应该优先考虑局部性（~数组）还是对齐好处，这取决于如何操纵这些值

---

有一个场景对我来说很有趣：让我们假设一个寻路算法，它接收作为数组的输入图（和其他辅助结构）。（如果您可以确保移动到较短的位置（即所有内容都在缓存中）会导致显著更好的位置，那么它的大多数输入数组存储的值都是，这超过了对齐的代价

对缓存的访问处于低纳米级