c内存对齐--影响php变量占用的内存

        当在C中定义了一个结构类型时，它的大小是否等于各字段(field)大小之和？编译器将如何在内存中放置这些字段？ANSI C对结构体的内存布局有什么要求？而咱们的程序又可否依赖这种布局？这些问题或许对很多朋友来讲还有点模糊，那么本文就试着探究它们背后的秘密。

       

        首先，至少有一点能够确定，那就是ANSI C保证结构体中各字段在内存中出现的位置是随它们的声明顺序依次递增的，而且第一个字段的首地址等于整个结构体实例的首地址。好比有这样一个结构体：

   

struct vector{ 
    int x,y,z; 
} s; 
int *p,*q,*r; 
struct vector *ps;

p = &s.x;
q = &s.y;
r = &s.z;
ps = &s;

assert(p < q);
assert(p < r);
assert(q < r);
assert((int*)ps == p);
// 上述断言必定不会失败

    这时，有朋友可能会问:"标准是否规定相邻字段在内存中也相邻?"。 唔，对不起，ANSI C没有作出保证，你的程序在任什么时候候都不该该依赖这个假设。那这是否意味着咱们永远没法勾勒出一幅更清晰更精确的结构体内存布局图？哦，固然不是。不过先让咱们从这个问题中暂时抽身，关注一下另外一个重要问题————内存对齐。

    许多实际的计算机系统对基本类型数据在内存中存放的位置有限制，它们会要求这些数据的首地址的值是某个数k(一般它为4或8)的倍数，这就是所谓的内存对齐，而这个k则被称为该数据类型的对齐模数(alignmentmodulus)。

    当一种类型S的对齐模数与另外一种类型T的对齐模数的比值是大于1的整 数，咱们就称类型S的对齐要求比T强(严格)，而称T比S弱(宽松)。这种强制的要求

    一来简化了处理器与内存之间传输系统的设计，

    二来能够提高读取数据的速度。

    好比这么一种处理器，它每次读写内存的时候都从某个8倍数的地址开始，一次读出或写入8个字节的数据，假如软件能保证double类型的数据都从8 倍数地址开始，那么读或写一个double类型数据就只须要一次内存操做。不然，咱们就可能须要两次内存操做才能完成这个动做，由于数据或许刚好横跨在两个符合对齐要求的8字节内存块上。某些处理器在数据不知足对齐要求的状况下可能会出错，可是Intel的IA32架构的处理器则无论数据是否对齐都能正确 工做。不过Intel奉劝你们，若是想提高性能，那么全部的程序数据都应该尽量地对齐。

    Win32平台下的微软C编译器(cl.exe for 80x86)在默认状况下采用以下的对齐规则: 任何基本数据类型T的对齐模数就是T的大小，即sizeof(T)。好比对于double类型(8字节)，就要求该类型数据的地址老是8的倍数，而 char类型数据(1字节)则能够从任何一个地址开始。

    Linux下的GCC奉行的是另一套规则(在资料中查得，并未验证，如错误请指正):任何2字节 大小(包括单字节吗?)的数据类型(好比short)的对齐模数是2，而其它全部超过2字节的数据类型(好比long,double)都以4为对齐模数。

    如今回到咱们关心的struct上来。ANSI C规定一种结构类型的大小是它全部字段的大小以及字段之间或字段尾部的填充区大小之和。嗯？填充区？对，这就是为了使结构体字段知足内存对齐要求而额外分 配给结构体的空间。那么结构体自己有什么对齐要求吗？有的，ANSI C标准规定结构体类型的对齐要求不能比它全部字段中要求最严格的那个宽松，能够更严格(但此非强制要求，VC7.1就仅仅是让它们同样严格)。咱们来看一 个例子(如下全部试验的环境是Intel Celeron 2.4G + WIN2000 PRO + vc7.1，内存对齐编译选项是"默认"，即不指定/Zp与/pack选项):

typedef struct ms1
{
char a;
int b;
} MS1;

    假设MS1按以下方式内存布局(本文全部示意图中的内存地址从左至右递增):
     

_____________________________
            |       |                   |
            |   a   |        b          |
            |       |                   |
            +---------------------------+
 Bytes:         1             4

    由于MS1中有最强对齐要求的是b字段(int)，因此根据编译器的对齐规则以及ANSI C标准，MS1对象的首地址必定是4(int类型的对齐模数)的倍数。那么上述内存布局中的b字段能知足int类型的对齐要求吗？嗯，固然不能。若是你是编译器，你会如何巧妙安排来知足CPU的癖好呢？呵呵，通过1毫秒的艰苦思考，你必定得出了以下的方案：

     

_______________________________
           |       |         |           |
           |   a   | padding |    b      |
           |       |         |           |
           +-----------------------------+
Bytes:       1         3          4

    这个方案在a与b之间多分配了3个填充(padding)字节，这样当整个struct对象首地址知足4字节的对齐要求时，b字段也必定能知足int型的 4字节对齐规定。那么sizeof(MS1)显然就应该是8，而b字段相对于结构体首地址的偏移就是4。很是好理解，对吗？如今咱们把MS1中的字段交换 一下顺序:

