内存管理笔记

目录(?)[+]

C++的内存管理

 来自：http://blog.csdn.net/wudijunjun/article/details/6395559

1内存分配方式

一个由C/C++编译的程序占用的内存分为以下几个部分

1、栈区（stack）— 由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。

2、堆区（heap） — 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表，呵呵。

3、全局区（静态区）（static）—，全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域，未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。 - 程序结束后有系统释放

4、文字常量区—常量字符串就是放在这里的。 程序结束后由系统释放

5、程序代码区—存放函数体的二进制代码。

2内存错误

常见的内存错误及其对策如下：

1）内存分配未成功，却使用了它。

编程新手常犯这种错误，因为他们没有意识到内存分配会不成功。常用解决办法是，在使用内存之前检查指针是否为NULL。如果指针p是函数的参数，那么在函数的入口处用assert(p!=NULL)进行检查。如果是用malloc或new来申请内存，应该用if(p==NULL) 或if(p!=NULL)进行防错处理。

2）内存分配虽然成功，但是尚未初始化就引用它。

犯这种错误主要有两个起因：一是没有初始化的观念；二是误以为内存的缺省初值全为零，导致引用初值错误（例如数组）。

内存的缺省初值究竟是什么并没有统一的标准，尽管有些时候为零值，我们宁可信其无不可信其有。所以无论用何种方式创建数组，都别忘了赋初值，即便是赋零值也不可省略，不要嫌麻烦。

3)内存分配成功并且已经初始化，但操作越过了内存的边界。

例如在使用数组时经常发生下标“多1”或者“少1”的操作。特别是在for循环语句中，循环次数很容易搞错，导致数组操作越界。

4)忘记了释放内存，造成内存泄露。

含有这种错误的函数每被调用一次就丢失一块内存。刚开始时系统的内存充足，你看不到错误。终有一次程序突然死掉，系统出现提示：内存耗尽。

动态内存的申请与释放必须配对，程序中malloc与free的使用次数一定要相同，否则肯定有错误（new/delete同理）。

5)释放了内存却继续使用它。

有三种情况：

（1）程序中的对象调用关系过于复杂，实在难以搞清楚某个对象究竟是否已经释放了内存，此时应该重新设计数据结构，从根本上解决对象管理的混乱局面。

（2）函数的return语句写错了，注意不要返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结束时被自动销毁。

（3）使用free或delete释放了内存后，没有将指针设置为NULL。导致产生“野指针”。

6）指针被强制转换成不匹配的数据结构

内存使用规则

【规则1】用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。

【规则2】不要忘记为数组和动态内存赋初值。防止将未被初始化的内存作为右值使用。

【规则3】避免数组或指针的下标越界，特别要当心发生“多1”或者“少1”操作。

【规则4】动态内存的申请与释放必须配对，防止内存泄漏。

【规则5】用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。

3指针与数组的对比

C++/C程序中，指针和数组在不少地方可以相互替换着用，让人产生一种错觉，以为两者是等价的。

数组要么在静态存储区被创建（如全局数组），要么在栈上被创建。数组名对应着（而不是指向）一块内存，其地址与容量在生命期内保持不变，只有数组的内容可以改变。

指针可以随时指向任意类型的内存块，它的特征是“可变”，所以我们常用指针来操作动态内存。指针远比数组灵活，但也更危险。

下面以字符串为例比较指针与数组的特性。

3.1修改内容

示例3-1中，字符数组a的容量是6个字符，其内容为hello/0。a的内容可以改变，如a[0]= ‘X’。指针p指向常量字符串“world”（位于静态存储区，内容为world/0），常量字符串的内容是不可以被修改的。从语法上看，编译器并不觉得语句p[0]= ‘X’有什么不妥，但是该语句企图修改常量字符串的内容而导致运行错误。

char a[] = “hello”;

a[0] = ‘X’;

cout << a << endl;

char *p = “world”;     // 注意p指向常量字符串

p[0] = ‘X’;         // 编译器不能发现该错误

cout << p << endl;

示例3-1 修改数组和指针的内容

3.2 内容复制与比较

不能对数组名进行直接复制与比较。示例3-2中，若想把数组a的内容复制给数组b，不能用语句 b = a ，否则将产生编译错误。应该用标准库函数strcpy进行复制。同理，比较b和a的内容是否相同，不能用if(b==a) 来判断，应该用标准库函数strcmp进行比较。

语句p = a 并不能把a的内容复制指针p，而是把a的地址赋给了p。要想复制a的内容，可以先用库函数malloc为p申请一块容量为strlen(a)+1个字符的内存，再用strcpy进行字符串复制。同理，语句if(p==a) 比较的不是内容而是地址，应该用库函数strcmp来比较。

     // 数组…

     char a[] = "hello";

     char b[10];

     strcpy(b, a);          // 不能用 b = a;

     if(strcmp(b, a) == 0) // 不能用 if (b == a)

…

     // 指针…

     int len = strlen(a);

     char *p = (char *)malloc(sizeof(char)*(len+1));

     strcpy(p,a);           // 不要用 p = a;

     if(strcmp(p, a) == 0) // 不要用 if (p == a)

…

示例3-2 数组和指针的内容复制与比较

3.3 计算内存容量

用运算符sizeof可以计算出数组的容量（字节数）。示例3-3（a）中，sizeof(a)的值是12（注意别忘了’/0’）。指针p指向a，但是sizeof(p)的值却是4。这是因为sizeof(p)得到的是一个指针变量的字节数，相当于sizeof(char*)，而不是p所指的内存容量。C++/C语言没有办法知道指针所指的内存容量，除非在申请内存时记住它。

注意当数组作为函数的参数进行传递时，该数组自动退化为同类型的指针。示例3-3（b）中，不论数组a的容量是多少，sizeof(a)始终等于sizeof(char *)。

     char a[] = "hello world";

     char *p = a;

     cout<< sizeof(a) << endl;   // 12字节

     cout<< sizeof(p) << endl;   // 4字节

示例3-3（a）计算数组和指针的内存容量

     void Func(char a[100])

     {

         cout<< sizeof(a) << endl;   // 4字节而不是100字节

}

示例3-3（b）数组退化为指针

4指针参数是如何传递内存的？

如果函数的参数是一个指针，不要指望用该指针去申请动态内存。示例4-1中，Test函数的语句GetMemory(str, 200)并没有使str获得期望的内存，str依旧是NULL，为什么？

void GetMemory(char *p, int num)

{

     p = (char *)malloc(sizeof(char) * num);

}

void Test(void)

{

     char *str = NULL;

     GetMemory(str, 100);   // str 仍然为 NULL

     strcpy(str, "hello"); // 运行错误

}

示例4-1 试图用指针参数申请动态内存

毛病出在函数GetMemory中。编译器总是要为函数的每个参数制作临时副本，指针参数p的副本是 _p，编译器使 _p = p。如果函数体内的程序修改了_p的内容，就导致参数p的内容作相应的修改。这就是指针可以用作输出参数的原因。在本例中，_p申请了新的内存，只是把_p所指的内存地址改变了，但是p丝毫未变。所以函数GetMemory并不能输出任何东西。事实上，每执行一次GetMemory就会泄露一块内存，因为没有用free释放内存。

如果非得要用指针参数去申请内存，那么应该改用“指向指针的指针”，见示例4-2。

void GetMemory2(char **p, int num)

{

     *p = (char *)malloc(sizeof(char) * num);

}

void Test2(void)

{

     char *str = NULL;

     GetMemory2(&str, 100); // 注意参数是 &str，而不是str

     strcpy(str, "hello");

     cout<< str << endl;

     free(str);   

}

示例4-2用指向指针的指针申请动态内存

由于“指向指针的指针”这个概念不容易理解，我们可以用函数返回值来传递动态内存。这种方法更加简单，见示例4-3。

char *GetMemory3(int num)

{

     char *p = (char *)malloc(sizeof(char) * num);

     return p;

}

void Test3(void)

{

     char *str = NULL;

     str = GetMemory3(100);

     strcpy(str, "hello");

     cout<< str << endl;

     free(str);   

}

示例4-3 用函数返回值来传递动态内存

用函数返回值来传递动态内存这种方法虽然好用，但是常常有人把return语句用错了。这里强调不要用return语句返回指向“栈内存”的指针，因为该内存在函数结束时自动消亡，见示例4-4。

char *GetString(void)

{

     char p[] = "hello world";

     return p; // 编译器将提出警告

}

