你可以使用一些处理器(nehalem可以这样做)，但以前所有的内存访问都是在64位(或32位)行上对齐的，因为总线是64位宽的，你必须一次获取64位，并且在对齐的64位“块”中获取这些要容易得多。

如果你想获取一个字节，你获取64位块，然后屏蔽掉你不想要的位。如果您的字节位于右端，这很简单，也很快速，但如果它位于64位块的中间，则必须屏蔽不需要的位，然后将数据转移到正确的位置。更糟糕的是，如果您想要一个2字节的变量，但它被分成了2个块，那么这就需要双倍的内存访问。

因此，当每个人都认为内存很便宜时，他们只是让编译器在处理器的块大小上对齐数据，这样你的代码以浪费内存为代价运行得更快更有效。

现代处理器上的内存子系统仅限于按其字大小的粒度和对齐方式访问内存;出现这种情况的原因有很多。

速度

现代处理器有多层高速缓存，数据必须通过这些缓存读取;支持单字节读取将使内存子系统的吞吐量与执行单元的吞吐量紧密绑定(又名cpu绑定);这一切都让人联想到，在硬盘驱动器中，由于许多相同的原因，DMA模式是如何超越PIO模式的。

CPU总是按它的字大小读取(32位处理器上是4字节)，所以当你在支持它的处理器上进行未对齐地址访问时，处理器将读取多个字。CPU将读取请求地址横跨的内存中的每个字。这将导致访问所请求数据所需的内存事务数增加到2倍。

因此，读取两个字节很容易比读取四个字节慢。例如，你在内存中有一个结构体，它看起来像这样:

struct mystruct {
    char c;  // one byte
    int i;   // four bytes
    short s; // two bytes
}

在32位处理器上，它很可能像下面所示的那样对齐:

处理器可以在一个事务中读取这些成员。

假设你有一个结构的打包版本，可能是从网络中打包的，它是为了传输效率;它可能看起来像这样:

读取第一个字节是一样的。

当你要求处理器从0x0005中给你16位时，它将不得不从0x0004中读取一个字，并左移1字节，将其放入16位寄存器;一些额外的工作，但大多数人可以在一个周期内处理。

当您从0x0001请求32位时，您将得到2X放大。处理器将从0x0000读入结果寄存器并左移1字节，然后再次从0x0004读入临时寄存器，右移3字节，然后将其与结果寄存器OR。

范围

For any given address space, if the architecture can assume that the 2 LSBs are always 0 (e.g., 32-bit machines) then it can access 4 times more memory (the 2 saved bits can represent 4 distinct states), or the same amount of memory with 2 bits for something like flags. Taking the 2 LSBs off of an address would give you a 4-byte alignment; also referred to as a stride of 4 bytes. Each time an address is incremented it is effectively incrementing bit 2, not bit 0, i.e., the last 2 bits will always continue to be 00.

这甚至会影响系统的物理设计。如果地址总线需要少2位，那么CPU上可以少2个引脚，电路板上也可以少2个走线。

原子性

CPU可以原子地操作一个对齐的内存字，这意味着没有其他指令可以中断该操作。这对于许多无锁数据结构和其他并发范例的正确操作至关重要。

结论

处理器的内存系统比这里描述的要复杂和复杂得多;关于x86处理器如何实际处理内存的讨论可能会有所帮助(许多处理器的工作方式类似)。

在这篇IBM文章中，您可以读到坚持内存对齐的更多好处。

计算机的主要用途是转换数据。现代内存架构和技术已经经过了几十年的优化，以便以高度可靠的方式在更多更快的执行单元之间获取更多数据。

好处:缓存

我前面提到的另一种为性能而调整的方法是对缓存线进行调整(例如，在某些cpu上)。

要了解更多关于利用缓存可以获得多少性能的信息，请查看处理器缓存效果画廊;从这个关于缓存线大小的问题

理解缓存线对于某些类型的程序优化是很重要的。例如，数据的对齐方式可以决定一个操作是涉及一条还是两条缓存线。正如我们在上面的例子中看到的，这很容易意味着在不对齐的情况下，操作将慢一倍。

你可以使用一些处理器(nehalem可以这样做)，但以前所有的内存访问都是在64位(或32位)行上对齐的，因为总线是64位宽的，你必须一次获取64位，并且在对齐的64位“块”中获取这些要容易得多。

如果你想获取一个字节，你获取64位块，然后屏蔽掉你不想要的位。如果您的字节位于右端，这很简单，也很快速，但如果它位于64位块的中间，则必须屏蔽不需要的位，然后将数据转移到正确的位置。更糟糕的是，如果您想要一个2字节的变量，但它被分成了2个块，那么这就需要双倍的内存访问。

因此，当每个人都认为内存很便宜时，他们只是让编译器在处理器的块大小上对齐数据，这样你的代码以浪费内存为代价运行得更快更有效。

If a system with byte-addressable memory has a 32-bit-wide memory bus, that means there are effectively four byte-wide memory systems which are all wired to read or write the same address. An aligned 32-bit read will require information stored in the same address in all four memory systems, so all systems can supply data simultaneously. An unaligned 32-bit read would require some memory systems to return data from one address, and some to return data from the next higher address. Although there are some memory systems that are optimized to be able to fulfill such requests (in addition to their address, they effectively have a "plus one" signal which causes them to use an address one higher than specified) such a feature adds considerable cost and complexity to a memory system; most commodity memory systems simply cannot return portions of different 32-bit words at the same time.

从根本上讲，这是因为内存总线有一些特定的长度，它比内存大小小得多。

因此，CPU从芯片上的L1缓存中读取，现在通常是32KB。但是连接L1缓存到CPU的内存总线的缓存线宽度要小得多。这将是128位的数量级。

So:

262,144 bits - size of memory
    128 bits - size of bus

未对齐的访问偶尔会重叠两条缓存线，这将需要一个全新的缓存读取来获取数据。它甚至可能会错过到DRAM中。

此外，CPU的某些部分将不得不倒立起来，从这两条不同的缓存线中拼凑出一个单独的对象，每条缓存线都有一块数据。在一行上，它是非常高阶的位，在另一行上，它是非常低阶的位。

将会有专门的硬件完全集成到管道中，处理将对齐的对象移动到CPU数据总线的必要位上，但是对于未对齐的对象可能缺乏这样的硬件，因为使用这些晶体管来加速正确优化的程序可能更有意义。

在任何情况下，无论有多少特殊用途的硬件(假设的和愚蠢的)致力于修补错位的内存操作，有时必要的第二次内存读取都会减慢管道。

@joshperry has given an excellent answer to this question. In addition to his answer, I have some numbers that show graphically the effects which were described, especially the 2X amplification. Here's a link to a Google spreadsheet showing what the effect of different word alignments look like. In addition here's a link to a Github gist with the code for the test. The test code is adapted from the article written by Jonathan Rentzsch which @joshperry referenced. The tests were run on a Macbook Pro with a quad-core 2.8 GHz Intel Core i7 64-bit processor and 16GB of RAM.