关于进程堆栈分布和工作原理（转发）
我们经常会讨论这样的问题：什么时候数据存储在堆栈(Stack)中，什么时候数据存储在堆(Heap)中。我们知道，局部变量是存储在堆栈中的；debug时，查看堆栈可以知道函数的调用顺序；函数调用时传递参数，事实上是把参数压入堆栈，听起来，堆栈象一个大杂烩。那么，堆栈(Stack) 到底是如何工作的呢？ 本文将详解C/C++堆栈的工作机制。阅读时请注意以下几点：
1）本文讨论的编译环境是 Visual C/C++，由于高级语言的堆栈工作机制大致相同，因此对其他编译环境或高级语言如C#也有意义。
2）本文讨论的堆栈，是指程序为每个线程分配的默认堆栈，用以支持程序的运行，而不是指程序员为了实现算法而自己定义的堆栈。
3) 本文讨论的平台为intel x86。
4）本文的主要部分将尽量避免涉及到汇编的知识，在本文最后可选章节，给出前面章节的反编译代码和注释。
5）结构化异常处理也是通过堆栈来实现的(当你使用try…catch语句时，使用的就是c++对windows结构化异常处理的扩展)，但是关于结构化异常处理的主题太复杂了，本文将不会涉及到。
![document_thumb_thumb[4]]( "document_thumb_thumb[4]")
从一些基本的知识和概念开始
1) 程序的堆栈是由处理器直接支持的。在intel x86的系统中，堆栈在内存中是从高地址向低地址扩展（这和自定义的堆栈从低地址向高地址扩展不同），如下图所示：
因此，栈顶地址是不断减小的，越后入栈的数据，所处的地址也就越低。
2) 在32位系统中，堆栈每个数据单元的大小为4字节。小于等于4字节的数据，比如字节、字、双字和布尔型，在堆栈中都是占4个字节的；大于4字节的数据在堆栈中占4字节整数倍的空间。
3)和堆栈的操作相关的两个寄存器是EBP寄存器和ESP寄存器的，本文中，你只需要把EBP和ESP理解成2个指针就可以了。ESP寄存器总是指向堆栈的栈顶，执行PUSH命令向堆栈压入数据时，ESP减4，然后把数据拷贝到ESP指向的地址；执行POP命令时，首先把ESP指向的数据拷贝到内存地址/寄存器中，然后ESP加4。EBP寄存器是用于访问堆栈中的数据的，它指向堆栈中间的某个位置（具体位置后文会具体讲解），函数的参数地址比EBP的值高，而函数的局部变量地址比EBP的值低，因此参数或局部变量总是通过EBP加减一定的偏移地址来访问的，比如，要访问函数的第一个参数为EBP+8。
4) 堆栈中到底存储了什么数据？包括了：函数的参数，函数的局部变量，寄存器的值（用以恢复寄存器），函数的返回地址以及用于结构化异常处理的数据（当函数中有try…catch语句时才有，本文不讨论）。这些数据是按照一定的顺序组织在一起的，我们称之为一个堆栈帧（Stack Frame）。一个堆栈帧对应一次函数的调用。在函数开始时，对应的堆栈帧已经完整地建立了（所有的局部变量在函数帧建立时就已经分配好空间了，而不是随着函数的执行而不断创建和销毁的）；在函数退出时，整个函数帧将被销毁。
5) 在文中，我们把函数的调用者称为caller（调用者），被调用的函数称为callee（被调用者）。之所以引入这个概念，是因为一个函数帧的建立和清理，有些工作是由Caller完成的，有些则是由Callee完成的。
开始讨论堆栈是如何工作的
我们来讨论堆栈的工作机制。堆栈是用来支持函数的调用和执行的，因此，我们下面将通过一组函数调用的例子来讲解，看下面的代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
int foo1(int m, int n)
{
int p=m*n;
return p;
}
int foo(int a, int b)
{
int c=a+1;
int d=b+1;
int e=foo1(c,d);
return e;
}
int main()
{
int result=foo(3,4);
return 0;
}
|
这段代码本身并没有实际的意义，我们只是用它来跟踪堆栈。下面的章节我们来跟踪堆栈的建立，堆栈的使用和堆栈的销毁。
堆栈的建立
我们从main函数执行的第一行代码，即int result=foo(3,4); 开始跟踪。这时main以及之前的函数对应的堆栈帧已经存在在堆栈中了，如下图所示：
图1
参数入栈
当foo函数被调用，首先，caller（此时caller为main函数）把foo函数的两个参数：a=3,b=4压入堆栈。参数入栈的顺序是由函数的调用约定(Calling Convention)决定的，我们将在后面一个专门的章节来讲解调用约定。一般来说，参数都是从右往左入栈的，因此，b=4先压入堆栈，a=3后压入，如图：
图2
返回地址入栈
我们知道，当函数结束时，代码要返回到上一层函数继续执行，那么，函数如何知道该返回到哪个函数的什么位置执行呢？函数被调用时，会自动把下一条指令的地址压入堆栈，函数结束时，从堆栈读取这个地址，就可以跳转到该指令执行了。如果当前＂call foo＂指令的地址是0×00171482,由于call指令占5个字节，那么下一个指令的地址为0×00171487，0×00171487将被压入堆栈:
图3
代码跳转到被调用函数执行
返回地址入栈后，代码跳转到被调用函数foo中执行。到目前为止，堆栈帧的前一部分，是由caller构建的；而在此之后，堆栈帧的其他部分是由callee来构建。
EBP指针入栈
在foo函数中，首先将EBP寄存器的值压入堆栈。因为此时EBP寄存器的值还是用于main函数的，用来访问main函数的参数和局部变量的，因此需要将它暂存在堆栈中，在foo函数退出时恢复。同时，给EBP赋于新值。
1）将EBP压入堆栈
2）把ESP的值赋给EBP
图4
这样一来，我们很容易发现当前EBP寄存器指向的堆栈地址就是ESP先前值的地址，你还会发现发现，EBP+4的地址就是函数返回值的地址，EBP+8就是函数的第一个参数的地址（第一个参数地址并不一定是EBP+8，后文中将讲到）。因此，通过EBP很容易查找函数是被谁调用的或者访问函数的参数（或局部变量）。
为局部变量分配地址
接着，foo函数将为局部变量分配地址。程序并不是将局部变量一个个压入堆栈的，而是将ESP减去某个值，直接为所有的局部变量分配空间，比如在foo函数中有ESP=ESP-0x00E4，（根据烛秋兄在其他编译环境上的测试，也可能使用push命令分配地址，本质上并没有差别，特此说明）如图所示：
图5
奇怪的是，在debug模式下，编译器为局部变量分配的空间远远大于实际所需，而且局部变量之间的地址不是连续的（据我观察，总是间隔8个字节）如下图所示：
图6
我还不知道编译器为什么这么设计，或许是为了在堆栈中插入调试数据，不过这无碍我们今天的讨论。
通用寄存器入栈
最后，将函数中使用到的通用寄存器入栈，暂存起来，以便函数结束时恢复。在foo函数中用到的通用寄存器是EBX，ESI，EDI，将它们压入堆栈，如图所示：
图7
至此，一个完整的堆栈帧建立起来了。
堆栈特性分析 上一节中，一个完整的堆栈帧已经建立起来，现在函数可以开始正式执行代码了。本节我们对堆栈的特性进行分析，有助于了解函数与堆栈帧的依赖关系。
1）一个完整的堆栈帧建立起来后，在函数执行的整个生命周期中，它的结构和大小都是保持不变的；不论函数在什么时候被谁调用，它对应的堆栈帧的结构也是一定的。
2）在A函数中调用B函数，对应的，是在A函数对应的堆栈帧“下方”建立B函数的堆栈帧。例如在foo函数中调用foo1函数，foo1函数的堆栈帧将在foo函数的堆栈帧下方建立。如下图所示：
图8
3）函数用EBP寄存器来访问参数和局部变量。我们知道，参数的地址总是比EBP的值高，而局部变量的地址总是比EBP的值低。而在特定的堆栈帧中，每个参数或局部变量相对于EBP的地址偏移总是固定的。因此函数对参数和局部变量的的访问是通过EBP加上某个偏移量来访问的。比如，在foo函数中，EBP+8为第一个参数的地址，EBP-8为第一个局部变量的地址。
4）如果仔细思考，我们很容易发现EBP寄存器还有一个非常重要的特性，请看下图中：
图9
我们发现，EBP寄存器总是指向先前的EBP，而先前的EBP又指向先前的先前的EBP，这样就在堆栈中形成了一个链表！这个特性有什么用呢，我们知道 EBP+4地址存储了函数的返回地址，通过该地址我们可以知道当前函数的上一级函数（通过在符号文件中查找距该函数返回地址最近的函数地址，该函数即当前函数的上一级函数），以此类推，我们就可以知道当前线程整个的函数调用顺序。事实上，调试器正是这么做的，这也就是为什么调试时我们查看函数调用顺序时总是说“查看堆栈”了。
返回值是如何传递的
堆栈帧建立起后，函数的代码真正地开始执行，它会操作堆栈中的参数，操作堆栈中的局部变量，甚至在堆（Heap）上创建对象，balabala….，终于函数完成了它的工作，有些函数需要将结果返回给它的上一层函数，这是怎么做的呢？
首先，caller和callee在这个问题上要有一个“约定”，由于caller是不知道callee内部是如何执行的，因此caller需要从 callee的函数声明就可以知道应该从什么地方取得返回值。同样的，callee不能随便把返回值放在某个寄存器或者内存中而指望Caller能够正确地获得的，它应该根据函数的声明，按照“约定”把返回值放在正确的”地方“。下面我们来讲解这个“约定”：
1）首先，如果返回值等于4字节，函数将把返回值赋予EAX寄存器，通过EAX寄存器返回。例如返回值是字节、字、双字、布尔型、指针等类型，都通过EAX寄存器返回。
2）如果返回值等于8字节，函数将把返回值赋予EAX和EDX寄存器，通过EAX和EDX寄存器返回，EDX存储高位4字节，EAX存储低位4字节。例如返回值类型为__int64或者8字节的结构体通过EAX和EDX返回。
3) 如果返回值为double或float型，函数将把返回值赋予浮点寄存器，通过浮点寄存器返回。
4）如果返回值是一个大于8字节的数据，将如何传递返回值呢？这是一个比较麻烦的问题，我们将详细讲解：
我们修改foo函数的定义如下并将它的代码做适当的修改：
|
1
2
3
4
|
MyStruct foo(int a, int b)
{
...
}
|
MyStruct定义为：
|
1
2
3
4
5
6
|
struct MyStruct
{
int value1;
__int64 value2;
bool value3;
};
|
这时，在调用foo函数时参数的入栈过程会有所不同，如下图所示：
图10
caller会在压入最左边的参数后，再压入一个指针，我们姑且叫它ReturnValuePointer，ReturnValuePointer指向 caller局部变量区的一块未命名的地址，这块地址将用来存储callee的返回值。函数返回时，callee把返回值拷贝到 ReturnValuePointer指向的地址中，然后把ReturnValuePointer的地址赋予EAX寄存器。函数返回后，caller通过 EAX寄存器找到ReturnValuePointer，然后通过ReturnValuePointer找到返回值，最后，caller把返回值拷贝到负责接收的局部变量上（如果接收返回值的话）。
你或许会有这样的疑问，函数返回后，对应的堆栈帧已经被销毁，而ReturnValuePointer是在该堆栈帧中，不也应该被销毁了吗？对的，堆栈帧是被销毁了，但是程序不会自动清理其中的值，因此ReturnValuePointer中的值还是有效的。
堆栈帧的销毁
当函数将返回值赋予某些寄存器或者拷贝到堆栈的某个地方后，函数开始清理堆栈帧，准备退出。堆栈帧的清理顺序和堆栈建立的顺序刚好相反：（堆栈帧的销毁过程就不一一画图说明了）
1）如果有对象存储在堆栈帧中，对象的析构函数会被函数调用。
2）从堆栈中弹出先前的通用寄存器的值，恢复通用寄存器。
3）ESP加上某个值，回收局部变量的地址空间（加上的值和堆栈帧建立时分配给局部变量的地址大小相同）。
4）从堆栈中弹出先前的EBP寄存器的值，恢复EBP寄存器。
5）从堆栈中弹出函数的返回地址，准备跳转到函数的返回地址处继续执行。
6）ESP加上某个值，回收所有的参数地址。
前面1-5条都是由callee完成的。而第6条，参数地址的回收，是由caller或者callee完成是由函数使用的调用约定（calling convention ）来决定的。下面的小节我们就来讲解函数的调用约定。
函数的调用约定（calling convention）
函数的调用约定(calling convention)指的是进入函数时，函数的参数是以什么顺序压入堆栈的，函数退出时，又是由谁（Caller还是Callee）来清理堆栈中的参数。有2个办法可以指定函数使用的调用约定：
1）在函数定义时加上修饰符来指定，如
|
1
2
3
4
|
void __thiscall mymethod();
{
...
}
|
2）在VS工程设置中为工程中定义的所有的函数指定默认的调用约定：在工程的主菜单打开Project|Project Property|Configuration Properties|C/C++|Advanced|Calling Convention，选择调用约定（注意：这种做法对类成员函数无效）。 常用的调用约定有以下3种：
1）__cdecl。这是VC编译器默认的调用约定。其规则是：参数从右向左压入堆栈，函数退出时由 caller清理堆栈中的参数。这种调用约定的特点是支持可变数量的参数，比如printf方法。由于callee不知道caller到底将多少参数压入堆栈，因此callee就没有办法自己清理堆栈，所以只有函数退出之后，由caller清理堆栈，因为caller总是知道自己传入了多少参数。
2）__stdcall。所有的Windows API都使用__stdcall。其规则是：参数从右向左压入堆栈，函数退出时由callee自己清理堆栈中的参数。由于参数是由callee自己清理的，所以__stdcall不支持可变数量的参数。
3) __thiscall。类成员函数默认使用的调用约定。其规则是：参数从右向左压入堆栈，x86构架下 this指针通过ECX寄存器传递，函数退出时由callee清理堆栈中的参数，x86构架下this指针通过ECX寄存器传递。同样不支持可变数量的参数。如果显式地把类成员函数声明为使用__cdecl或者__stdcall，那么，将采用__cdecl或者__stdcall的规则来压栈和出栈，而 this指针将作为函数的第一个参数最后压入堆栈，而不是使用ECX寄存器来传递了。
反编译代码的跟踪（不熟悉汇编可跳过）
以下代码为和foo函数对应的堆栈帧建立相关的代码的反编译代码，我将逐行给出注释，可对照前文中对堆栈的描述：
main函数中 int result=foo(3,4); 的反汇编：
|
1
2
3
4
5
|
008A147E push 4 //b=4 压入堆栈
008A1480 push 3 //a=3 压入堆栈,到达图2的状态
008A1482 call foo (8A10F5h) //函数返回值入栈,转入foo中执行,到达图3的状态
008A1487 add esp,8 //foo返回,由于采用__cdecl,由Caller清理参数
008A148A mov dword ptr [result], |
下面是foo函数代码正式执行前和执行后的反汇编代码
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
008A13F0 push ebp //把ebp压入堆栈
008A13F1 mov ebp,esp //ebp指向先前的ebp,到达图4的状态
008A13F3 sub esp,//为局部变量分配0E4字节的空间,到达图5的状态
008A13F9 push ebx //压入EBX
008A13FA push esi //压入ESI
008A13FB push edi //压入EDI,到达图7的状态
008A13FC lea edi,[ebp-0E4h] //以下4行把局部变量区初始化为每个字节都等于cch
008A1402 mov ecx,39h
008A1407 mov eax,0CCCCCCCCh
008A140C rep stos dword ptr es:[edi]
...... //省略代码执行N行
......
008A1436 pop edi //恢复EDI
008A1437 pop esi //恢复ESI
008A1438 pop ebx //恢复EBX
008A1439 add esp,0E4h //回收局部变量地址空间
008A143F cmp ebp,esp //以下3行为Runtime Checking,检查ESP和EBP是否一致
008A1441 call @ILT+330(__RTC_CheckEsp) (8A114Fh)
008A1446 mov esp,ebp
008A1448 pop ebp //恢复EBP
008A1449 ret //弹出函数返回地址，跳转到函数返回地址执行 //(__cdecl调用约定,Callee未清理参数)
|
![document_thumb_thumb4[1]]( "document_thumb_thumb4[1]")
参考
Debug Tutorial Part 2: The Stack
Intel汇编语言程序设计(第四版) 第8章
http://msdn.microsoft.com/zh-cn/library/46t77ak2(VS.80).aspx
![document_thumb_thumb4[1]]( "document_thumb_thumb4[1]")
声明
本文为Binhua Liu原创作品。本文允许复制，修改，传递，但不允许用于商业用途。转载请注明出处。本文发表于2010年8月24日。
【C/C++】堆栈
堆和栈的区别
一个由c/C++编译的程序占用的内存分为以下几个部分
1、栈区（stack）— 由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。
2、堆区（heap） — 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表，呵呵。
3、全局区（静态区）（static）—，全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域， 未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。 - 程序结束后有系统释放
4、文字常量区—常量字符串就是放在这里的。 程序结束后由系统释放
5、程序代码区—存放函数体的二进制代码。
二、例子程序
这是一个前辈写的，非常详细
//main.cpp
int a = 0; 全局初始化区
char *p1; 全局未初始化区
main()
{
int b; 栈
char s[] = ”abc”; 栈
char *p2; 栈
char *p3 = ”123456″; 123456\0在常量区，p3在栈上。
static int c =0； 全局（静态）初始化区
p1 = (char *)malloc(10);
p2 = (char *)malloc(20);
分配得来得10和20字节的区域就在堆区。
strcpy(p1, ”123456″); 123456\0放在常量区，编译器可能会将它与p3所指向的”123456″优化成一个地方。
}
二、堆和栈的理论知识
2.1申请方式
stack:
由系统自动分配。 例如，声明在函数中一个局部变量 int b; 系统自动在栈中为b开辟空间
heap:
需要程序员自己申请，并指明大小，在c中malloc函数
如p1 = (char *)malloc(10);
在C++中用new运算符
如p2 = (char *)malloc(10);
但是注意p1、p2本身是在栈中的。
2.2
申请后系统的响应
栈：只要栈的剩余空间大于所申请空间，系统将为程序提供内存，否则将报异常提示栈溢出。
堆：首先应该知道操作系统有一个记录空闲内存地址的链表，当系统收到程序的申请时，
会遍历该链表，寻找第一个空间大于所申请空间的堆结点，然后将该结点从空闲结点链表中删除，并将该结点的空间分配给程序，另外，对于大多数系统，会在这块内存空间中的首地址处记录本次分配的大小，这样，代码中的delete语句才能正确的释放本内存空间。另外，由于找到的堆结点的大小不一定正好等于申请的大小，系统会自动的将多余的那部分重新放入空闲链表中。
2.3申请大小的限制
栈：在Windows下,栈是向低地址扩展的数据结构，是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的，在 WINDOWS下，栈的大小是2M（也有的说是1M，总之是一个编译时就确定的常数），如果申请的空间超过栈的剩余空间时，将提示overflow。因此，能从栈获得的空间较小。
堆：堆是向高地址扩展的数据结构，是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的，自然是不连续的，而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见，堆获得的空间比较灵活，也比较大。
2.4申请效率的比较：
栈由系统自动分配，速度较快。但程序员是无法控制的。
堆是由new分配的内存，一般速度比较慢，而且容易产生内存碎片,不过用起来最方便.
另外，在WINDOWS下，最好的方式是用VirtualAlloc分配内存，他不是在堆，也不是在栈是直接在进程的地址空间中保留一快内存，虽然用起来最不方便。但是速度快，也最灵活。
2.5堆和栈中的存储内容
栈： 在函数调用时，第一个进栈的是主函数中后的下一条指令（函数调用语句的下一条可执行语句）的地址，然后是函数的各个参数，在大多数的C编译器中，参数是由右往左入栈的，然后是函数中的局部变量。注意静态变量是不入栈的。
当本次函数调用结束后，局部变量先出栈，然后是参数，最后栈顶指针指向最开始存的地址，也就是主函数中的下一条指令，程序由该点继续运行。
堆：一般是在堆的头部用一个字节存放堆的大小。堆中的具体内容有程序员安排。
2.6存取效率的比较
char s1[] = ”aaaaaaaaaaaaaaa”;
char *s2 = ”bbbbbbbbbbbbbbbbb”;
aaaaaaaaaaa是在运行时刻赋值的；
而bbbbbbbbbbb是在编译时就确定的；
但是，在以后的存取中，在栈上的数组比指针所指向的字符串(例如堆)快。
比如：
#include
void main()
{
char a = 1;
char c[] = ”1234567890″;
char *p =”1234567890″;
a = c[1];
a = p[1];
return;
}
对应的汇编代码
10: a = c[1];
00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]
0040106A 88 4D FC mov byte ptr [ebp-4],cl
11: a = p[1];
0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]
00401070 8A 42 01 mov al,byte ptr [edx+1]
00401073 88 45 FC mov byte ptr [ebp-4],al
第一种在读取时直接就把字符串中的元素读到寄存器cl中，而第二种则要先把指针值读到edx中，在根据edx读取字符，显然慢了。
2.7小结：
堆和栈的区别可以用如下的比喻来看出：
使用栈就象我们去饭馆里吃饭，只管点菜（发出申请）、付钱、和吃（使用），吃饱了就走，不必理会切菜、洗菜等准备工作和洗碗、刷锅等扫尾工作，他的好处是快捷，但是自由度小。
使用堆就象是自己动手做喜欢吃的菜肴，比较麻烦，但是比较符合自己的口味，而且自由度大。
windows进程中的内存结构
在阅读本文之前，如果你连堆栈是什么多不知道的话，请先阅读文章后面的基础知识。
接触过编程的人都知道，高级语言都能通过变量名来访问内存中的数据。那么这些变量在内存中是如何存放的呢？程序又是如何使用这些变量的呢？下面就会对此进行深入的讨论。下文中的C语言代码如没有特别声明，默认都使用VC编译的release版。
首先，来了解一下 C 语言的变量是如何在内存分部的。C 语言有全局变量(Global)、本地变量(Local)，静态变量(Static)、寄存器变量(Regeister)。每种变量都有不同的分配方式。先来看下面这段代码：
#include
int g1=0, g2=0, g3=0;
int main()
{
static int s1=0, s2=0, s3=0;
int v1=0, v2=0, v3=0;
//打印出各个变量的内存地址
printf(“0xx\n”,&v1); //打印各本地变量的内存地址
printf(“0xx\n”,&v2);
printf(“0xx\n\n”,&v3);
printf(“0xx\n”,&g1); //打印各全局变量的内存地址
printf(“0xx\n”,&g2);
printf(“0xx\n\n”,&g3);
printf(“0xx\n”,&s1); //打印各静态变量的内存地址
printf(“0xx\n”,&s2);
printf(“0xx\n\n”,&s3);
return 0;
}
编译后的执行结果是：
0x0012ff78
0x0012ff7c
0x0012ff80
0x004068d0
0x004068d4
0x004068d8
0x004068dc
0x004068e0
0x004068e4
输出的结果就是变量的内存地址。其中v1,v2,v3是本地变量，g1,g2,g3是全局变量，s1,s2,s3是静态变量。你可以看到这些变量在内存是连续分布的，但是本地变量和全局变量分配的内存地址差了十万八千里，而全局变量和静态变量分配的内存是连续的。这是因为本地变量和全局/静态变量是分配在不同类型的内存区域中的结果。对于一个进程的内存空间而言，可以在逻辑上分成3个部份：代码区，静态数据区和动态数据区。动态数据区一般就是“堆栈”。“栈(stack)”和“堆(heap)”是两种不同的动态数据区，栈是一种线性结构，堆是一种链式结构。进程的每个线程都有私有的“栈”，所以每个线程虽然代码一样，但本地变量的数据都是互不干扰。一个堆栈可以通过“基地址”和“栈顶”地址来描述。全局变量和静态变量分配在静态数据区，本地变量分配在动态数据区，即堆栈中。程序通过堆栈的基地址和偏移量来访问本地变量。
├———————┤低端内存区域
│ …… │
├———————┤
│ 动态数据区 │
├———————┤
│ …… │
├———————┤
│ 代码区 │
├———————┤
│ 静态数据区 │
├———————┤
│ …… │
├———————┤高端内存区域
堆栈是一个先进后出的数据结构，栈顶地址总是小于等于栈的基地址。我们可以先了解一下函数调用的过程，以便对堆栈在程序中的作用有更深入的了解。不同的语言有不同的函数调用规定，这些因素有参数的压入规则和堆栈的平衡。windows API的调用规则和ANSI C的函数调用规则是不一样的，前者由被调函数调整堆栈，后者由调用者调整堆栈。两者通过“__stdcall”和“__cdecl”前缀区分。先看下面这段代码：
#include
void __stdcall func(int param1,int param2,int param3)
{
int var1=param1;
int var2=param2;
int var3=param3;
printf(“0xx\n”,¶m1); //打印出各个变量的内存地址
printf(“0xx\n”,¶m2);
printf(“0xx\n\n”,¶m3);
printf(“0xx\n”,&var1);
printf(“0xx\n”,&var2);
printf(“0xx\n\n”,&var3);
return;
}
int main()
{
func(1,2,3);
return 0;
}
编译后的执行结果是：
0x0012ff78
0x0012ff7c
0x0012ff80
0x0012ff68
0x0012ff6c
0x0012ff70
├———————┤<—函数执行时的栈顶（ESP）、低端内存区域
│ …… │
├———————┤
│ var 1 │
├———————┤
│ var 2 │
├———————┤
│ var 3 │
├———————┤
│ RET │
├———————┤<—“__cdecl”函数返回后的栈顶（ESP）
│ parameter 1 │
├———————┤
│ parameter 2 │
├———————┤
│ parameter 3 │
├———————┤<—“__stdcall”函数返回后的栈顶（ESP）
│ …… │
├———————┤<—栈底（基地址 EBP）、高端内存区域
上图就是函数调用过程中堆栈的样子了。首先，三个参数以从又到左的次序压入堆栈，先压“param3”，再压“param2”，最后压入 “param1”；然后压入函数的返回地址(RET)，接着跳转到函数地址接着执行（这里要补充一点，介绍UNIX下的缓冲溢出原理的文章中都提到在压入 RET后，继续压入当前EBP，然后用当前ESP代替EBP。然而，有一篇介绍windows下函数调用的文章中说，在windows下的函数调用也有这一步骤，但根据我的实际调试，并未发现这一步，这还可以从param3和var1之间只有4字节的间隙这点看出来）；第三步，将栈顶(ESP)减去一个数，为本地变量分配内存空间，上例中是减去12字节(ESP=ESP-3*4，每个int变量占用4个字节)；接着就初始化本地变量的内存空间。由于 “__stdcall”调用由被调函数调整堆栈，所以在函数返回前要恢复堆栈，先回收本地变量占用的内存(ESP=ESP+3*4)，然后取出返回地址，填入EIP寄存器，回收先前压入参数占用的内存(ESP=ESP+3*4)，继续执行调用者的代码。参见下列汇编代码：
;————–func 函数的汇编代码——————-
:00401000 83EC0C sub esp, 0000000C //创建本地变量的内存空间
:00401003 8B442410 mov eax, dword ptr [esp+10]
:00401007 8B4C2414 mov ecx, dword ptr [esp+14]
:0040100B 8B542418 mov edx, dword ptr [esp+18]
:0040100F 89442400 mov dword ptr [esp], eax
:00401013 8D442410 lea eax, dword ptr [esp+10]
:00401017 894C2404 mov dword ptr [esp+04], ecx
……………………（省略若干代码）
:00401075 83C43C add esp, 0000003C ;恢复堆栈，回收本地变量的内存空间
:00401078 C3 ret 000C ;函数返回，恢复参数占用的内存空间
;如果是“__cdecl”的话，这里是“ret”，堆栈将由调用者恢复
;——————-函数结束————————-
;————–主程序调用func函数的代码————–
:00401080 6A03 push 00000003 //压入参数param3
:00401082 6A02 push 00000002 //压入参数param2
:00401084 6A01 push 00000001 //压入参数param1
:00401086 E875FFFFFF call 00401000 //调用func函数
;如果是“__cdecl”的话，将在这里恢复堆栈，“add esp, 0000000C”
聪明的读者看到这里，差不多就明白缓冲溢出的原理了。先来看下面的代码：
#include
#include
void __stdcall func()
{
char lpBuff[8]=”\0″;
strcat(lpBuff,”AAAAAAAAAAA”);
return;
}
int main()
{
func();
return 0;
}
编译后执行一下回怎么样？哈，“”0×00414141″指令引用的”0×00000000″内存。该内存不能为”read”。”，“非法操作” 喽！”41″就是”A”的16进制的ASCII码了，那明显就是strcat这句出的问题了。”lpBuff”的大小只有8字节，算进结尾的\0，那 strcat最多只能写入7个”A”，但程序实际写入了11个”A”外加1个\0。再来看看上面那幅图，多出来的4个字节正好覆盖了RET的所在的内存空间，导致函数返回到一个错误的内存地址，执行了错误的指令。如果能精心构造这个字符串，使它分成三部分，前一部份仅仅是填充的无意义数据以达到溢出的目的，接着是一个覆盖RET的数据，紧接着是一段shellcode，那只要着个RET地址能指向这段shellcode的第一个指令，那函数返回时就能执行shellcode了。但是软件的不同版本和不同的运行环境都可能影响这段shellcode在内存中的位置，那么要构造这个RET是十分困难的。一般都在RET和shellcode之间填充大量的NOP指令，使得exploit有更强的通用性。
├———————┤<—低端内存区域
│ …… │
├———————┤<—由exploit填入数据的开始
│ │
│ buffer │<—填入无用的数据
│ │
├———————┤
│ RET │<—指向shellcode，或NOP指令的范围
├———————┤
│ NOP │
│ …… │<—填入的NOP指令，是RET可指向的范围
│ NOP │
├———————┤
│ │
│ shellcode │
│ │
├———————┤<—由exploit填入数据的结束
│ …… │
├———————┤<—高端内存区域
windows下的动态数据除了可存放在栈中，还可以存放在堆中。了解C++的朋友都知道，C++可以使用new关键字来动态分配内存。来看下面的C++代码：
#include
#include
#include
void func()
{
char *buffer=new char[128];
char bufflocal[128];
static char buffstatic[128];
printf(“0xx\n”,buffer); //打印堆中变量的内存地址
printf(“0xx\n”,bufflocal); //打印本地变量的内存地址
printf(“0xx\n”,buffstatic); //打印静态变量的内存地址
}
void main()
{
func();
return;
}
程序执行结果为：
0x004107d0
0x0012ff04
0x004068c0
可以发现用new关键字分配的内存即不在栈中，也不在静态数据区。VC编译器是通过windows下的“堆(heap)”来实现new关键字的内存动态分配。在讲“堆”之前，先来了解一下和“堆”有关的几个API函数：
HeapAlloc 在堆中申请内存空间
HeapCreate 创建一个新的堆对象
HeapDestroy 销毁一个堆对象
HeapFree 释放申请的内存
HeapWalk 枚举堆对象的所有内存块
GetProcessHeap 取得进程的默认堆对象
GetProcessHeaps 取得进程所有的堆对象
LocalAlloc
GlobalAlloc
当进程初始化时，系统会自动为进程创建一个默认堆，这个堆默认所占内存的大小为1M。堆对象由系统进行管理，它在内存中以链式结构存在。通过下面的代码可以通过堆动态申请内存空间：
HANDLE hHeap=GetProcessHeap();
char *buff=HeapAlloc(hHeap,0,8);
其中hHeap是堆对象的句柄，buff是指向申请的内存空间的地址。那这个hHeap究竟是什么呢？它的值有什么意义吗？看看下面这段代码吧：
#pragma comment(linker,”/entry:main”) //定义程序的入口
#include
_CRTIMP int (__cdecl *printf)(const char *, …); //定义STL函数printf
void main()
{
HANDLE hHeap=GetProcessHeap();
char *buff=HeapAlloc(hHeap,0,0×10);
char *buff2=HeapAlloc(hHeap,0,0×10);
HMODULE hMsvcrt=LoadLibrary(“msvcrt.dll”);
printf=(void *)GetProcAddress(hMsvcrt,”printf”);
printf(“0xx\n”,hHeap);
printf(“0xx\n”,buff);
printf(“0xx\n\n”,buff2);
}
执行结果为：
0×00130000
0×00133100
0×00133118
hHeap的值怎么和那个buff的值那么接近呢？其实hHeap这个句柄就是指向HEAP首部的地址。在进程的用户区存着一个叫PEB(进程环境块)的结构，这个结构中存放着一些有关进程的重要信息，其中在PEB首地址偏移0×18处存放的ProcessHeap就是进程默认堆的地址，而偏移 0×90处存放了指向进程所有堆的地址列表的指针。windows有很多API都使用进程的默认堆来存放动态数据，如windows 2000下的所有 ANSI版本的函数都是在默认堆中申请内存来转换ANSI字符串到Unicode字符串的。对一个堆的访问是顺序进行的，同一时刻只能有一个线程访问堆中的数据，当多个线程同时有访问要求时，只能排队等待，这样便造成程序执行效率下降。
最后来说说内存中的数据对齐。所位数据对齐，是指数据所在的内存地址必须是该数据长度的整数倍，DWORD数据的内存起始地址能被4除尽，WORD 数据的内存起始地址能被2除尽，x86 CPU能直接访问对齐的数据，当他试图访问一个未对齐的数据时，会在内部进行一系列的调整，这些调整对于程序来说是透明的，但是会降低运行速度，所以编译器在编译程序时会尽量保证数据对齐。同样一段代码，我们来看看用VC、Dev-C++和lcc三个不同编译器编译出来的程序的执行结果：
#include
int main()
{
int a;
char b;
int c;
printf(“0xx\n”,&a);
printf(“0xx\n”,&b);
printf(“0xx\n”,&c);
return 0;
}
这是用VC编译后的执行结果：
0x0012ff7c
0x0012ff7b
0x0012ff80
变量在内存中的顺序：b(1字节)-a(4字节)-c(4字节)。
这是用Dev-C++编译后的执行结果：
0x0022ff7c
0x0022ff7b
0x0022ff74
变量在内存中的顺序：c(4字节)-中间相隔3字节-b(占1字节)-a(4字节)。
这是用lcc编译后的执行结果：
0x0012ff6c
0x0012ff6b
0x0012ff64
变量在内存中的顺序：同上。
三个编译器都做到了数据对齐，但是后两个编译器显然没VC“聪明”，让一个char占了4字节，浪费内存哦。
基础知识：
堆栈是一种简单的数据结构，是一种只允许在其一端进行插入或删除的线性表。允许插入或删除操作的一端称为栈顶，另一端称为栈底，对堆栈的插入和删除操作被称为入栈和出栈。有一组CPU指令可以实现对进程的内存实现堆栈访问。其中，POP指令实现出栈操作，PUSH指令实现入栈操作。CPU的ESP寄存器存放当前线程的栈顶指针，EBP寄存器中保存当前线程的栈底指针。CPU的EIP寄存器存放下一个CPU指令存放的内存地址，当CPU执行完当前的指令后，从EIP寄存器中读取下一条指令的内存地址，然后继续执行。
参考：《Windows下的HEAP溢出及其利用》by: isno
《windows核心编程》by: Jeffrey Richter
摘要： 讨论常见的堆性能问题以及如何防范它们。（共 9 页）
前言
您是否是动态分配的 C/C++ 对象忠实且幸运的用户？您是否在模块间的往返通信中频繁地使用了“自动化”？您的程序是否因堆分配而运行起来很慢？不仅仅您遇到这样的问题。几乎所有项目迟早都会遇到堆问题。大家都想说，“我的代码真正好，只是堆太慢”。那只是部分正确。更深入理解堆及其用法、以及会发生什么问题，是很有用的。
什么是堆？
（如果您已经知道什么是堆，可以跳到“什么是常见的堆性能问题？”部分）
在程序中，使用堆来动态分配和释放对象。在下列情况下，调用堆操作：
事先不知道程序所需对象的数量和大小。
对象太大而不适合堆栈分配程序。
堆使用了在运行时分配给代码和堆栈的内存之外的部分内存。下图给出了堆分配程序的不同层。
GlobalAlloc/GlobalFree：Microsoft Win32 堆调用，这些调用直接与每个进程的默认堆进行对话。
LocalAlloc/LocalFree：Win32 堆调用（为了与 Microsoft Windows NT 兼容），这些调用直接与每个进程的默认堆进行对话。
COM 的 IMalloc 分配程序（或 CoTaskMemAlloc / CoTaskMemFree）：函数使用每个进程的默认堆。自动化程序使用“组件对象模型 (COM)”的分配程序，而申请的程序使用每个进程堆。
C/C++ 运行时 (CRT) 分配程序：提供了 malloc() 和 free() 以及 new 和 delete 操作符。如 Microsoft Visual Basic 和 Java 等语言也提供了新的操作符并使用垃圾收集来代替堆。CRT 创建自己的私有堆，驻留在 Win32 堆的顶部。
Windows NT 中，Win32 堆是 Windows NT 运行时分配程序周围的薄层。所有 API 转发它们的请求给 NTDLL。
Windows NT 运行时分配程序提供 Windows NT 内的核心堆分配程序。它由具有 128 个大小从 8 到 1,024 字节的空闲列表的前端分配程序组成。后端分配程序使用虚拟内存来保留和提交页。
在图表的底部是“虚拟内存分配程序”，操作系统使用它来保留和提交页。所有分配程序使用虚拟内存进行数据的存取。
分配和释放块不就那么简单吗？为何花费这么长时间？
堆实现的注意事项
传统上，操作系统和运行时库是与堆的实现共存的。在一个进程的开始，操作系统创建一个默认堆，叫做“进程堆”。如果没有其他堆可使用，则块的分配使用“进程堆”。语言运行时也能在进程内创建单独的堆。（例如，C 运行时创建它自己的堆。）除这些专用的堆外，应用程序或许多已载入的动态链接库 (DLL) 之一可以创建和使用单独的堆。Win32 提供一整套 API 来创建和使用私有堆。有关堆函数（英文）的详尽指导，请参见 MSDN。
当应用程序或 DLL 创建私有堆时，这些堆存在于进程空间，并且在进程内是可访问的。从给定堆分配的数据将在同一个堆上释放。（不能从一个堆分配而在另一个堆释放。）
在所有虚拟内存系统中，堆驻留在操作系统的“虚拟内存管理器”的顶部。语言运行时堆也驻留在虚拟内存顶部。某些情况下，这些堆是操作系统堆中的层，而语言运行时堆则通过大块的分配来执行自己的内存管理。不使用操作系统堆，而使用虚拟内存函数更利于堆的分配和块的使用。
典型的堆实现由前、后端分配程序组成。前端分配程序维持固定大小块的空闲列表。对于一次分配调用，堆尝试从前端列表找到一个自由块。如果失败，堆被迫从后端（保留和提交虚拟内存）分配一个大块来满足请求。通用的实现有每块分配的开销，这将耗费执行周期，也减少了可使用的存储空间。
Knowledge Base 文章 Q10758，“用 calloc() 和 malloc() 管理内存” （搜索文章编号）, 包含了有关这些主题的更多背景知识。另外，有关堆实现和设计的详细讨论也可在下列著作中找到：“Dynamic Storage Allocation: A Survey and Critical Review”，作者 Paul R. Wilson、Mark S. Johnstone、 Michael Neely 和 David Boles；“International Workshop on Memory Management”, 作者 Kinross, Scotland, UK, 1995 年 9 月(http://www.cs.utexas.edu/users/oops/papers.html)（英文）。
Windows NT 的实现（Windows NT 版本 4.0 和更新版本） 使用了 127 个大小从 8 到 1,024 字节的 8 字节对齐块空闲列表和一个“大块”列表。“大块”列表（空闲列表[0]） 保存大于 1,024 字节的块。空闲列表容纳了用双向链表链接在一起的对象。默认情况下，“进程堆”执行收集操作。（收集是将相邻空闲块合并成一个大块的操作。）收集耗费了额外的周期，但减少了堆块的内部碎片。
单一全局锁保护堆，防止多线程式的使用。（请参见“Server Performance and Scalability Killers”中的第一个注意事项, George Reilly 所著，在 “MSDN Online Web Workshop”上（站点：http://msdn.microsoft.com/workshop/server/iis/tencom.asp（英文）。）单一全局锁本质上是用来保护堆数据结构，防止跨多线程的随机存取。若堆操作太频繁，单一全局锁会对性能有不利的影响。
什么是常见的堆性能问题？
以下是您使用堆时会遇到的最常见问题：
分配操作造成的速度减慢。光分配就耗费很长时间。最可能导致运行速度减慢原因是空闲列表没有块，所以运行时分配程序代码会耗费周期寻找较大的空闲块，或从后端分配程序分配新块。
释放操作造成的速度减慢。释放操作耗费较多周期，主要是启用了收集操作。收集期间，每个释放操作“查找”它的相邻块，取出它们并构造成较大块，然后再把此较大块插入空闲列表。在查找期间，内存可能会随机碰到，从而导致高速缓存不能命中，性能降低。
堆竞争造成的速度减慢。当两个或多个线程同时访问数据，而且一个线程继续进行之前必须等待另一个线程完成时就发生竞争。竞争总是导致麻烦；这也是目前多处理器系统遇到的最大问题。当大量使用内存块的应用程序或 DLL 以多线程方式运行（或运行于多处理器系统上）时将导致速度减慢。单一锁定的使用—常用的解决方案—意味着使用堆的所有操作是序列化的。当等待锁定时序列化会引起线程切换上下文。可以想象交叉路口闪烁的红灯处走走停停导致的速度减慢。
竞争通常会导致线程和进程的上下文切换。上下文切换的开销是很大的，但开销更大的是数据从处理器高速缓存中丢失，以及后来线程复活时的数据重建。
堆破坏造成的速度减慢。造成堆破坏的原因是应用程序对堆块的不正确使用。通常情形包括释放已释放的堆块或使用已释放的堆块，以及块的越界重写等明显问题。（破坏不在本文讨论范围之内。有关内存重写和泄漏等其他细节，请参见 Microsoft Visual C++(R) 调试文档 。）
频繁的分配和重分配造成的速度减慢。这是使用脚本语言时非常普遍的现象。如字符串被反复分配，随重分配增长和释放。不要这样做，如果可能，尽量分配大字符串和使用缓冲区。另一种方法就是尽量少用连接操作。
竞争是在分配和释放操作中导致速度减慢的问题。理想情况下，希望使用没有竞争和快速分配/释放的堆。可惜，现在还没有这样的通用堆，也许将来会有。
在所有的服务器系统中（如 IIS、MSProxy、DatabaseStacks、网络服务器、 Exchange 和其他）, 堆锁定实在是个大瓶颈。处理器数越多，竞争就越会恶化。
尽量减少堆的使用
现在您明白使用堆时存在的问题了，难道您不想拥有能解决这些问题的超级魔棒吗？我可希望有。但没有魔法能使堆运行加快—因此不要期望在产品出货之前的最后一星期能够大为改观。如果提前规划堆策略，情况将会大大好转。调整使用堆的方法，减少对堆的操作是提高性能的良方。
如何减少使用堆操作？通过利用数据结构内的位置可减少堆操作的次数。请考虑下列实例：
struct ObjectA {
// objectA 的数据
}
struct ObjectB {
// objectB 的数据
}
// 同时使用 objectA 和 objectB
//
// 使用指针
//
struct ObjectB {
struct ObjectA * pObjA;
// objectB 的数据
}
//
// 使用嵌入
//
struct ObjectB {
struct ObjectA pObjA;
// objectB 的数据
}
//
// 集合 – 在另一对象内使用 objectA 和 objectB
//
struct ObjectX {
struct ObjectA objA;
struct ObjectB objB;
}
避免使用指针关联两个数据结构。如果使用指针关联两个数据结构，前面实例中的对象 A 和 B 将被分别分配和释放。这会增加额外开销—我们要避免这种做法。
把带指针的子对象嵌入父对象。当对象中有指针时，则意味着对象中有动态元素（百分之八十）和没有引用的新位置。嵌入增加了位置从而减少了进一步分配/释放的需求。这将提高应用程序的性能。
合并小对象形成大对象（聚合）。聚合减少分配和释放的块的数量。如果有几个开发者，各自开发设计的不同部分，则最终会有许多小对象需要合并。集成的挑战就是要找到正确的聚合边界。
内联缓冲区能够满足百分之八十的需要（aka 80-20 规则）。个别情况下，需要内存缓冲区来保存字符串/二进制数据，但事先不知道总字节数。估计并内联一个大小能满足百分之八十需要的缓冲区。对剩余的百分之二十，可以分配一个新的缓冲区和指向这个缓冲区的指针。这样，就减少分配和释放调用并增加数据的位置空间，从根本上提高代码的性能。
在块中分配对象（块化）。块化是以组的方式一次分配多个对象的方法。如果对列表的项连续跟踪，例如对一个 {名称，值} 对的列表，有两种选择：选择一是为每一个“名称-值”对分配一个节点；选择二是分配一个能容纳（如五个）“名称-值”对的结构。例如，一般情况下，如果存储四对，就可减少节点的数量，如果需要额外的空间数量，则使用附加的链表指针。
块化是友好的处理器高速缓存，特别是对于 L1-高速缓存，因为它提供了增加的位置 —不用说对于块分配，很多数据块会在同一个虚拟页中。
正确使用 _amblksiz。C 运行时 (CRT) 有它的自定义前端分配程序，该分配程序从后端（Win32 堆）分配大小为 _amblksiz 的块。将 _amblksiz 设置为较高的值能潜在地减少对后端的调用次数。这只对广泛使用 CRT 的程序适用。
使用上述技术将获得的好处会因对象类型、大小及工作量而有所不同。但总能在性能和可升缩性方面有所收获。另一方面，代码会有点特殊，但如果经过深思熟虑，代码还是很容易管理的。
其他提高性能的技术
下面是一些提高速度的技术：
使用 Windows NT5 堆
由于几个同事的努力和辛勤工作，1998 年初 Microsoft Windows(R) 2000 中有了几个重大改进：
改进了堆代码内的锁定。堆代码对每堆一个锁。全局锁保护堆数据结构，防止多线程式的使用。但不幸的是，在高通信量的情况下，堆仍受困于全局锁，导致高竞争和低性能。Windows 2000 中，锁内代码的临界区将竞争的可能性减到最小,从而提高了可伸缩性。
使用 “Lookaside”列表。堆数据结构对块的所有空闲项使用了大小在 8 到 1,024 字节（以 8-字节递增）的快速高速缓存。快速高速缓存最初保护在全局锁内。现在，使用 lookaside 列表来访问这些快速高速缓存空闲列表。这些列表不要求锁定，而是使用 64 位的互锁操作，因此提高了性能。
内部数据结构算法也得到改进。
这些改进避免了对分配高速缓存的需求，但不排除其他的优化。使用 Windows NT5 堆评估您的代码；它对小于 1,024 字节 (1 KB) 的块（来自前端分配程序的块）是最佳的。GlobalAlloc() 和 LocalAlloc() 建立在同一堆上，是存取每个进程堆的通用机制。如果希望获得高的局部性能，则使用 Heap(R) API 来存取每个进程堆，或为分配操作创建自己的堆。如果需要对大块操作，也可以直接使用 VirtualAlloc() / VirtualFree() 操作。
上述改进已在 Windows 2000 beta 2 和 Windows NT 4.0 SP4 中使用。改进后，堆锁的竞争率显著降低。这使所有 Win32 堆的直接用户受益。CRT 堆建立于 Win32 堆的顶部，但它使用自己的小块堆，因而不能从 Windows NT 改进中受益。（Visual C++ 版本 6.0 也有改进的堆分配程序。）
使用分配高速缓存
分配高速缓存允许高速缓存分配的块，以便将来重用。这能够减少对进程堆（或全局堆）的分配/释放调用的次数，也允许最大限度的重用曾经分配的块。另外，分配高速缓存允许收集统计信息,以便较好地理解对象在较高层次上的使用。
典型地，自定义堆分配程序在进程堆的顶部实现。自定义堆分配程序与系统堆的行为很相似。主要的差别是它在进程堆的顶部为分配的对象提供高速缓存。高速缓存设计成一套固定大小（如 32 字节、64 字节、128 字节等）。这一个很好的策略，但这种自定义堆分配程序丢失与分配和释放的对象相关的“语义信息”。
与自定义堆分配程序相反，“分配高速缓存”作为每类分配高速缓存来实现。除能够提供自定义堆分配程序的所有好处之外，它们还能够保留大量语义信息。每个分配高速缓存处理程序与一个目标二进制对象关联。它能够使用一套参数进行初始化，这些参数表示并发级别、对象大小和保持在空闲列表中的元素的数量等。分配高速缓存处理程序对象维持自己的私有空闲实体池（不超过指定的阀值）并使用私有保护锁。合在一起，分配高速缓存和私有锁减少了与主系统堆的通信量，因而提供了增加的并发、最大限度的重用和较高的可伸缩性。
需要使用清理程序来定期检查所有分配高速缓存处理程序的活动情况并回收未用的资源。如果发现没有活动，将释放分配对象的池，从而提高性能。
可以审核每个分配/释放活动。第一级信息包括对象、分配和释放调用的总数。通过查看它们的统计信息可以得出各个对象之间的语义关系。利用以上介绍的许多技术之一，这种关系可以用来减少内存分配。
分配高速缓存也起到了调试助手的作用，帮助您跟踪没有完全清除的对象数量。通过查看动态堆栈返回踪迹和除没有清除的对象之外的签名，甚至能够找到确切的失败的调用者。
MP 堆
MP 堆是对多处理器友好的分布式分配的程序包，在 Win32 SDK（Windows NT 4.0 和更新版本）中可以得到。最初由 JVert 实现，此处堆抽象建立在 Win32 堆程序包的顶部。MP 堆创建多个 Win32 堆，并试图将分配调用分布到不同堆，以减少在所有单一锁上的竞争。
本程序包是好的步骤 —一种改进的 MP-友好的自定义堆分配程序。但是，它不提供语义信息和缺乏统计功能。通常将 MP 堆作为 SDK 库来使用。如果使用这个 SDK 创建可重用组件，您将大大受益。但是，如果在每个 DLL 中建立这个 SDK 库，将增加工作设置。
重新思考算法和数据结构
要在多处理器机器上伸缩，则算法、实现、数据结构和硬件必须动态伸缩。请看最经常分配和释放的数据结构。试问，“我能用不同的数据结构完成此工作吗？”例如，如果在应用程序初始化时加载了只读项的列表，这个列表不必是线性链接的列表。如果是动态分配的数组就非常好。动态分配的数组将减少内存中的堆块和碎片，从而增强性能。
减少需要的小对象的数量减少堆分配程序的负载。例如，我们在服务器的关键处理路径上使用五个不同的对象，每个对象单独分配和释放。一起高速缓存这些对象，把堆调用从五个减少到一个，显著减少了堆的负载，特别当每秒钟处理 1,000 个以上的请求时。
如果大量使用“Automation”结构，请考虑从主线代码中删除“Automation BSTR”，或至少避免重复的 BSTR 操作。（BSTR 连接导致过多的重分配和分配/释放操作。）
摘要
对所有平台往往都存在堆实现，因此有巨大的开销。每个单独代码都有特定的要求，但设计能采用本文讨论的基本理论来减少堆之间的相互作用。
评价您的代码中堆的使用。
改进您的代码，以使用较少的堆调用：分析关键路径和固定数据结构。
在实现自定义的包装程序之前使用量化堆调用成本的方法。
如果对性能不满意，请要求 OS 组改进堆。更多这类请求意味着对改进堆的更多关注。
要求 C 运行时组针对 OS 所提供的堆制作小巧的分配包装程序。随着 OS 堆的改进，C 运行时堆调用的成本将减小。
操作系统（Windows NT 家族）正在不断改进堆。请随时关注和利用这些改进。
Murali Krishnan 是 Internet Information Server (IIS) 组的首席软件设计工程师。从 1.0 版本开始他就设计 IIS，并成功发行了 1.0 版本到 4.0 版本。Murali 组织并领导 IIS 性能组三年 (1995-1998), 从一开始就影响 IIS 性能。他拥有威斯康星州 Madison 大学的 M.S.和印度 Anna 大学的 B.S.。工作之外，他喜欢阅读、打排球和家庭烹饪。
http://community.csdn.net/Expert/FAQ/FAQ_Index.asp?id=172835
我在学习对象的生存方式的时候见到一种是在堆栈(stack)之中，如下
CObject object;
还有一种是在堆(heap)中 如下
CObject* pobject=new CObject();
请问
（1）这两种方式有什么区别？
（2）堆栈与堆有什么区别？？
—————————————————————
1) about stack, system will allocate memory to the instance of object automatically, and to the
heap, you must allocate memory to the instance of object with new or malloc manually.
2) when function ends, system will automatically free the memory area of stack, but to the
heap, you must free the memory area manually with free or delete, else it will result in memory
leak.
3)栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。
4）堆上分配的内存可以有我们自己决定，使用非常灵活。
—————————————————————
【C/C++】如何判断CPU是大端还是小端模式
如何判断CPU是大端还是小端模式
MSB:Most Significant Bit ——- 最高有效位
LSB:Least Significant Bit ——- 最低有效位
大端模式（big-edian）
big-endian：MSB存放在最低端的地址上。
举例，双字节数0×1234以big-endian的方式存在起始地址0×00002000中：
| data |<– address
| 0×12 |<– 0×00002000
| 0×34 |<– 0×00002001
在Big-Endian中，对于bit序列中的序号编排方式如下（以双字节数0x8B8A为例）：
—-+—————————————————+
bit | 00 01 02 03 04 05 06 07 | 08 09 10 11 12 13 14 15 |
—-+MSB———————————————LSB+
val | 1 0 0 0 1 0 1 1 | 1 0 0 0 1 0 1 0 |
—-+—————————————————+
= 0x8B8A
小端模式(little-endian)
little-endian：LSB存放在最低端的地址上。
举例，双字节数0×1234以little-endian的方式存在起始地址0×00002000中：
| data |<– address
| 0×34 |<– 0×00002000
| 0×12 |<– 0×00002001
在Little-Endian中，对于bit序列中的序号编排和Big-Endian刚好相反，其方式如下（以双字节数0x8B8A为例）：
—-+—————————————————+
bit | 15 14 13 12 11 10 09 08 | 07 06 05 04 03 02 01 00 |
—-+MSB———————————————LSB+
val | 1 0 0 0 1 0 1 1 | 1 0 0 0 1 0 1 0 |
—-+—————————————————+
= 0x8B8A
c) 网络字节序：TCP/IP各层协议将字节序定义为Big-Endian，因此TCP/IP协议中使用的字节序通常称之为网络字节序。
网络字节顺序是“所见即所得”的顺序。而Intel类型的CPU的字节顺序与此相反。
比如上面的 short B=0102H(十六进制，每两位表示一个字节的宽度）。所见到的是“0102”，按一般数学常识，数轴从左到右的方向增加，即内存地址从左到右增加的话，在内存中这个 short B的字节顺序是：
01 02
这就是网络字节顺序。所见到的顺序和在内存中的顺序是一致的！
在C语言中，不同于结构体，共用体（联合体）中的几种不同类型的变量存放在同一段内存单元中。利用这一特点，可以用联合体变量判断ARM或x86环境下，存储系统是是大端还是小端模式。
#include “stdio.h”
int main()
{
union w
{
int a; //4 bytes
char b; //1 byte
} c;
c.a=1;
if (c.b==1)
printf(“It is Little_endian!\n”);
else
printf(“It is Big_endian!\n”);
return 1;
}
说明：
1 在c中，联合体（共用体）的数据成员都是从低地址开始存放。
2 若是小端模式，由低地址到高地址c.a存放为0×01 00 00 00，c.b被赋值为0×01；
————————————————————————————
地址 0×00000000 0×00000001 0×00000002 0×00000003
c.a 01 00 00 00
c.b 01 00
————————————————————————————
3 若是大端模式，由低地址到高地址c.a存放为0×00 00 00 01，c.b被赋值为0×0；
————————————————————————————
地址 0×00000000 0×00000001 0×00000002 0×00000003
c.a 00 00 00 01
c.b 00 00
————————————————————————————
4 根据c.b的值的情况就可以判断cpu的模式了，现在XP环境下的intel CPU是小端模式，不信你可测试下！
的确判别一个 系统是大头序还是小头序的方法是有的。
比如：
-BEGIN-
int x=1; // 0×00000001
if (*(char*)&x) {
}else{
}
-END-
内存数据（0×00000001）-〉大头/小头字符序-〉数值（1）
这里判别的前提条件是知道内存数据及所对应的数值，所以可以判定出大小头字符序。
另外参考：http://www.cnblogs.com/wxxweb/archive/2011/06/28/2092108.html
参考：大小端转换函数 http://blog.csdn.net/ysdaniel/article/details/6772392
【C/C++】void (*signal(int sig,void (*func)(int)))(int)
在ANSI标准中，signal()的声明如下：
void (*signal(int sig,void (*func)(int)))(int)
signal是一个函数，它返回一个函数指针，后者所指向的函数(signal的返回值)接受一个int参数并返回void。signal函数有两个参数，一个是sig(为int类型)，另一个是func(为void(*)(int)类型)。
void (*func)(int)是一个函数指针，所指向的函数接受一个int参数，返回值是void。
下面用typedef进行简化：
typedef void（*ptr_to_func）(int);
ptr_to_func signal（int，ptr_to_func）;
网上的一个例子：
#include
enum { RED, GREEN, BLUE };
void OutputSignal(int sig)
{
printf(“The signal you /’ve input is: ”);
switch(sig)
{
case RED:
puts(“RED!”);
break;
case GREEN:
puts(“GREEN!”);
break;
case BLUE:
puts(“BLUE!”);
break;
}
}
void ( *signal( int sig, void (*func)(int) ) ) (int)
{
puts(“Hello, world!”);
func(sig);
return func;
}
int main(void)
{
(*signal(GREEN, &OutputSignal))(RED);
return 0;
}
Output:
Hello, world!
The signal you ‘ve input is: GREEN!
The signal you ‘ve input is: RED!
【C/C++】理解复杂函数声明（一）
曾经碰到过让你迷惑不解、类似于int * (* (*fp1) (int) ) [10];这样的变量声明吗？本文将由易到难，一步一步教会你如何理解这种复杂的C/C++声明。我们将从每天都能碰到的较简单的声明入手，然后逐步加入 const修饰符和typedef，还有函数指针，最后介绍一个能够让你准确地理解任何C/C++声明的“右左法则”。需要强调一下的是，复杂的C /C++声明并不是好的编程风格；这里仅仅是教你如何去理解这些声明。
让我们从一个非常简单的例子开始，如下：
int n; |
这个应该被理解为“declare n as an int”（n是一个int型的变量）。接下去来看一下指针变量，如下：
int *p; |
这个应该被理解为“declare p as an int *”（p是一个int *型的变量），或者说p是一个指向一个int型变量的指针。我想在这里展开讨论一下：我觉得在声明一个指针（或引用）类型的变量时，最好将* （或&）写在紧靠变量之前，而不是紧跟基本类型之后。这样可以避免一些理解上的误区，比如：
int* p,q; |
第一眼看去，好像是p和q都是int*类型的，但事实上，只有p是一个指针，而q是一个最简单的int型变量。我们还是继续我们前面的话题，再来看一个指针的指针的例子：
char **argv; |
理论上，对于指针的级数没有限制，你可以定义一个浮点类型变量的指针的指针的指针的指针，再来看如下的声明：
int RollNum[30][4]; int (*p)[4]=RollNum; int *q[5]; |
这里，p被声明为一个指向一个4元素（int类型）数组的指针，而q被声明为一个包含5个元素（int类型的指针）的数组。另外，我们还可以在同一个声明中混合实用*和&，如下：
int **p1; // p1 is a pointer to a pointer to an int. int *&p2; // p2 is a reference to a pointer to an int. int &*p3; // ERROR: Pointer to a reference is illegal. int &&p4; // ERROR: Reference to a reference is illegal. |
注：p1是一个int类型的指针的指针；p2是一个int类型的指针的引用；p3是一个int类型引用的指针（不合法！）；p4是一个int类型引用的引用（不合法！）。
const修饰符
当你想阻止一个变量被改变，可能会用到const关键字。在你给一个变量加上const修饰符的同时，通常需要对它进行初始化，因为以后的任何时候你将没有机会再去改变它。例如：
const int n=5; int const m=10; |
上述两个变量n和m其实是同一种类型的——都是const int（整形恒量）。因为C++标准规定，const关键字放在类型或变量名之前等价的。我个人更喜欢第一种声明方式，因为它更突出了const修饰符的作用。当const与指针一起使用时，容易让人感到迷惑。例如，我们来看一下下面的p和q的声明：
const int *p; int const *q; |
他们当中哪一个代表const int类型的指针（const直接修饰int），哪一个代表int类型的const指针（const直接修饰指针）？实际上，p和q都被声明为const int类型的指针。而int类型的const指针应该这样声明：
int * const r= &n; // n has been declared as an int |
这里，p和q都是指向const int类型的指针，也就是说，你在以后的程序里不能改变*p的值。而r是一个const指针，它在声明的时候被初始化指向变量n（即r=&n;）之后，r的值将不再允许被改变（但*r的值可以改变）。
组合上述两种const修饰的情况，我们来声明一个指向const int类型的const指针，如下：
const int * const p=&n // n has been declared as const int |
下面给出的一些关于const的声明，将帮助你彻底理清const的用法。不过请注意，下面的一些声明是不能被编译通过的，因为他们需要在声明的同时进行初始化。为了简洁起见，我忽略了初始化部分；因为加入初始化代码的话，下面每个声明都将增加两行代码。
char ** p1; // pointer to pointer to char const char **p2; // pointer to pointer to const char char * const * p3; // pointer to const pointer to char const char * const * p4; // pointer to const pointer to const char char ** const p5; // const pointer to pointer to char const char ** const p6; // const pointer to pointer to const char char * const * const p7; // const pointer to const pointer to char const char * const * const p8; // const pointer to const pointer to const char |
注：p1是指向char类型的指针的指针；p2是指向const char类型的指针的指针；p3是指向char类型的const指针；p4是指向const char类型的const指针；p5是指向char类型的指针的const指针；p6是指向const char类型的指针的const指针；p7是指向char类型const指针的const指针；p8是指向const char类型的const指针的const指针。
typedef的妙用
typedef给你一种方式来克服“*只适合于变量而不适合于类型”的弊端。你可以如下使用typedef：
typedef char * PCHAR; PCHAR p,q; |
这里的p和q都被声明为指针。（如果不使用typedef，q将被声明为一个char变量，这跟我们的第一眼感觉不太一致！）下面有一些使用typedef的声明，并且给出了解释：
typedef char * a; // a is a pointer to a char typedef a b(); // b is a function that returns // a pointer to a char typedef b *c; // c is a pointer to a function // that returns a pointer to a char typedef c d(); // d is a function returning // a pointer to a function // that returns a pointer to a char typedef d *e; // e is a pointer to a function // returning a pointer to a // function that returns a // pointer to a char e var[10]; // var is an array of 10 pointers to // functions returning pointers to // functions returning pointers to chars. |
typedef经常用在一个结构声明之前，如下。这样，当创建结构变量的时候，允许你不使用关键字struct（在C中，创建结构变量时要求使用struct关键字，如struct tagPOINT a；而在C++中，struct可以忽略，如tagPOINT b）。
typedef struct tagPOINT { int x; int y; }POINT; POINT p; |
函数指针
函数指针可能是最容易引起理解上的困惑的声明。函数指针在DOS时代写TSR程序时用得最多；在Win32和X-Windows时代，他们被用在需要回调函数的场合。当然，还有其它很多地方需要用到函数指针：虚函数表，STL中的一些模板，Win NT/2K/XP系统服务等。让我们来看一个函数指针的简单例子：
int (*p)(char); |
这里p被声明为一个函数指针，这个函数带一个char类型的参数，并且有一个int类型的返回值。另外，带有两个float类型参数、返回值是char类型的指针的指针的函数指针可以声明如下：
char ** (*p)(float, float); |
那么，带两个char类型的const指针参数、无返回值的函数指针又该如何声明呢？参考如下：
void * (*a[5])(char * const, char * const); |
“右左法则”是一个简单的法则，但能让你准确理解所有的声明。这个法则运用如下：从最内部的括号开始阅读声明，向右看，然后向左看。当你碰到一个括号时就调转阅读的方向。括号内的所有内容都分析完毕就跳出括号的范围。这样继续，直到整个声明都被分析完毕。
对上述“右左法则”做一个小小的修正：当你第一次开始阅读声明的时候，你必须从变量名开始，而不是从最内部的括号。
下面结合例子来演示一下“右左法则”的使用。
int * (* (*fp1) (int) ) [10]; |
阅读步骤：
1. 从变量名开始——fp1
2. 往右看，什么也没有，碰到了)，因此往左看，碰到一个*——一个指针
3. 跳出括号，碰到了(int)——一个带一个int参数的函数
4. 向左看，发现一个*——（函数）返回一个指针
5. 跳出括号，向右看，碰到[10]——一个10元素的数组
6. 向左看，发现一个*——指针
7. 向左看，发现int——int类型
总结：fp1被声明成为一个函数的指针,该函数返回指向指针数组的指针.
再来看一个例子：
int *( *( *arr[5])())(); |
阅读步骤：
1. 从变量名开始——arr
2. 往右看，发现是一个数组——一个5元素的数组
3. 向左看，发现一个*——指针
4. 跳出括号，向右看，发现()——不带参数的函数
5. 向左看，碰到*——（函数）返回一个指针
6. 跳出括号，向右发现()——不带参数的函数
7. 向左，发现*——（函数）返回一个指针
8. 继续向左，发现int——int类型
还有更多的例子：
float ( * ( *b()) [] )(); // b is a function that returns a // pointer to an array of pointers // to functions returning floats. void * ( *c) ( char, int (*)()); // c is a pointer to a function that takes // two parameters: // a char and a pointer to a // function that takes no // parameters and returns // an int // and returns a pointer to void. void ** (*d) (int &, char **(*)(char *, char **)); // d is a pointer to a function that takes // two parameters: // a reference to an int and a pointer // to a function that takes two parameters: // a pointer to a char and a pointer // to a pointer to a char // and returns a pointer to a pointer // to a char // and returns a pointer to a pointer to void float ( * ( * e[10]) (int &) ) [5]; // e is an array of 10 pointers to // functions that take a single // reference to an int as an argument // and return pointers to // an array of 5 floats. |
【Notes】Notes Of C Traps And Pitfalls（二）
4贪心法，大嘴法
如果（编译器的）输入流截止至某个字符之前都已经被分解为一个个符号，那个下一个符号将包括从该字符之后可能组成一个符号的最大字符串。
a—b = a– -b !=a- –b
上面是你随便 google一下,人家就可以跟你解释的,一大堆的道理,我们没怎么多时间,讨论为何要对齐.直入主题,怎么判断内存对齐规则,sizeof的结果怎么来的,请牢记以下3条原则:(在没有#pragma pack宏的情况下，务必看完最后一行)
１:数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小（只要该成员有子成员，比如说是数组，结构体等）的整数倍开始(比如int在３２位机为４字节,则要从４的整数倍地址开始存储。
２:结构体作为成员:如果一个结构里有某些结构体成员,则结构体成员要从其内部最大元素大小的整数倍地址开始存储.(struct a里存有struct b,b里有char,int ,double等元素,那b应该从8的整数倍开始存储.)
３:收尾工作:结构体的总大小,也就是sizeof的结果,.必须是其内部最大成员的整数倍.不足的要补齐.
等你看完此３条原则,２分钟已经过去,抓紧时间,实战３分钟:
typedef struct bb
{
int id; //[0]….[3]
double weight; //[8]…..[15] 原则１
float height; //[16]..[19],总长要为８的整数倍,补齐[20]…[23] 原则３
}BB;
typedef struct aa
{
char name[2]; //[0],[1]
int id; //[4]…[7] 原则１
double score; //[8]….[15]
short grade; //[16],[17]
BB b; //[24]……[47] 原则２
}AA;
int main()
{
AA a;
cout<
}
结果是
48 24
ok,上面的全看明白了,内存对齐基本过关.
再讲讲#pragma pack().
在代码前加一句#pragma pack(1),你会很高兴的发现,上面的代码输出为
32 16
bb是4+8+4=16,aa是2+4+8+2+16=32;
这不是理想中的没有内存对齐的世界吗.没错,#pragma pack(1),告诉编译器,所有的对齐都按照1的整数倍对齐,换句话说就是没有对齐规则.
明白了不?
那#pragma pack(2)的结果又是多少呢?对不起,５分钟到了,自己去测试吧.
ps:Vc,Vs等编译器默认是#pragma pack(8)，所以测试我们的规则会正常；注意gcc默认是#pragma pack(4)，并且gcc只支持1,2,4对齐。套用三原则里计算的对齐值是不能大于#pragma pack指定的n值。