void Test4(void)

{

char *str = NULL;

str = GetString(); // str 的内容是垃圾

cout<< str << endl;

}

示例4-4 return语句返回指向“栈内存”的指针

用调试器逐步跟踪Test4，发现执行str = GetString语句后str不再是NULL指针，但是str的内容不是“hello world”而是垃圾。

如果把示例4-4改写成示例4-5，会怎么样？

char *GetString2(void)

{

     char *p = "hello world";

     return p;

}

void Test5(void)

{

     char *str = NULL;

     str = GetString2();

     cout<< str << endl;

}

示例4-5 return语句返回常量字符串

函数Test5运行虽然不会出错，但是函数GetString2的设计概念却是错误的。因为GetString2内的“hello world”是常量字符串，位于静态存储区，它在程序生命期内恒定不变。无论什么时候调用GetString2，它返回的始终是同一个“只读”的内存块。

5 free和delete把指针怎么啦？

别看free和delete的名字恶狠狠的（尤其是delete），它们只是把指针所指的内存给释放掉，但并没有把指针本身干掉。

用调试器跟踪示例7-5，发现指针p被free以后其地址仍然不变（非NULL），只是该地址对应的内存是垃圾，p成了“野指针”。如果此时不把p设置为NULL，会让人误以为p是个合法的指针。

如果程序比较长，我们有时记不住p所指的内存是否已经被释放，在继续使用p之前，通常会用语句if (p != NULL)进行防错处理。很遗憾，此时if语句起不到防错作用，因为即便p不是NULL指针，它也不指向合法的内存块。

     char *p = (char *) malloc(100);

     strcpy(p, “hello”);

     free(p);     // p所指的内存被释放，但是p所指的地址仍然不变

     …

     if(p != NULL) // 没有起到防错作用

     {

        strcpy(p, “world”); // 出错

}

示例5 p成为野指针

6动态内存会被自动释放吗？

函数体内的局部变量在函数结束时自动消亡。很多人误以为示例6是正确的。理由是p是局部的指针变量，它消亡的时候会让它所指的动态内存一起完蛋。这是错觉！

     void Func(void)

{

     char *p = (char *) malloc(100); // 动态内存会自动释放吗？

}

示例6 试图让动态内存自动释放

我们发现指针有一些“似是而非”的特征：

（1）指针消亡了，并不表示它所指的内存会被自动释放。

（2）内存被释放了，并不表示指针会消亡或者成了NULL指针。

这表明释放内存并不是一件可以草率对待的事。也许有人不服气，一定要找出可以草率行事的理由：

如果程序终止了运行，一切指针都会消亡，动态内存会被操作系统回收。既然如此，在程序临终前，就可以不必释放内存、不必将指针设置为NULL了。终于可以偷懒而不会发生错误了吧？

想得美。如果别人把那段程序取出来用到其它地方怎么办？

7杜绝“野指针”

“野指针”不是NULL指针，是指向“垃圾”内存的指针。人们一般不会错用NULL指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。

“野指针”的成因主要有两种：

（1）指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。例如

     char *p = NULL;

     char *str = (char *) malloc(100);

（2）指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。参见第5节。

（3）指针操作超越了变量的作用范围。这种情况让人防不胜防，示例程序如下：

     class A

{   

public:

     void Func(void){ cout << “Func of class A” << endl; }

};

     void Test(void)

{

     A *p;

         {

              A a;

              p = &a; // 注意 a 的生命期

        }

         p->Func();         // p是“野指针”

}

函数Test在执行语句p->Func()时，对象a已经消失，而p是指向a的，所以p就成了“野指针”。但奇怪的是我运行这个程序时居然没有出错，这可能与编译器有关。

8有了malloc/free为什么还要new/delete ？

malloc与free是C++/C语言的标准库函数，new/delete是C++的运算符。它们都可用于申请动态内存和释放内存。

对于非内部数据类型的对象而言，光用maloc/free无法满足动态对象的要求。对象在创建的同时要自动执行构造函数，对象在消亡之前要自动执行析构函数。由于malloc/free是库函数而不是运算符，不在编译器控制权限之内，不能够把执行构造函数和析构函数的任务强加于malloc/free。

因此C++语言需要一个能完成动态内存分配和初始化工作的运算符new，以及一个能完成清理与释放内存工作的运算符delete。注意new/delete不是库函数。

我们先看一看malloc/free和new/delete如何实现对象的动态内存管理，见示例8。

class Obj

{

public :

Obj(void){ cout << “Initialization” << endl; }

~Obj(void){ cout << “Destroy” << endl; }

void Initialize(void){ cout << “Initialization” << endl; }

void    Destroy(void){ cout << “Destroy” << endl; }

};

void UseMallocFree(void)

{

     Obj *a = (obj *)malloc(sizeof(obj)); // 申请动态内存

     a->Initialize();                          // 初始化

     //…

     a->Destroy(); // 清除工作

     free(a);      // 释放内存

}

void UseNewDelete(void)

{

     Obj *a = new Obj; // 申请动态内存并且初始化

     //…

     delete a;          // 清除并且释放内存

}

示例8 用malloc/free和new/delete如何实现对象的动态内存管理

类Obj的函数Initialize模拟了构造函数的功能，函数Destroy模拟了析构函数的功能。函数UseMallocFree中，由于malloc/free不能执行构造函数与析构函数，必须调用成员函数Initialize和Destroy来完成初始化与清除工作。函数UseNewDelete则简单得多。

所以我们不要企图用malloc/free来完成动态对象的内存管理，应该用new/delete。由于内部数据类型的“对象”没有构造与析构的过程，对它们而言malloc/free和new/delete是等价的。

既然new/delete的功能完全覆盖了malloc/free，为什么C++不把malloc/free淘汰出局呢？这是因为C++程序经常要调用C函数，而C程序只能用malloc/free管理动态内存。

如果用free释放“new创建的动态对象”，那么该对象因无法执行析构函数而可能导致程序出错。如果用delete释放“malloc申请的动态内存”，理论上讲程序不会出错，但是该程序的可读性很差。所以new/delete必须配对使用，malloc/free也一样。

9堆分配的几种方法对比：

1）realloc

void *realloc( void *memblock, size_t size );可以连续地址分配内存，指针总指向最初始位置，无法获的更大内存地址时，会删掉以前的空间，寻找更大的地方存放

2）malloc

void *malloc( size_t size );内存分配失败不提示，允许用户通过重载来实现捕获，已分配内存，可重新被覆盖。释放类，可不需调用虚拟函数表。

3）calloc：内部调用malloc

Allocates an array in memory with elements initialized to 0.

4）new，动态分配，指针数组

释放时若调用了虚函数，则会调用虚函数表，比如虚析构函数，当声明时没有virtual的类，就无虚函数表。new[count],当count 为0可能会崩溃

10内存耗尽怎么办？

如果在申请动态内存时找不到足够大的内存块，malloc和new将返回NULL指针，宣告内存申请失败。通常有三种方式处理“内存耗尽”问题。

（1）判断指针是否为NULL，如果是则马上用return语句终止本函数。例如：

void Func(void)

{

A *a = new A;

if(a == NULL)

{

     return;

}

…

}

（2）判断指针是否为NULL，如果是则马上用exit(1)终止整个程序的运行。例如：

void Func(void)

{

A *a = new A;

if(a == NULL)

{

     cout << “Memory Exhausted” << endl;

exit(1);

}

     …

}

（3）为new和malloc设置异常处理函数。例如Visual C++可以用_set_new_hander函数为new设置用户自己定义的异常处理函数，也可以让malloc享用与new相同的异常处理函数。详细内容请参考C++使用手册。

上述（1）（2）方式使用最普遍。如果一个函数内有多处需要申请动态内存，那么方式（1）就显得力不从心（释放内存很麻烦），应该用方式（2）来处理。（？？？exit貌似不会执行局部对象的析构函数，return则会执行。）

很多人不忍心用exit(1)，问：“不编写出错处理程序，让操作系统自己解决行不行？”

不行。如果发生“内存耗尽”这样的事情，一般说来应用程序已经无药可救。如果不用exit(1) 把坏程序杀死，它可能会害死操作系统。道理如同：如果不把歹徒击毙，歹徒在老死之前会犯下更多的罪。