typedef struct ms2
{
int a;
char b;
} MS2;

    或许你认为MS2比MS1的状况要简单，它的布局应该就是

     

_______________________
           |             |       |
           |     a       |   b   |
           |             |       |
           +---------------------+
Bytes:           4           1

    由于MS2对象一样要知足4字节对齐规定，而此时a的地址与结构体的首地址相等，因此它必定也是4字节对齐。嗯，分析得有道理，但是却不全面。让咱们来考 虑一下定义一个MS2类型的数组会出现什么问题。C标准保证，任何类型(包括自定义结构类型)的数组所占空间的大小必定等于一个单独的该类型数据的大小乘以数组元素的个数。换句话说，数组各元素之间不会有空隙。按照上面的方案，一个MS2数组array的布局就是:

     

|<-array[1]-> |<-array[2]->|<- array[3] .....

      _____________________________________________
      |         |   |        |   |
      |    a    | b |   a    | b |.............
      |         |   |        |   |
      +--------------------------------------------
Bytes:     4      1     4      1

    当数组首地址是4字节对齐时，array[1].a也是4字节对齐，但是array[2].a呢？array[3].a ....呢？可见这种方案在定义结构体数组时没法让数组中全部元素的字段都知足对齐规定，必须修改为以下形式:

      

___________________________________
         |               |       |         |
         |     a         |   b   | padding |
         |               |       |         |
         +---------------------------------+
Bytes:         4             1       3

    如今不管是定义一个单独的MS2变量仍是MS2数组，均能保证全部元素的全部字段都知足对齐规定。那么sizeof(MS2)仍然是8，而a的偏移为0，b的偏移是4。

    好的，如今你已经掌握告终构体内存布局的基本准则，尝试分析一个稍微复杂点的类型吧。

typedef struct ms3
{
char a;
short b;
double c;
} MS3;

    我想你必定能得出以下正确的布局图:

______________________________________
      |    |\|     |           |           |
      | a  |\|  b  | padding   |   c       |
      |    |\|     |           |           |
      +------------------------------------+
Bytes:  1       2        4             8

sizeof(short) 等于2，b字段应从偶数地址开始，因此a的后面填充一个字节，而sizeof(double)等于8，c字段要从8倍数地址开始，前面的a、b字段加上填 充字节已经有4 bytes，因此b后面再填充4个字节就能够保证c字段的对齐要求了。sizeof(MS3)等于16，b的偏移是2，c的偏移是8。接着看看结构体中字 段仍是结构类型的状况:

typedef struct ms4
{
   char a;
   MS3 b;
} MS4;

    MS3中内存要求最严格的字段是c，那么MS3类型数据的对齐模数就与double的一致(为8)，a字段后面应填充7个字节，所以MS4的布局应该是:
      

_____________________________________
           |       |         |                |
           |   a   | padding |     b          |
           |       |         |                |
           +----------------------------------+
Bytes:        1         7                16

    显然，sizeof(MS4)等于24，b的偏移等于8。

    在实际开发中，咱们能够经过指定/Zp编译选项来更改编译器的对齐规则。好比指定/Zpn(VC7.1中n能够是一、二、四、八、16)就是告诉编译器最 大对齐模数是n。在这种状况下，全部小于等于n字节的基本数据类型的对齐规则与默认的同样，可是大于n个字节的数据类型的对齐模数被限制为n。事实 上，VC7.1的默认对齐选项就至关于/Zp8。仔细看看MSDN对这个选项的描述，会发现它郑重告诫了程序员不要在MIPS和Alpha平台上用 /Zp1和/Zp2选项，也不要在16位平台上指定/Zp4和/Zp8(想一想为何？)。改变编译器的对齐选项，对照程序运行结果从新分析上面4种结构体 的内存布局将是一个很好的复习。

    到了这里，咱们能够回答本文提出的最后一个问题了。结构体的内存布局依赖于CPU、操做系统、编译器及编译时的对齐选项，而你的程序可能须要运行在多种平 台上，你的源代码可能要被不一样的人用不一样的编译器编译(试想你为别人提供一个开放源码的库)，那么除非绝对必需，不然你的程序永远也不要依赖这些诡异的内 存布局。顺便说一下，若是一个程序中的两个模块是用不一样的对齐选项分别编译的，那么它极可能会产生一些很是微妙的错误。若是你的程序确实有很难理解的行 为，不防仔细检查一下各个模块的编译选项。

    思考题:请分析下面几种结构体在你的平台上的内存布局，并试着寻找一种合理安排字段声明顺序的方法以尽可能节省内存空间。

    A. struct P1 { int a; char b; int c; char d; };
    B. struct P2 { int a; char b; char c; int d; };
     C. struct P3 { short a[3]; char b[3]; };
    D. struct P4 { short a[3]; char *b[3]; };
    E. struct P5 { struct P2 *a; char b; struct P1 c[2]; };