关于C#：malloc()/ free()的对齐限制

我读过的较早的K＆R(第二版)和其他C语言文本讨论了以malloc()和free()样式实现动态内存分配器的实现，通常还附带提到了有关数据类型对齐限制的内容。 显然，某些计算机硬件体系结构(CPU，寄存器和内存访问)限制了您存储和寻址某些值类型的方式。 例如，可能要求必须从4的倍数的地址开始存储4字节(long)整数。

主要平台(英特尔和AMD，SPARC，Alpha)对内存分配和内存访问施加什么限制(如果有)，或者我可以安全地忽略在特定地址边界上对齐内存分配吗？

Sparc，MIPS，Alpha和大多数其他"经典RISC"架构仅允许对内存进行对齐访问，即使在今天。不对齐的访问将导致异常，但是某些操作系统将通过使用较小的加载和存储从软件中的所需地址进行复制来处理该异常。应用程序代码不会知道有问题，只是性能会很差。

MIPS具有特殊指令(lwl和lwr)，可用于从未对齐的地址访问32位量。只要编译器可以告知地址可能未对齐，它将使用这两个指令序列而不是常规的lw指令。

x86可以毫无例外地处理硬件中未对齐的内存访问，但是与对齐访问相比，x86的性能仍然高达3倍。

乌尔里希·德雷珀(Ulrich Drepper)就此主题以及其他与内存相关的主题写了一篇详尽的论文，每个程序员应该了解的内存{ / AA}。这是一篇很长的文章，但充满耐嚼性。

对齐在今天仍然非常重要。如果您尝试访问奇数边界上的字值，则某些处理器(68k系列产品会引起人们的注意)会引发异常。如今，大多数处理器将运行两个内存周期来获取未对齐的字，但这肯定比对齐的获取要慢。其他一些处理器甚至不会抛出异常，但是会从内存中获取不正确的值！

如果除了性能以外，没有其他原因，明智的做法是尝试遵循处理器的对齐方式首选项。通常，您的编译器会处理所有细节，但是如果您在自己布置内存结构的地方做任何事情，那么值得考虑。

请注意，即使在IA-32和AMD64上，某些SSE指令/本性也需要对齐的数据。如果数据未对齐，这些说明将引发异常，因此至少您不必调试"错误的数据"错误。也有等效的未对齐指令，但是像Denton所说的那样，它们的速度较慢。

如果您使用的是VC ++，那么除了#pragma pack指令之外，您还可以使用__declspec(align)指令进行精确对齐。 VC ++文档还提到了针对特定对齐要求的__aligned_malloc函数。

根据经验，除非您跨编译器/语言移动数据或使用SSE指令，否则您可能会忽略对齐问题。

正如Greg所提到的，它在今天仍然很重要(也许在某些方面甚至更重要)，并且编译器通常会根据体系结构的目标来进行对齐。在托管环境中，JIT编译器可以基于运行时体系结构优化对齐方式。

您可能会看到pragma指令(在C / C ++中)会更改对齐方式。仅在需要非常特定的对齐方式时才应使用此选项。

在C(++)中布置类或结构时，您仍然需要注意对齐问题。在这些情况下，编译器将为您做正确的事情，但是struct / class的整体大小可能比必要的浪费更多

例如：

大小为4 * 4 = 16字节(假设Windows在x86上)

大小为4 * 3 = 12个字节。

这是因为编译器对整数强制执行4字节对齐，而对char强制执行1字节对齐。

通常，相同大小(类型)的pack成员变量在一起，以最大程度地减少浪费的空间。