有一个很重要的现象要告诉大家。对于32位以上的应用程序而言，无论怎样使用malloc与new，几乎不可能导致“内存耗尽”。我在Windows 98下用Visual C++编写了测试程序，见示例9。这个程序会无休止地运行下去，根本不会终止。因为32位操作系统支持“虚存”，内存用完了，自动用硬盘空间顶替。我只听到硬盘嘎吱嘎吱地响，Window 98已经累得对键盘、鼠标毫无反应。

我可以得出这么一个结论：对于32位以上的应用程序，“内存耗尽”错误处理程序毫无用处。这下可把Unix和Windows程序员们乐坏了：反正错误处理程序不起作用，我就不写了，省了很多麻烦。

我不想误导读者，必须强调：不加错误处理将导致程序的质量很差，千万不可因小失大。

void main(void)

{

     float *p = NULL;

     while(TRUE)

     {

         p = new float[1000000];

         cout << “eat memory” << endl;

         if(p==NULL)

              exit(1);

     }

}

示例9试图耗尽操作系统的内存

11 malloc/free的使用要点

10.1函数malloc的原型如下：

      void * malloc(size_t size);

用malloc申请一块长度为length的整数类型的内存，程序如下：

int *p = (int *) malloc(sizeof(int) * length);

我们应当把注意力集中在两个要素上：“类型转换”和“sizeof”。

1）malloc返回值的类型是void *，所以在调用malloc时要显式地进行类型转换，将void * 转换成所需要的指针类型。

2）malloc函数本身并不识别要申请的内存是什么类型，它只关心内存的总字节数。我们通常记不住int, float等数据类型的变量的确切字节数。例如int变量在16位系统下是2个字节，在32位下是4个字节；而float变量在16位系统下是4个字节，在32位下也是4个字节。最好用以下程序作一次测试：

cout << sizeof(char) << endl;

cout << sizeof(int) << endl;

cout << sizeof(unsigned int) << endl;

cout << sizeof(long) << endl;

cout << sizeof(unsigned long) << endl;

cout << sizeof(float) << endl;

cout << sizeof(double) << endl;

cout << sizeof(void *) << endl;

在malloc的“()”中使用sizeof运算符是良好的风格，但要当心有时我们会昏了头，写出 p = malloc(sizeof(p))这样的程序来。

10.2函数free的原型如下：

void free( void * memblock );

为什么free函数不象malloc函数那样复杂呢？这是因为指针p的类型以及它所指的内存的容量事先都是知道的（？？？知道，但并没有记录啊），语句free(p)能正确地释放内存。如果p是NULL指针，那么free对p无论操作多少次都不会出问题。如果p不是NULL指针，那么free对p连续操作两次就会导致程序运行错误。

12 new/delete的使用要点

运算符new使用起来要比函数malloc简单得多，例如：

int *p1 = (int *)malloc(sizeof(int) * length);

int *p2 = new int[length];

这是因为new内置了sizeof、类型转换和类型安全检查功能。对于非内部数据类型的对象而言，new在创建动态对象的同时完成了初始化工作。如果对象有多个构造函数，那么new的语句也可以有多种形式。例如

class Obj

{

public :

     Obj(void);         // 无参数的构造函数

     Obj(int x);        // 带一个参数的构造函数

…

}

void Test(void)

{

     Obj *a = new Obj;

     Obj *b = new Obj(1); // 初值为1

     …

     delete a;

     delete b;

}

如果用new创建对象数组，那么只能使用对象的无参数构造函数。例如

     Obj *objects = new Obj[100];    // 创建100个动态对象

不能写成

     Obj *objects = new Obj[100](1);// 创建100个动态对象的同时赋初值1

在用delete释放对象数组时，留意不要丢了符号‘[]’。例如

     delete []objects; // 正确的用法

delete objects;    // 错误的用法

后者相当于delete objects[0]，漏掉了另外99个对象。

13一些心得体会

我认识不少技术不错的C++/C程序员，很少有人能拍拍胸脯说通晓指针与内存管理（包括我自己）。我最初学习C语言时特别怕指针，导致我开发第一个应用软件（约1万行C代码）时没有使用一个指针，全用数组来顶替指针，实在蠢笨得过分。躲避指针不是办法，后来我改写了这个软件，代码量缩小到原先的一半。（高质量CC++编程，第7章作者原话）

我的经验教训是：

（1）越是怕指针，就越要使用指针。不会正确使用指针，肯定算不上是合格的程序员。

（2）必须养成“使用调试器逐步跟踪程序”的习惯，只有这样才能发现问题的本质。

参考：《高质量CC++编程》第7章

操作系统的内存管理

以前，在内存空间不够大时，同时运行的应用程序的数量就会受到很大限制。甚至当某个应用程序在某个运行时所需内存超过物理内存时，该应用程序就会无法运行。现代操作系统（诸如 Windows 和 Linux）的内存管理都能解决这个问题，解决的方法就是虚拟内存的引入。

本质上虚拟内存就是要让一个程序的代码和数据在没有全部载入内存时即可运行。运行过程中，当执行到尚未载入内存的代码，或者要访问还没有载入到内存的数据时，虚拟内存管理器动态地将这部分代码或数据从硬盘载入到内存中。而且在通常情况下，虚拟内存管理器也会相应地先将内存中某些代码或者数据置换到硬盘中，为即将载入的代码或数据腾出空间。

因为内存和硬盘之间的数据传输相对代码执行来说，是非常慢的操作，因此虚拟内存管理器在保证工作正确的前提下，还必须考虑效率因素。比如，它需要优化置换算法，尽量避免就要执行的代码或访问的数据刚被置换出内存，而很久没有访问的代码或数据却一直驻留在内存中。另外它还需要将驻留在内存的各个进程的代码或数据维持在一个合理的数量上，并且根据该进程的性能表现动态调整此数量，等等，使得程序运行时将其涉及的磁盘 I/O 次数降到尽可能低，以提高程序的运行性能。

Windows内存管理

如果从应用程序的角度来看 Windows虚拟内存管理系统，可以扼要地归结为一句话。即Win32虚拟内存管理器为每一个 Win32进程提供了进程私有且基于页的 4 GB（32 位）大小的线性虚拟地址空间。这句话可以分解如下：

（1）“进程私有”意味着每个进程都只能访问属于自己的地址空间，而无法访问其他进程的地址空间，也不用担心自己的地址空间会被其他进程看到（父子进程例外，比如调试器利用父子进程关系来访问被调试进程的地址空间，这里不详述）。需要注意的是，进程运行时用到的 dll 并没有属于自己的虚拟地址空间。而是其所属进程的虚拟地址空间，dll 的全局数据，以及通过 dll函数申请的内存都是从调用其进程的虚拟地址空间中开辟的。

（2）“基于页”是指虚拟地址空间被划分为多个称为“页”的单元，页的大小由底层处理器决定，x86中页的大小为 4 KB。页是Win32虚拟内存管理器处理的最小单元，相应的物理内存也被划分为多个页。虚拟内存地址空间的申请和释放，以及内存和磁盘的数据传输或置换都是以页为最小单位进行的。

（3）“4 GB 大小”意味着进程中的地址取值范围可以从 0x00000000 到0xFFFFFFFF。Win32 将低区的2 GB留给进程使用，高区的 2 GB 则留给系统使用。

Win32 中用来辅助实现虚拟内存的硬盘文件称为“调页文件”，可以有 16 个，调页文件用来存放被虚拟内存管理器置换出内存的数据。当这些数据再次被进程访问时，虚拟内存管理器会先将它们从调页文件中置换进内存，这样进程可以正确访问这些数据。用户可以自己配置调页文件。出于空间利用效率和性能的考虑，程序代码（包括 exe和 dll文件）不会被修改，所以当它们所在的页被置换出内存时，并不会被写进调页文件中，而是直接抛弃。当再次被需要时，虚拟内存管理器直接从存放它们的 exe或dll文件中找到它们并调入内存。另外对 exe和dll文件中包含的只读数据的处理与此类似，也不会为它们在调页文件中开辟空间。

当进程执行某段代码或者访问某些数据，而这些代码或者数据还没有在内存时，这种情形称为“缺页错误”。缺页错误的原因有很多种，最常见的一种就是已经提到的，即这些代码和数据被虚拟内存管理器置换出了内存，这时虚拟内存管理器在这段代码执行或者这些数据被访问前将它们调入内存。这个操作对开发人员来说是透明的，因此大大简化了开发人员的负担。但是调页错误涉及磁盘 I/O，大量的调页错误会大大降低程序的总体性能。因此需要了解缺页错误的主要原因，以及规避它们的方法。

使用虚拟内存

Win32 中分配内存分为两个步骤：“预留”和“提交”。因此在进程虚拟地址空间中的页有三种状态：自由（free）、预留（reserved）和提交（committed）。

（1）自由也叫空闲，表示此页尚未被分配，可以用来满足新的内存分配请求。

（2）预留指从虚拟地址空间中划出一块区域（region，页的整数倍数大小），划出之后这个区域中的页不能用来满足新的内存分配请求，而是用来供要求“预留”此段区域的代码以后使用。预留时并没有分配物理存储，只是增加了一个描述进程虚拟地址空间使用状态的数据结构（VAD，虚拟地址描述符），用来记录这段区域已被预留。“预留”操作相对较快，因为没有真正分配物理存储。也正因为没有分配真正的物理存储，所以预留的空间并不能够直接访问，对预留页的访问会引起“内存访问违例”（内存访问违例会导致整个进程立刻退出，而不仅仅是中止引起该违例的线程）。

（3）提交，若想得到真正的物理存储，必须对预留的内存进行提交。提交会从调页文件中开辟空间，并修改VAD 中的相应项。注意，提交时也并没有立刻从物理内存中分配空间，而只是从磁盘的调页文件中开辟空间。这个空间用做以后置换的备份空间，直到有代码第一次访问这段提交内存中的某些数据时，系统发现并没有真正的物理内存，抛出缺页错误。虚拟内存管理器处理此缺页错误，直到这时才会真正分配物理内存，提交也可以在预留的同时一起进行。需要注意的是，提交操作会从调页文件中开辟磁盘空间，所以比预留操作的时间长。

这也是Win32虚拟内存管理中的 demand-paging （请求－分页）策略的一个体现，即不到真正访问时，不会为某虚拟地址分配真正的物理内存。这种策略一是出于性能考虑，将工作分段完成，提高总体性能；二是出于空间效率考虑，不到真正访问时，Win32 总是假定进程不会访问大多数的数据，因而也不必为它们开辟存储空间或将其置换进物理内存，这样可以提高存储空间（磁盘和物理内存）的使用效率。

设想某些程序对内存有很大的需求，但又不是立即需要所有这些内存，那么一次就从物理存储中开辟空间满足这些还只是“潜在”的需求，从执行性能和存储空间效率来说，都是一种浪费。因为只是“潜在”需求，极有可能这些分配的内存中很大一部分最后都没有真正被用到。如果在申请的时候就一次性为它们分配全部物理存储，无疑会极大地降低空间的利用效率。

另一方面，如果完全不用预留及提交机制，只是随需分配内存来满足每次的请求，那么对一个会在不同时间点频繁请求内存的代码来说，因为在它请求内存的不同时间点的间隙极有可能会有其他代码请求内存。这样这段在不同时间点频繁请求内存的代码请求得到的内存因为虚拟地址不连续，无法很好地利用空间 locality特性，对其整体进行访问（比如遍历操作）时就会增加缺页错误的数量，从而降低程序的性能。

预留和提交在Win32中都使用VirtualAlloc函数完成，预留传入MEM_RESERVE参数，提交传入 MEM_COMMIT参数。释放虚拟内存使用VirtualFree函数，此函数根据不同的传入参数，与VirtualAlloc相对应，可以释放与虚拟地址区域相对应的物理存储，但该虚拟地址区域还可处于预留状态，也可以连同虚拟地址区域一起释放，该段区域恢复为自由状态。

线程栈和进程堆的实现都利用了这种预留和提交两步机制，下面仅以线程栈为例来说明Win32系统是如何使用这种预留和提交两步机制的。

创建线程栈时，只是一个预留的虚拟地址区域，默认是 1 MB （此大小可在 CreateThread或在链接时通过链接选项修改），初始时只有前两页是提交的。当线程栈因为函数的嵌套调用需要更多的提交页时，虚拟内存管理器会动态地提交该虚拟地址区域中的后续页以满足其需求，直到到达 1 MB的上限。当到达此预留区域大小的上限（默认 1 MB）时，虚拟内存管理器不会增加预留区域大小，而是在提交最后一页时抛出一个栈溢出异常，抛出栈溢出异常时该栈还有一页空间可用，程序仍可正常运行。而当程序继续使用栈空间，用完最后一页后，还继续需要存储空间，这时就超过了上限，会直接导致进程退出。

所以为防止线程栈溢出导致整个程序退出，应该注意尽量控制栈的使用大小。比如减少函数的嵌套层数，减少递归函数的使用，尽量不要在函数中使用太大的局部变量（大的对象可以从堆中开辟空间存放，因为堆会动态扩大，而线程栈的可用内存区域在线程创建时就已固定，之后在整个线程生命期间无法扩展）。

另外为了防止因为一个线程栈的溢出导致整个进程退出，可以对可能会产生线程栈溢出的线程体函数加异常处理，捕获在提交最后一页时抛出的溢出异常，并做出相应处理。

访问虚拟内存时的处理流程

对某虚拟内存区域进行了预留并提交之后，就可以对该区域中的数据进行访问了，下图描述了当程序对某段内存访问时的处理流程：

如图 5-1 所示，当该数据已在物理内存中时，虚拟内存管理器只需将指向该数据的虚拟地址映射为物理指针，即可访问到物理内存中的真正数据。这一步不会涉及磁盘 I/O，速度相对较快。

当第一次访问一段刚刚提交的内存中的数据时，因为并没有真正的物理内存分配给它。或者该数据以前已被访问过，但是被虚拟内存管理器置换出了内存。这两种情形都会引发缺页错误，虚拟内存管理器此时会处理这一缺页错误，它先检测此数据是否在调页文件中已有备份空间（exe和 dll的代码页和只读数据页情形与此类似，但是其备份空间不在调页文件，而是包含它们的 exe 或 dll 文件）。如果是这两种情况，表明访问的数据在磁盘中有备份，接下来虚拟内存管理器就需要在物理内存中找到合适的页，并将存放在磁盘的备份数据置换进物理内存。

虚拟内存管理器首先查询当前物理内存中是否有空闲页，虚拟内存管理器维护一个称为“页帧数据库”（page-frame database）的数据结构，此数据结构是操作系统全局的，当Windows 启动时被初始化，用来跟踪和记录物理内存中每一个页的状态，它会用一个链表将所有空闲页连接起来，当需要空闲页时，直接查找此空闲页链表，如果有，直接使用某个空闲页；否则根据调页算法首先选出某个页。（需要指出的是，虚拟内存管理器调页时并不是只调入一个页，为了利用局部特性，它在调入包含所需数据的页的同时，会将其附近的几个页一起调入内存。这里为了简单和清楚起见，假定只调入目标页。但应该意识到Win32 调页时的这个特性，因为可以利用它来提高程序效率。这个页将会用来存放即将从磁盘置换进来的页的内容。）选出某个内存页后，接着检查此页状态，如果此页自上次调进内存以来尚未被修改过，则直接使用此页（代码页和只读页也可以直接使用）；反之，如果此页已被修改过（“脏”），则需要先将此页的内容“写”到调页文件中与此页相对应的备份页中，并随即将此页标为空闲页。

图 5-1 访问虚拟内存的处理流程

现在，有了一个空闲页用来存放即将要访问的数据。此时，虚拟内存管理器会再次检测，此数据是否是刚被申请的内存且是第一次被访问。如果是，则直接将此空闲页清0使用即可（不必从磁盘中将其备份页的内容读进，因为该备份页中的内容无意义）；如果不是，则需要将调页文件中该页的备份页读到此空闲页中，并随即将此页的状态从空闲页改为活动页。

此时，此数据已在物理内存页中，通过虚拟地址映射到物理地址，即就可访问此数据了。

上述为访问成功时的情形，但情形并非总是如此。比如当用户定义了一个数组，而此数组刚好在其所在页的下边界，且此页的下一页刚好是自由或者预留的（不是提交的，即没有真正的物理存储）。当程序不小心向下越界访问此数组，则首先引发缺页错误。随即虚拟内存管理器在处理缺页错误时检测到它也不在调页文件中，这就是所谓的“访问违例”（access violation）。访问违例意味着要访问的地址所在的虚拟内存页还没有被提交，即没有实际的物理存储与之对应，访问违例会直接导致整个进程退出（即 crash）。

可以看到，指针越界访问的后果根据运行时实际情况而有所不同。如上所述，当数组并非处于其所在页的边界，越界后还在同一页中，这时只会“误访问”（误读或误写，其中误读只会影响到正在执行的代码；误写则会影响到其他处代码的执行）该页中其他数据，而不会导致整个进程的 crash。即使在该数组真的处于其所在页的边界，且越界后指针值落在了其相邻页。但如果此相邻页碰巧也为一个提交页，此时仍然只是“误访问”，也不会导致进程的 crash。这也意味着，同一个应用程序的代码中存在着指针越界访问错误，运行时有时 crash，但有时则不会。

Microsoft提供了一个监测指针越界访问的工具 pageheap，它的原理就是强制使每次分配的内存都位于页的边界，同时强制该页的相邻页为自由页（即不分配其相邻页给程序使用）。这样每次越界访问都会立即引起 access violation，导致程序crash。从而使得指针越界访问错误在开发期间一定会被暴露出来，而不会发生某个指针越界访问错误一直隐藏到Release版本，直到最终用户使用时才被发现的情形。

虚拟地址到物理地址的映射

如上所述，在确保访问的数据已在物理内存中后，还需要先将虚拟地址转换为物理地址，即“地址映射”，才能够真正访问此数据。本节讲述 Win32 中虚拟内存管理器如何将虚拟地址映射为物理地址。

Win32 通过一个两层表结构来实现地址映射，因为 4 GB 虚拟地址空间为每个进程私有，相应地，每个进程都维护一套自己的层次表结构用来实现其地址映射。第一层表称为“页目录”（page directory），实际上就是一个内存页（4 KB = 4 096 byte）。这一页以四个字节为单元分为 1 024项，每一项称为一个“页目录项”（Page Directory Entry，PDE）；第二层表称为“页表”（page table），共有1 024个页表。页目录中每一个页目录项PDE 对应这一层中的某一个页表，每一个页表也占了一个内存页。这一页中的 4 KB，即4 096 个字节也像页目录那样被分成 1 024 项，每项4个字节，页表的每一项则称为“页表项”（Page Table Entry，PTE）。每一个页表项PTE都指向物理内存中的某一个页帧，如图 5-2所示。

已经知道，Win32提供了 4 GB（32位）大小的虚拟地址空间。因此每个虚拟地址都是一个 32位的整数值，这32 位由三个部分组成，如图 5-3所示。

图 5-3 虚拟地址空间

这三个部分中的第一部分，即前 10位为页目录下标，用其可以定位在页目录的 1 024项中的某一项。根据定位到的那一项的项值，可以找到第 2 层页表中的某一个页表。虚拟地址的第二部分，即中间的 10位为页表下标，可用来定位刚刚找到的页表的1 024项中的某一项。此项值可以找到物理内存中的某一个页，此页包含此虚拟地址所代表的数据。最后用虚拟地址的第三部分，即最后 12 位可用来定位此物理页中的特定的字节位置，12 位刚好可以定位一个页中的任意位置的字节。

举一个具体的例子，假设在程序中访问一个指针（Win32中的“指针”意味虚拟地址），此指针值为0x2A8E317F，图 5-4所示为虚拟地址到物理地址的映射过程。

图 5-4 虚拟地址（0x2A8E317F）到物理地址的映射过程

0x2A8E317F 的二进制写法为 0010101010,0011100011,000101111111，为了方便起见，将这 32 位分成 10 位、10 位和 12 位。第一个 10 位 00101010 用来定位页目录中的页目录项，因为页目录项为四个字节，定位前将此 10 位左移两位，即 0010101000（0x2A8）。再用此值作为下标找到对应的页目录项，此页目录项指向一个页表。同样方法再用第二个 10位 0011100011 定位此页表中的页表项。此页表项指向真正的物理内存，然后用最后 12 位000101111111 定位页内的数据（此时这 12位不用再左移，因为物理页内定位时，需要能定位到每一个字节。而不像页目录和页表中，只需要定位每 4个字节的第 1个字节），即为此指针指向的数据。

上面假设的是此数据已在物理内存中，其实，“判断访问的数据是否在内存中”这一步骤，也是在这个地址映射过程中完成的，Win32 总是假使数据已在物理内存中，并进行地址映射。页表项中有一位用来标识包含此数据的页是否在物理内存页中（？？？那实际用于指示物理页的数据只有31位？，也就是说程序能访问到的只有2G？剩下2G的美其名曰：留给系统用），当取得页表项时，检测此位，如果在，就是本节描述的过程，如果不在，则抛出缺页错误，此时此页表项中包含了此数据是否在调页文件中，如果不在，则为访问违例，如果在，此页表项可查出了此数据页在哪个调页文件中，以及此数据页在该调页文件中的起始位置，然后根据这些信息将此数据页从磁盘中调入物理内存中，再继续进行地址映射过程。已经说过，为了实现虚拟地址空间各进程私有，每个进程都拥有自己的页目录和页表结构，对不同进程而言，页目录中的页目录项值（PDE），以及页表中的页表项值（PTE）都是不同的，因此相同的指针（虚拟地址）被不同的进程映射到的物理地址也是不同的。这也意味着，在不同进程间传递指针是没有意义的。

虚拟内存空间使用状态记录

当通过VirtualAlloc申请一块虚拟内存时，虚拟内存管理器是如何知道哪些内存块是自由的，可以用来满足此次内存请求呢？即 Win32 虚拟内存如何维护和记录每一个进程的 4 GB 虚拟内存地址空间的使用状态，如各个区域的状态、大小及起始地址呢？

上一节中，读者也许会认为可以通过遍历页目录和页表中的项值来收集虚拟内存空间的使用状态，但这样做首先有效率问题，因为每次申请内存都需要做一次搜索。但这个方法不仅仅是因为效率有问题，而且还是行不通的，对预留的页来说，虚拟内存管理器并没有为之分配物理存储。所以也就不会为其填写页表项，这时遍历页表无法分辨某块虚拟内存是自由还是预留的。另外即使对提交页来说，遍历页表也无法得到完整的信息，正如 5.1.1节中提到的 Win32 在虚拟内存管理时用到的主要策略 demand-paging，即 Win32虚拟内存管理器在程序没有实际访问某块内存前，总是假定这块内存不会被访问到，因此不会为这块内存做过多处理，包括不会为其分配真正的物理内存空间，甚至页表，即进程中用来完成虚拟地址到物理地址映射的页表的存储空间也是随需分配的。

Win32 虚拟内存管理器使用另外一个数据结构来记录和维护每个进程的 4 GB 虚拟地址空间的使用及状态信息，这就是虚拟地址描述符树（Virtual Address Descriptor，VAD）。每一个进程都有一个自己的 VAD 集合，这个集合中的 VAD 被组织成一个自平衡二叉树，以提高查找的效率。另外只有预留或者提交的内存块才会有VAD，自由的内存块没有VAD（因此不在VAD树结构中的虚拟地址块就是自由的）。VAD的组织如图 5-5 所示。

（1）当程序申请一块新内存时，虚拟内存管理器只需访问VAD树。找到两个相邻VAD，只要小的 VAD 的上限与大的 VAD 的下限之间的差值满足所申请的内存块的大小需求，即可使用二者之间的虚拟内存。

（2）当第一次访问提交的内存时，虚拟内存管理器根据上一节描述的流程。即总是假定该数据页已在物理内存中，并进行虚拟地址到物理地址的转换。当找到相应的页目录项后发现该页目录项并没有指向一个合法的页表，它就会查找该进程的VAD 树。找到包含该地址的 VAD，并根据 VAD 中的信息，比如该内存块的大小、范围，以及在调页文件中的起始位置等，随需生成相应的页表项，然后从刚才发生缺页错误的地方继续进行地址映射。由此可以看出，一个虚拟内存页被提交时，除了在调页文件中开辟一个备份页之外，不会生成包含指向它的页表项的页表，也不会填充指向它的页表项，更不会为之开辟真正的物理内存页，而是直到第一次访问这个提交页时，才会“随需地”从VAD中取得包含该页的整个区域的信息，生成相应页表，并填充相应页的表项。

图 5-5 VAD 的组织结构

（3）当访问预留的内存时，虚拟内存管理器也是根据上一节描述的流程进行虚拟地址到物理地址的映射，找到相应的页目录项后发现该页目录项并没有指向一个合法的页表，它就会查找该进程的 VAD 树，找到包含该地址的 VAD。这时它会发现此段内存块只是预留的，而没有提交，即并没有对应的真正的物理存储，这时直接抛出访问违例，进程退出。 （为什么要一个“预留”，为什么不直接合并到提交？？？ ）

（4）当访问自由的内存时，虚拟内存管理器还是根据上一节描述的流程进行虚拟地址到物理地址的映射。找到相应的页目录项后发现该页目录项并没有指向一个合法的页表，它就会查找该进程的 VAD 树，发现并没有 VAD 包含此虚拟地址，此时可以知道该地址所在的虚拟地址页是自由状态，直接抛出访问违例，进程退出。

进程工作集

因为频繁的调页操作引起的磁盘 I/O 会大大降低程序的运行效率，因此对每一个进程，虚拟内存管理器都会将其一定量的内存页驻留在物理内存中。并跟踪其执行的性能指标，动态调整这个数量。Win32 中驻留在物理内存中的内存页称为进程的“工作集”（workingset），进程的工作集可以通过“任务管理器”查看，其中“内存使用”列即为工作集大小。

工作集是会动态变化的，进程初始时只有很少的代码页和数据页被调入内存。当执行到未被调入内存的代码或者访问到尚未调入内存的数据时，这些代码页或者数据页会被调入物理内存，工作集也随之增长。但工作集不能无限增长，系统为每个进程都定义了一个默认的最小工作集（根据系统物理内存大小，此值可能为 20~50 MB）和最大工作集（根据系统物理内存大小，此值可能为 45~345 MB）。当工作集到达最大工作集，即进程需要再次调入新页到物理内存中时，虚拟内存管理器会将其原来的工作集中的某些页先置换出内存，然后将需要调入的新页调入内存。

因为工作集的页驻留在物理内存中，因此对这些页的访问不涉及磁盘 I/O，相对而言非常快；反之，如果执行的代码或者访问的数据不在工作集中，则会引发额外的磁盘 I/O，从而降低程序的运行效率。一个极端的情况就是所谓的颠簸或抖动（thrashing），即程序的大部分的执行时间都花在了调页操作上，而不是代码执行上。

如前所述，虚拟内存管理器在调页时，不仅仅只是调入需要的页，同时还将其附近的页也一起调入内存中。综合这些知识，对开发人员来说，如果想提高程序的运行效率，应该考虑以下两个因素。

（1）对代码来说，尽量编写紧凑代码，这样最理想的情形就是工作集从不会到达最大阀值。在每次调入新页时，也就不需要置换已经载入内存的页。因为根据 locality特性，以前执行的代码和访问的数据在后面有很大可能会被再次执行或访问。这样程序执行时，发生的缺页错误数就会大大降低，即减少了磁盘 I/O，在资源管理器中也可以看到一个程序执行时截至当时共发生的缺页错误次数。即使不能达到这种理想情形，紧凑的代码也往往意味着接下来执行的代码更大可能就在相同的页或相邻页。根据时间 locality特性，程序 80%的时间花在了 20%的代码上。如果能将这 20%的代码尽量紧凑且排在一起，无疑会大大提高程序的整体运行性能。

（2）对数据来说，尽量将那些会一起访问的数据（比如链表）放在一起。这样当访问这些数据时，因为它们在同一页或相邻页，只需要一次调页操作即可完成；反之，如果这些数据分散在多个页（更糟的情况是这些页还不相邻），那么每次对这些数据的整体访问都会引发大量的缺页错误，从而降低性能。利用Win32提供的预留和提交两步机制，可以为这些会一同访问的数据预留出一大块空间。此时并没有分配实际存储空间，然后在后续执行过程中生成这些数据时随需为它们提交内存。这样既不浪费真正的物理存储（包括调页文件的磁盘空间和物理内存空间），又能利用locality特性。另外内存池机制也是基于类似的考虑。

Win32内存相关 API

在Win32平台下，开发人员可以通过如下 5组函数来使用内存（完成申请和释放等操作）。

（1）传统的 CRT 函数（malloc/free 系列）：因为这组函数的平台无关性，如果程序会被移植到其他非 Windows平台，则这组函数是首选。也正因为这组函数非 Win32专有，而且介绍这组函数的资料俯拾皆是，这里不作详细介绍。

（2）global heap/local heap函数（GlobalAlloc/LocalAlloc 系列）：这组函数是为了向后兼容而保留的。在 Windows 3.1平台下，global heap为系统中所有进程共有的堆，这些进程包括系统进程和用户进程。它们对此 global heap内存的申请会交错在一起，从而使得一个用户进程的不小心的内存使用错误会导致整个操作系统的崩溃。local heap 又被称为“private heap”，与 global heap 相对应，local heap为每个进程私有。进程通过LocalAlloc 从自己的 local heap里申请内存，而不会相互干扰。除此之外，进程不能通过另外的用户自定义堆或者其他方式动态地申请内存。到了 Win32 平台，由于考虑到安全因素，global heap已经废弃，local heap也改名为“process heap”。为了使得以前针对 Windows 3.1 平台写的应用程序能够运行在新的Win32平台上，GlobalAlloc/ LocalAlloc 系列函数仍然得到沿用，但是这一系列函数最后都是从process heap 中分配内存。不仅如此，Win32 平台还允许进程除 process heap 之外生成和使用新的用户自定义堆，因此在 Win32 平台下建议不使用GlobalAlloc/LocalAlloc 系列函数进行内存操作，因此这里不详细介绍这组函数。

（3）虚拟内存函数（VirtualAlloc/VirtualFree系列）：这组函数直接通过保留（reserve）和提交（commit）虚拟内存地址空间来操作内存，因此它们为开发人员提供最大的自由度，但相应地也为开发人员内存管理工作增加了更多的负担。这组函数适合于为大型连续的数据结构数组开辟空间。

（4）内存映射文件函数（CreateFileMapping/MapViewOfFile 系列）：系统使用内存映射文件函数系列来加载.exe或者.dll文件。而对开发人员而言，一方面通过这组函数可以方便地操作硬盘文件，而不用考虑那些繁琐的文件 I/O 操作；另一方面，运行在同一台机器上的多个进程可以通过内存映射文件函数来共享数据（这也是同一台机器上进程间进行数据共享和通信的最有效率和最方便的方法）。

（5）堆内存函数（HeapCreate/HeapAlloc 系列）：Win32 平台中的每个堆都是各进程私有的，每个进程除了默认的进程堆，还可以另外创建用户自定义堆。当程序需要动态创建多个小数据结构时，堆函数系列最为适合。一般来说 CRT 函数（malloc/free）就是基于堆内存函数实现的。

1．虚拟内存

虚拟内存相关函数共有 4 对，即 VirtualAlloc/VirtualFree、VirtualLock/VirtualUnlock、

VirtualQuery/VirtualQueryEx 及 VirtualProtect/VirtualProtectEx。其中最重要的是第一对，本节主要介绍这一对。

LPVOID VirtualAlloc(

LPVOID lpAddress,

DWORD dwSize,

DWORD flAllocationType,

DWORD flProtect

);

VirtualAlloc 根据 flAllocationType 的不同，可以保留一段虚拟内存区域（MEM_ RESERVE）或者提交一段虚拟内存区域（MEM_COMMIT）。当保留时，除了修改进程的VAD 之外（准确地说是增加了一项），并没有分配其他资源，如调页文件空间或者实际物理内存，甚至没有创建页表项。因此非常快捷，而且执行速度与保留空间的大小没有关系。

因为保留仅仅只是让内存管理器预留一段虚拟地址空间，并没有实在的存储（硬盘上的调页文件空间或者物理内存），因此访问保留地址会引起访问违例，这是一种严重错误，会直接导致进程退出；相反，提交虚拟内存时，内存管理器必须从系统调页文件中开辟实际的存储空间，因此速度会比保留操作慢。但是需要注意的是，此时在物理内存中并没有立刻分配空间用来与这段虚拟内存空间相对应，甚至也没有相应的页表项被创建，但是提交操作会相应修改VAD 项。只有首次访问这段虚拟地址空间中的某个地址时，由于缺页中断，虚拟内存管理器查找VAD，接着根据VAD 的内容，动态创建PTE，然后根据PTE信息，分配物理内存页，并实际访问该内存。由此可见，真正花费时间的操作不是提交内存，而是对提交内存的第一次访问！这种 lazy-evaluation（即假设不使用） 机制对程序运行性能是十分有益的，因为如果某个程序提交了大段内存，但只是零星地对其中的某些页进行访问，如果没有这种lazy-evaluation机制，提交大段内存会极大地降低系统的性能。

与之相对，VirtualFree 释放内存，它提供两种选择：可以将提交的内存释放给系统，但是不释放保留的虚拟内存地址空间；也可以在释放内存的同时将虚拟内存地址空间一并释放，这样这块虚拟内存地址空间的状态变回初始的自由状态。如果内存是提交状态，VirtualFree因为会释放真正的存储空间而比较慢；如果只是释放保留的虚拟内存地址空间，那么因为只需要修改VAD，该操作会很快。

除此之外，VirtualLock 保证某块内存在lock 期间一直在物理内存中，因此对该内存的访问不会引起缺页中断。lock 的内存用VirtualUnlock解锁。因为VirtualLock 会把内存锁定在物理内存中，如果这些内存实际中访问的并不频繁，那么会使得其他经常使用到的内存反而增大了被调页出去的概率，从而降低了系统的整体性能，因此在实际使用中，并不推荐使用 VirtualLock/VirtualUnlock 函数。VirtualQuery 可以获得传入指针所在的虚拟内存块的状态，如包含该指针所在页的虚拟内存区域的基址，以及该区域的状态等。VirtualProtect可用来修改某段区域的提交内存页的存取保护标志。

2．内存映射文件

内存映射文件主要有三个用途，Windows利用它来有效使用 exe 和dll文件，开发人员利用它来方便地访问硬盘文件，或者实现不同进程间的内存共享。第一种这里不详细介绍，只介绍后两种用途。首先讨论它提供的方便访问硬盘文件的机制，一旦通过这种机制将一个硬盘文件（部分或者全部）映射到进程的一段虚拟地址空间中，读写该文件的内容就像通过指针访问变量一样。假设 pViewMem为文件映射到内存的首址，那么：

*pViewMem = 100; //写文件的第1 个字节

char ch = *(pViewMem + 50); //读文件的第50个字节内容

下面介绍这种机制的使用步骤。

（1） 新建或者打开一个硬盘文件。

此步骤用来获得一个文件对象的句柄，用 CreateFile 函数来新建或者打开一个文件：

HANDLE CreateFile(

PCSTR pszFileName,

DWORD dwDesiredAccess,

DWORD dwShareMode,

PSECURITY_ATTRIBUTES psa,

DWORD dwCreationDisposition,

DWORD dwFlagsAndAttributes,

HANDLE hTemplateFile);

其中pszFileName参数指示该文件的路径名，dwDesiredAccess参数表示该文件内容将会被如何访问，此参数包括０、GENERIC_READ、GENERIC_WRITE，以及 GENERIC_READ | GENERIC_WRITE 共4种可能，分别表示“不能读也不能写”（在只为了读取该文件属性时使用）、“只读”、“只写”，以及“既可读也可写”；dwShareMode 参数用来限定对该文件的任何其他访问的权限，也包括上述 4 种类型。剩余的几个参数因为与要讨论的问题关系不大，所以不赘述。

此函数成功时，会返回一个文件对象句柄；否则会返回INVALID_HANDLE_VALUE。

（2）创建或者打开一个文件映射内核对象。

还需要有一个文件映射内核对象，正是它真正将文件内容映射到内存中。如果已经存在此内核对象，只需通过 OpenFileMapping 函数将其打开即可，这个函数返回该命名对象的句柄。大多数情况下，需要新建一个文件映射内核对象，此时调用CreateFileMapping函数：

HANDLE CreateFileMapping(

HANDLE hFile,

PSECURITY_ATTRIBUTES psa,

DWORD fdwProtect,

DWORD dwMaximumSizeHigh,

DWORD dwMaximumSizeLow,

PCTSTR pszName);

hFile 参数是第一个步骤中返回的文件内核对象句柄；psa 参数是指明内核对象安全特性的，不详述；fdwProtect参数指明了对映射到内存页中的文件内容的存取权限，这个权限必须与第一个步骤中的文件访问权限对应；dwMaximumSizeHigh 和 dwMaximum SizeLow参数指明映射的最大的空间大小，因为 Windows 支持大小达到 64 位的文件，因此需要两个32位的参数；pszName 为内核对象名称。

此步只是创建了一个文件映射内核对象，并没有预留或者提交虚拟地址空间，更没有物理内存页被分配出来存放文件内容。

（3）映射文件的内容到进程虚拟地址空间。

访问文件内容之前，必须将要访问的文件内容映射到内存中，通过 MapViewOfFile 函数完成：

PVOID MapViewOfFile(

HANDLE hFileMappingObject,

DWORD dwDesiredAccess,

DWORD dwFileOffsetHigh,

DWORD dwFileOffsetLow,

SIZE_T dwNumberOfBytesToMap);

其中参数分别为：用来映射内存映射内核对象的句柄，映射的文件内容到内存内存页的存取权限，需要映射的文件内容的起始部分在文件中的偏移及大小。映射时并不需要一次将整个文件的内容全部映射到内存中。

这个函数的操作包括从进程虚拟地址空间中预留出所需映射大小的一段区域，然后提交。提交时并不是从系统的调页文件中开辟空间用来作为该段区域的备份存储，而是内存映射内核对象所对应的文件的指明区域。与虚拟内存使用的惟一不同就是该段虚拟地址空间区域的备份存储不同，其他都是一样的。同样，此时并没有真正的物理内存开辟出来，直到通过返回的指针访问已经映射到内存中的文件内容时，因为发生缺页错误，系统才会分配物理内存页，并将对应的文件存储中的内容调页到该物理内存页。

（4）访问文件内容。

现在可以通过 MapViewOfFile 函数返回的指针来访问该段映射到内存中文件内容，就像本节演示的那样，通过指针访问硬盘文件内容。

这里需要提醒的是，通过该指针修改文件内容时，修改的结果常常不会立刻反映到文件中，因为实际上是在对调入物理内存页中的数据进行修改。考虑到性能因素，该页并不会每做一次修改就立刻将该修改同步到硬盘文件中。如果需要在某个时候强制将之前所做的修改一次性同步到与之对应的硬盘文件中时，可以通过 FlushViewOfFile 函数达到这个目的：

BOOL FlushViewOfFile(PVOID pvAddress, SIZE_T dwNumberOfBytesToFlush);

这个函数传入需要将修改同步到硬盘文件中的内存块的起始地址和大小。

（5）取消文件内容到进程虚拟地址空间的映射。

当该段映射到内存中的文件内容访问完毕，不再需要访问时，为了有效地利用系统的资源，应该及时回收该段内存，这时调用 UnmapViewOfFile 函数：

BOOL UnmapViewOfFile(PVOID pvBaseAddress);

此函数传入MapViewOfFile 函数返回的指针，系统回收对应的 MapViewOfFile 调用时预留并提交的虚拟内存地址空间区域，这样该段区域可被其他申请使用。另外因为对应的备份存储不是系统的调页文件，所以不存在备份存储回收的问题。

（6）关闭文件映射内核对象和文件内核对象。

最后，在完成任务不再使用该文件时，通过CloseHandle(hFile)和CloseHandle (hMapping)来关闭文件并释放内存映射文件的内核对象句柄。

下面接着讨论如何利用内存映射文件内核对象来进行进程间的内存共享。

进程间通过内存映射文件进行内存共享时，该内存映射文件内核对象常常不是基于某一个硬盘文件，而是从系统的调页文件中开辟空间作为临时用做共享的存储空间。因此与单纯地利用内存映射文件来访问硬盘文件内容稍有不同，下面是通过内存映射文件来进行进程间内存共享的步骤。假设有进程A 和进程B，进程A通过CreateFileMapping 创建一个基于系统调页文件的名为“SharedMem”的内存映射文件内核对象：

HANDLE m_hFileMapA = CreateFileMapping

(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0,

10 * 1024, TEXT("SharedMem"));

需要注意的是，因为现在不再基于普通的硬盘文件，所以不需要调用 CreateFile 来新建或者打开文件这个步骤，注意此时传入的文件句柄参数为 INVALID_HANDLE_VALUE，此参数代表从调页文件中开辟空间作为共享内存。

进程B 通过OpenFileMapping 打开刚才进程 A 创建的名为“SharedMem”的内存映射文件内核对象：

HANDLE m_hFileMapB = OpenFileMapping(..., TEXT("SharedMem"));

进程A和进程B都可以用此内存映射文件内核对象将从系统调页文件中开辟的那块存储空间的全部或者部分映射到内存中，然后即可使用。

进程A：

...

PVOID pViewA = MapViewOfFile(m_hFileMapA, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0);

...

进程B：

...

PVOID pViewB = MapViewOfFile(m_hFileMapB, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0);

...

它们各自对该共享内存的修改都能够及时地被对方看到。另外需要注意的是，它们映射到的虚拟内存空间区域并不一定有相同的起始地址，这是因为它们拥有自己的虚拟地址空间。

还有一个需要引起注意，但很难发现的问题是因为创建基于系统调页文件的内存映射文件内核对象是通过传入hFile为INVALID_HANDLE_VALUE 的参数来标记的，而创建或者打开普通硬盘文件失败时的返回值也是 INVALID_HANDLE_VALUE，因此诸如下面这段代码存在的 bug是很难发现的：

...

HANDLE hFile = CreateFile(...);

HANDLE hMap = CreateFileMapping(hFile, ...);

if (hMap == NULL)

return(GetLastError());

...

这段代码的本意是首先创建或者打开一个普通的硬盘文件，然后创建一个基于此文件的内存映射文件内核对象，而并不是想创建一个基于系统调页文件的该对象。但是可以看到，当第 1句CreateFile 执行失败时，返回 INVALID_HANDLE_VALUE。这个返回值立刻被传入到CreateFileMapping 函数，结果创建了一个基于系统调页文件的内存映射文件内核对象。这并不是这段代码的原意，而且也会造成问题。因为基于普通硬盘文件的内存映射文件内核对象的操作往往希望将最后的结果保存在该文件中，而基于系统调页文件的内存映射文件内核对象的操作往往只是关注该数据在执行期的结果，操作完毕后并不保存该结果。当 CreateFile 失败且程序运行后，程序运行无误。但是当检查结果文件时，会发现该文件要么没有被创建，要么数据没有改动，因为随后的操作都是基于系统调页文件的！

因此当使用基于普通硬盘文件的内存映射文件内核对象时，一定要在 CreateFile 调用完后检查返回值。

3．堆

分配多个小块内存一般都会选择使用堆函数，比如链表节点和树节点等，堆函数的最大优点就是开发人员不用考虑页边界之类的琐碎事情；劣势就是堆函数的操作相对虚拟内存和内存映射文件来说速度要慢些，而且无法像虚拟内存或者内存映射文件那样直接提交或者回收物理存储。

进程都有一个默认的堆，其初始区域大小默认是 1 MB，链接时可以通过/HEAP 参数修改此默认值。很多操作的临时存储都使用进程的默认堆，比如绝大多数的Win32函数，进程默认堆的句柄可以通过 GetProcessHeap函数获得。

因为程序大部分的内存需求都是从进程默认堆中分配的，而且在多线程情况下还需要考虑线程安全问题。因此对特定的应用，这种情况会造成程序的性能下降。针对这种需求，Win32 提供了自定义堆机制。

自定义堆的步骤如下。

（1）创建自定义堆。

与进程默认堆（进程创建时系统自动创建）不同，自定义堆需要开发人员首先通过HeapCreate函数创建：

HANDLE HeapCreate(

DWORD fdwOptions,

SIZE_T dwInitialSize,

SIZE_T dwMaximumSize);

fdwOptions参数可以指明是否需要串行化访问支持（HEAP_NO_SERIALIZE），以及分配和回收内存出错时是否抛出异常（HEAP_GENERATE_EXCEPTIONS）。当该自定义堆会被多个线程同时访问时，需要加上串行化访问支持，但相应的性能会有所下降。

dwInitialSize 参数指明该自定义堆创建时提交的存储大小（页大小的倍数），dwMaximumSize 参数则指明该自定义堆从进程虚拟地址空间中预留出的区域大小。随着对此自定义堆内存的分配，提交的存储大小随之变大，但此参数限制了增大的极限。另一种情况时是dwMaximumSize为 0，此时该自定义堆可以一直增长，直到进程虚拟地址空间用完。

（2）从自定义堆中分配内存。

从自定义堆中分配内存调用函数 HeapAlloc （从进程默认堆中分配内存也调用此函数）：

PVOID HeapAlloc(

HANDLE hHeap,

DWORD fdwFlags,

SIZE_T dwBytes);

hHeap 参数即上一步骤中返回的堆内核对象句柄，fdwFlags 可以取 HEAP_ZERO_MEMORY、 HEAP_GENERATE_EXCEPTIONS和HEAP_NO_SERIALIZE共3个值， HEAP_ZERO_MEMORY 指明返回的内存必须全部清 0。HEAP_GENERATE_EXCEPTIONS 指明此次分配内存如果失败，需要抛出异常。如果该自定义堆创建时指明过此参数，则其上的内存分配不必再指明此参数；如果堆创建时没有指明，则可以在每次申请时指明。

HEAP_NO_SERIALIZE 参数指明此次分配不必串行化访问支持。最后的 dwBytes参数指明此次分配的内存大小，返回值为分配内存的起始位置。

（3）释放内存。

从堆中释放内存调用 HeapFree函数：

BOOL HeapFree(

HANDLE hHeap,

DWORD fdwFlags,

PVOID pvMem);

这个函数的参数意义很明显，无须赘述。需要指出的是，这样释放内存并不能保证所有物理存储被回收，一是因为物理存储以页大小为单位判断是否可以回收；二是 Window设计堆机制时对效率的考虑。

（4）销毁自定义堆。

当程序不再需要使用某个自定义堆时，调用HeapDestroy函数：

BOOL HeapDestroy(HANDLE hHeap);

对堆的销毁有几点需要说明，一是当堆销毁时，所有从该堆分配的内存全部被回收，而不必对那些内存一一进行释放，同时该堆占用物理存储以及虚拟地址空间区域也会被系统回收；二是如果没有显式销毁自定义堆，这些堆会在程序退出时被系统销毁。需要注意的是，线程创建的自定义堆并不会在线程退出时被销毁，而是当整个进程退出时才会被销毁，从资源利用效率角度出发，应该在自定义堆不再被使用时立即销毁；三是进程默认堆不能通过此函数销毁，更严格地说，进程默认堆在进程退出前是不能被销毁的。

自定义堆的其他函数如下。

（1）获得进程所有堆：

DWORD GetProcessHeaps(

DWORD dwNumHeaps,

PHANDLE pHeaps);

此函数返回进程目前所有的堆（包括进程默认堆），传入存放所有堆内核对象句柄的数组，以及数组的大小，返回值为堆数目。

（2）修改分配内存的大小：

PVOID HeapReAlloc(

HANDLE hHeap,

DWORD fdwFlags,

PVOID pvMem,

SIZE_T dwBytes);

这个函数可以修改原来分配的内存块（pvMem）的大小，新的大小由参数dwBytes指明。

（3）查询某块分配内存的大小：

SIZE_T HeapSize(

HANDLE hHeap,

DWORD fdwFlags,

LPCVOID pvMem);

这个函数可以查询到原来分配的一个内存块的大小。当该内存块指针是外部模块传入时，如果需要知道该块确切大小时，这个函数就可以发挥作用。

（4）堆压缩：

UINT HeapCompact(

HANDLE hHeap,

DWORD fdwFlags);

此函数将相邻的回收回来的自由块合并在一起，需要注意的是，这个函数并不能移动已经分配的内存块，即它并不能消除内存碎片。

自定义堆有如下优点。

（1）减少碎片，节省内存：由于大多数自定义堆是为某些特定的数据结构创建的，所以这些数据结构大小相同，从而使得上次释放的空间有更大机会刚好可以满足下一次的内存申请，从而减少了碎片的产生。

（2）由于局部性原理，所以提高了性能：由上所述，自定义堆上的内存块大多是某些特定的数据结构，比如链表节点或者树节点。这些数据结构有着很强的时间局部性，即程序往往会在相邻的时间内访问所有这些数据。如果这些数据都放在某一个自定义堆中，这种空间局部性就会极大地减少对这些数据整体访问引起的缺页错误，从而提高了程序的运行性能。

（3）由避免线程同步问题，所以提高性能：如前所述，因为进程默认堆可能会被多个线程同时访问，因此添加了保证线程安全的串行化访问支持，但串行化访问支持的代价就是性能下降。如果某个自定义堆只允许某单个线程访问，那么此自定义堆不必添加串行化访问支持，从而提高程序的性能。