reserve内部是怎么实现的呢？当然是new了。那么在reserve操作，也就是new之后，我们程序是否立即就占用了这些内存呢？这就要看我们这里说的“内存”是什么样的内存了。什么意思呢？我们知道，现代操作系统都采用了虚拟内存的机制，内存占用也就有了虚拟内存（virtual memory）和物理内存（physical memory）之分了。
　　我们又知道，Unix/Linux进程的虚拟地址空间被按用途被划分成了内核空间和用户空间。内核空间供操作系统的内核使用，用户空间供用户程序支配。其中用户空间又被划分为若干段，主要包括：代码段（.text），用来存放/映射用户程序的代码；数据段（.data），存放初始化的全局数据或静态数据，这部分在文件系统中也占据磁盘空间；.bss段（一直没找到一个亲切的翻译），存放为初始化的全局或静态数据，在程序加载时分配空间和初始化，这部分空间不占用磁盘空间（当然在可执行文件中要保留其大小）；堆栈段，用来保存程序执行时的上下文（局部变量、函数参数和返回地址等），在进程建立时由操作系统分配，空间较小且在运行时不可动态调整，增长方向因机器架构而异，IA上自高地址向下增长，堆栈不占用磁盘空间；堆，供用户在运行时动态地申请和使用，空间较大，未被申请的堆空间不可使用，也不会被映射到物理空间，堆随着用户程序申请向上增长，堆不占用磁盘空间。

　　这么长的开场白之后，我们还知道，new负责在运行时（通过运行时库）为用户程序在堆上申请空间。但，而且，当然，new出的只是虚拟空间。在未对该空间进行读写时，这些空间并未被映射到物理空间，即操作系统还没有为这段空间分配物理内存。只有当程序开始对刚刚申请的虚拟空间进行访问时，被操作系统的虚拟内存机制觉察到（页中断）这一请求，才会为访问地址所在的虚存页面分配和映射物理页面，访问才得以进行。可以使用下面程序对此作出验证，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

int
main()
{
    sleep(3);
    std::cout<<"stage 1..."<<std::endl;
    char *p = new char[1U<<30 * 2]; //~ 2GB
 
    sleep(3);
    std::cout<<"stage 2..."<<std::endl;
 
    for(unsigned i = 0; i < (1U<<30*2); ++i) //~ access
    {
        p[i] = 0;
        usleep(1000); //~ per millisecond
    }
    return 0;
}

　　运行此程序，同时使用top命令观察。主要观察两项，new前后程序的虚存占用，以及stage 2中程序驻留内存（REsident Size，即物理内存）的变化。另外，为了观察方便，最好调整top命令，使其按内存占用对进程排序。

　　上面虽然没有介绍太多东西，但由于本人水平有限，难免会有错误及不清楚之处，如果“不幸”被你发现了，还请指出和补充之。
　　关于内存管理，学习过程中总会发现“惊喜”，若要做到对内存知根知底，对内核和语言运行时库的研究是必要的。对于这些个“小惊喜”，一方面说明俺是个小菜，另一方面也预示着俺是个成长中的小菜。各位看官您见笑了;-)

　　操作系统采用虚拟内存的方式管理存储器有很多好处：
　　第一，虚拟内存管理可以控制物理内存的访问权限。物理内存本身是不限制访问的，任何地址都可以读写，而操作系统要求不同的页面具有不同的访问权限，这是利用CPU模式和MMU的内存保护机制实现的。例如，代码段被只读保护起来，防止被错误的指令意外改写，内核地址空间也被保护起来，防止在用户模式下执行错误的指令意外改写内核数据。这样，执行错误指令或恶意代码的破坏能力受到了限制，顶多使当前进程因段错误终止，而不会影响整个系统的稳定性。

　　第二，虚拟内存管理最主要的作用是让每个进程有独立的地址空间。所谓独立的地址空间是指，不同进程中的同一个VA被MMU映射到不同的PA，并且在某一个进程中访问任何地址都不可能访问到另外一个进程的数据，这样使得任何一个进程由于执行错误指令或恶意代码导致的非法内存访问都不会意外改写其它进程的数据，不会影响其它进程的运行，从而保证整个系统的稳定性。另一方面，每个进程都认为自己独占整个虚拟地址空间，这样链接器和加载器的实现会比较容易，不必考虑各进程的地址范围是否冲突。

　　第三，方便了共享库的实现。采用共享库的目的在于节省内存(物理内存)，一些公用模块在内存中可以只保存一份，让各进程共享，而不是各自加载一份，当然，只读的代码段可以共享，可写的数据段就必须各自保留一份了。采用虚拟内存机制后，可以将物理内存中所加载的共享库分别映射到进程各自的地址空间，由于加载地址可能不同，所以共享库必须实现为地址无关码(PIC)。

　　第三，VA到PA的映射会给分配和释放内存带来方便，物理地址不连续的几块内存可以映射成虚拟地址连续的一块内存。比如要用malloc分配一块很大的内存空间，虽然有足够多的空闲物理内存，却没有足够大的连续空闲内存，这时就可以分配多个不连续的物理页面而映射到连续的虚拟地址范围。

　　第四，“增加”了程序可以使用的内存空间。一个系统如果同时运行着很多进程，为各进程分配的内存之和可能会大于实际可用的物理内存，虚拟内存管理使得这种情况下各进程仍然能够正常运行。因为各进程分配的只不过是虚拟内存的页面，这些页面的数据可以映射到物理页面，也可以临时保存到磁盘上而不占用物理页面。当所访问的页面不在内存中时再将其加载进来，无空闲页面的时候还可能需要采取一定的置换算法将某个页面换出。这种机制的可行性得益于伟大的“局部性原理”。

1
2
3
4
5
6
7

int
main()
{
	char * str = new char[32];
	str = "Hello, Piggy!";
	return 0;
}

这样是会内存泄漏的……而我一直都不知道……

1
2
3
4
5
6
7
8
9
10
11
12

.LC0:
	.string	"Hello, Piggy!"
	.text
.globl main
	.type	main, @function
main:
	andl	$-16, %esp
	subl	$32, %esp
	movl	$32, (%esp)
	call	_Znaj
	movl	%eax, 28(%esp)
	movl	$.LC0, 28(%esp) ;把str给覆盖了

不过想来也自然，因为这样是允许的，char *str = “Hello, Piggy!”;，“程序中的字符串被存放在常量存储区”不要把这句话当成耳旁风，谨记。

　　当缺页中断服务程序发现，内存中已经没有空闲的物理页面(通常称之为帧)时，就会执行一种页面换出程序，它采取一定的置换算法将某个页面换出到外存的交换(文件)分区。通常，衡量一种页面置换算法性能好坏的指标就是对于大量的页面请求序列，在一定数量的物理帧上，产生缺页中断的平均次数。页面置换算法较多，其变种更多，常常见诸于各大OS教材的主要由下面的几种。

• 先入先出法(FIFO)
  　　Fist In Fist Out, 这是一种实现起来最为简单的算法，其实质是，最简单的页面置换算法是先入先出(FIFO)法。这种算法的实质是，总是选择在主存中停留时间最长(即最老)的一页置换，即先进入内存的页，先退出内存。理由是：最早调入内存的页，其不再被使用的可能性比刚调入内存的可能性大。建立一个FIFO队列，收容所有在内存中的页。被置换页面总是在队列头上进行。当一个页面被放入内存时，就把它插在队尾上。
  　　这种算法只是在按线性顺序访问地址空间时才是理想的，否则效率不高。因为那些常被访问的页，往往在主存中也停留得最久，结果它们因变“老”而不得不被置换出去。另外，FIFO算法还有一个比较有意思的缺陷，称之为Berlady异常(或者?)，说当物理内存也即帧数增加时，其缺页中断的次数反而有可能增加！
• 最优置换算法(OPT)
  　　最优置换(OPTimal replacement)，顾其名，知其义，这是一种最优的算法，因为对于任一页面请求序列，其产生的缺页中断次数时最少的，但，这只是理论上的最优。其实质是：当调入新的一页而必须预先置换某个老页时，所选择的老页应是将来不再被使用，或者是在最远的将来才被访问。其最优性是容易证明的。
  　　但是最优页面置换算法的实现是困难的，因为它需要我们预先就知道一个进程整个运行过程中页面走向的全部情况，而这几乎时不可能的。所以，这个算法主要还是用来衡量其他算法的优劣的。
• 最近最久未使用算法(LRU)
  　　最近最久未使用算法(Least-Recently Used)，它的核心思想是，当需要置换一页时，选择在最近一段时间里最久没有使用过的页面予以置换。既然要以时间为替换依据，那么肯定就要用到定时/计数器，因此这个算法通常需要一定的硬件支持，这样的话其通用性也会降低。

  　　还有一种LRU的近似算法，最近未使用算法(Not Recently Used，NUR)，相比LRU实现起来更简单一些。它在页表的每一表项中增加一个引用位，操作系统定期地将它们置为0。当某一页被访问时，由硬件将该位置1。需要页面替换时，就可把该位是0的页淘汰出去。

　　

• 二次机会算法(SC)
  　　这是一种FIFO和LRU的折中，或者说结合，它避免了FIFO的缺陷，即可能把经常使用的页面替换出去(比如说装入程序?)。它的思想是：需要页面替换时，检查它的访问位。如果是0，就淘汰这页；如果访问位是1，就将其清0，同时给它第二次机会，然后检验下一个FIFO页面。因此，如果一个页面经常使用，它的访问位总保持为1，它被淘汰出去的几率是很小的。

　　
　　还有其他很多页面置换算法，实际使用的算法通常就是这些算法的一些折中或者说变种，可见，要想把一个理论上的好算法应用到具体的问题上，会受到很多限制，还需要做不少其他的工作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <iostream>
using namespace std;
int
main()
{
    const int size = 2^30;
    char * p = new char[size];
    for(int i = 0; i < size; ++i)
    {
        p[i] = 0;
    }
    sleep(121);
    return 0;
}

　　在后台运行该程序的多个实例，并查看内存占用：

1
2
3
4
5
6
7
8
9

[04:07 PM] ivan@ivan-desktop ~/cpp> ./test&
[1] 8345
[04:07 PM] ivan@ivan-desktop ~/cpp> ./test&
[2] 8346
[04:07 PM] ivan@ivan-desktop ~/cpp> ./test&
[3] 8347
[04:07 PM] ivan@ivan-desktop ~/cpp> ./test&
[4] 8348
[04:07 PM] ivan@ivan-desktop ~/cpp> free

             total       used       free     shared    buffers     cached
Mem:       1997172    1942672      54500          0     486080    1067476

　　只占了十分之一左右！这又是为什么呢？永远也学不完的虚拟内存啊！

　　呃……又SB了！const int size = 2^30;这哪里是1G啊！分明是28嘛！Orz…汇编码里面尽是28！这下好了，改成1<<30，运行了四个实例，机器就笨的像猪了：

System Monitor

　　等程序结束了，刚开始运行着到浏览器也慢了一会儿，估计是被换到交换文件里面去了。

　　操作系统采用虚拟内存的方式管理存储器有很多好处：

　　第一，虚拟内存管理可以控制物理内存的访问权限。物理内存本身是不限制访问的，任何地址都可以读写，而操作系统要求不同的页面具有不同的访问权限，这是利用CPU模式和MMU的内存保护机制实现的。例如，代码段被只读保护起来，防止被错误的指令意外改写，内核地址空间也被保护起来，防止在用户模式下执行错误的指令意外改写内核数据。这样，执行错误指令或恶意代码的破坏能力受到了限制，顶多使当前进程因段错误终止，而不会影响整个系统的稳定性。

　　第二，虚拟内存管理最主要的作用是让每个进程有独立的地址空间。所谓独立的地址空间是指，不同进程中的同一个VA被MMU映射到不同的PA，并且在某一个进程中访问任何地址都不可能访问到另外一个进程的数据，这样使得任何一个进程由于执行错误指令或恶意代码导致的非法内存访问都不会意外改写其它进程的数据，不会影响其它进程的运行，从而保证整个系统的稳定性。另一方面，每个进程都认为自己独占整个虚拟地址空间，这样链接器和加载器的实现会比较容易，不必考虑各进程的地址范围是否冲突。

　　第三，方便了共享库的实现。采用共享库的目的在于节省内存(物理内存)，一些公用模块在内存中可以只保存一份，让各进程共享，而不是各自加载一份，当然，只读的代码段可以共享，可写的数据段就必须各自保留一份了。采用虚拟内存机制后，可以将物理内存中所加载的共享库分别映射到进程各自的地址空间，由于加载地址可能不同，所以共享库必须实现为地址无关码(PIC)。

　　第三，VA到PA的映射会给分配和释放内存带来方便，物理地址不连续的几块内存可以映射成虚拟地址连续的一块内存。比如要用malloc分配一块很大的内存空间，虽然有足够多的空闲物理内存，却没有足够大的连续空闲内存，这时就可以分配多个不连续的物理页面而映射到连续的虚拟地址范围。

　　第四，“增加”了程序可以使用的内存空间。一个系统如果同时运行着很多进程，为各进程分配的内存之和可能会大于实际可用的物理内存，虚拟内存管理使得这种情况下各进程仍然能够正常运行。因为各进程分配的只不过是虚拟内存的页面，这些页面的数据可以映射到物理页面，也可以临时保存到磁盘上而不占用物理页面。当所访问的页面不在内存中时再将其加载进来，无空闲页面的时候还可能需要采取一定的置换算法将某个页面换出。这种机制的可行性得益于伟大的“局部性原理”。

　　管道是Linux支持的 IPC形式之一，具有以下特点：

• 管道是半双工的，数据只能向一个方向流动；需要双方通信时，需要建立起两个管道；
• 只能用于父子进程或者兄弟进程之间（具有亲缘关系的进程）；
• 单独构成一种独立的文件系统：管道对于管道两端的进程而言，就是一个文件，但它不是普通的文件，它不属于某种文件系统，而是自立门户，单独构成一种文件系统，并且只存在与内存中。
• 数据的读出和写入：一个进程向管道中写的内容被管道另一端的进程读出。写入的内容每次都添加在管道缓冲区的末尾，并且每次都是从缓冲区的头部读出数据。

　　匿名管道是通过pipe()函数创建的：

1
2
3

#include <unistd.h>
int fd[2];
int pipe( fd);

　　该函数创建的管道的两端处于一个进程中间，在实际应用中没有太大意义，因此，一个进程在由pipe()创建管道后，一般再fork一个子进程，然后通过管道实现父子进程间的通信（因此也不难推出，只要两个进程中存在亲缘关系，这里的亲缘关系指的是具有共同的祖先，都可以采用管道方式来进行通信）。

管道的读写规则

　　管道两端可分别用描述字fd[0]以及fd[1]来描述，需要注意的是，管道的两端是固定了任务的。即一端只能用于读，由描述字fd[0]表示，称其为管道读端；另一端则只能用于写，由描述字fd[1]来表示，称其为管道写端。如果试图从管道写端读取数据，或者向管道读端写入数据都将导致错误发生。一般文件的I/O函数都可以用于管道，如close、read、write等等。

从管道中读取数据：

• 如果管道的写端不存在，则认为已经读到了数据的末尾，读函数返回的读出字节数为0；
• 当管道的写端存在时，如果请求的字节数目大于PIPE_BUF，则返回管道中现有的数据字节数，如果请求的字节数目不大于PIPE_BUF，则返回管道中现有数据字节数（此时，管道中数据量小于请求的数据量）；或者返回请求的字节数（此时，管道中数据量不小于请求的数据量）。

向管道中写入数据：

• 向管道中写入数据时，linux将不保证写入的原子性，管道缓冲区一有空闲区域，写进程就会试图向管道写入数据。如果读进程不读走管道缓冲区中的数据，那么写操作将一直阻塞。
• 只有在管道的读端存在时，向管道中写入数据才有意义。否则，向管道中写入数据的进程将收到内核传来的SIFPIPE信号，应用程序可以处理该信号，也可以忽略（默认动作则是应用程序终止）。

示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
 
int
main()
{
    int fd[2];
    char rbuf[10]; //~ 读缓冲
    char wbuf[5120];//~ 写缓冲
    size_t rsize;
    pid_t pid;
    if(pipe(fd) == -1)
        printf("pipe create failure\n");
    if((pid = fork()) < 0)
        printf("process create failure\n");
    if(pid == 0) //~ 子进程写
    {
        //close(fd[0]); //!~ 若此处将读端关闭，则管道就没有打开的读端，也无法写入。
        while(rsize = fread(wbuf, 1, sizeof(wbuf), stdin))
        {
            rsize = write(fd[1], wbuf, rsize);
            printf("write: %d\n", rsize);
        }
        close(fd[1]);
    }
    else if(pid > 0) //~ 父进程读
    {
        //~ sleep(1);
        close(fd[1]);
        close(fd[0]);//~读端写端均关闭，此时父进程不做任何事。
        sleep(9);
        while(1)
        {
            sleep(1);
            //~ rsize = read(fd[0], rbuf, sizeof(rbuf));
            //~ fprintf(stderr, "%d ", rsize);
            //~ fwrite(rbuf,1 , rsize, stderr);
            //~ fprintf(stderr, "\n");
        }
    }
    return 0;
}

疑问

　　上述程序运行时，当输入字符串大于写缓冲时，为何没有阻塞？对于一下输入：

There’s a whole lot of laughing gas in the atmosphere these days. But it’s no laughing matter. Nitrous oxide, or N2O, wafts up from manure and the chemical fertilizer sprayed on fields. Industry contributes as well
…….
There’s a whole lot of laughing gas in the atmosphere these days. But it’s no laughing matter. Nitrous oxide, or N2O, wafts up from manure and the chemical fertilizer sprayed on fields. Industry contributes as well

产生的输出：

write: 4096
write: 4096
write: 4096
write: 4096
write: 4096
write: 4096

　　这是为什么呢？:-(

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <iostream>
#include <pthread.h>
using namespace std;
 
class M
{
    public:
        M(){}
        ~M()
        {
            cout<<"M destructed..."<<endl;
        }
    private:
        int i;
};
class B
{
    public:
        B(){}
        //! virtual ~B(){}
        ~B(){}
};
class D: public B
{
    public:
        D(){}
        ~D(){}
    private:
        M m;
};
 
int
main()
{
    B * pb = new D;
    delete pb;
    return 0;
}

表明看来似乎合情合理，由于C++的多态特性，允许我们将一个子类地址赋给父类型的指针pb，释放对象时理所当然的对pb进行delete。但，在程序运行时，并没有输出M destructed…，即D::m的析构函数没有被调用，而m的析构函数是需要D::~D()来调用的，所以子类D的析构函数也没有被调用。这是很容易理解的，因为父类的析构函数不是virtual的。由此，我们得出结论，用来继承的父类的析构函数总应该是virtual的，除非你确定它绝对不会被用于多态。关于这一点，《Effective C++》里面已经讲到了。

除了上面的问题，我们还应该关心的是，尽管析构函数没有被调用，那M::i的空间被释放了吗？It’s a question！由于析构函数没有被调用，那么释放M::i的任务就完全落在了delete身上的了，那么delete做到了吗？It’s a very question！这又回到了上一篇日志中所描述的问题上了。我的观点是delete做到了它应该做的事情，它只负责释放当初new申请的空间，即对象本身，至于对象里面是否有动态申请的内存，那就不是delete而是对象析构函数自己的工作了。

1
2
3
4
5
6
7
8

#include <stdio.h>
int
main()
{
    int* pi = (int*)malloc(sizeof(int));
    free((char*)pi);
    return 0;
}

这段程序的内存能完全释放吗？答案是能。
看free函数的原型：void free(void*); 可知，无论你传给它什么类型的指针，它内部都是按照没有类型的void*来处理的。堆管理器会帮程序处理这一切，它记录了你先前申请的这块内存的大小，它看到的只是一块内存，没有任何类型之类的东西。

再看下面这段代码：

1
2
3
4
5
6
7
8
9

#include <iostream>
using namespace std;
int
main()
{
    int* pi = new int;
    delete (char*) pi;
    return 0;
}

这里的内存被正确释放了吗？答案我也不知道……还请看到的高手解答^_^:-)
接着看，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
using namespace std;
class demo
{
    public:
        //~ 此处省略代码数行……
        ~demo()
        {
             delete [] pi;
        }
    private:
        int * pi;
};
int
main()
{
    demo * pd = new demo;
    delete (char*)pd;
    return 0;
}

这里的内存会被正确释放吗？答案要分两方面来讨论。*pd对象本身的内存(4Byte)会不会被释放，就像上例中所说，我还是不知道。但(*pd)::pi所指向的内存肯定是打了水漂啦！因为delete看到的只是一个char*类型的pd，只会简单做一些处理(待高人讲解)，而不会调用析构函数demo::~demo()。甚至有时候它还可能调用其他类的析构函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#include <iostream>
using namespace std;
class demo
{
    public:
        //~ 此处省略代码数行……
        ~demo()
        {
             delete [] pi;
        }
    private:
        int * pi;
};
 
class foo
{
public:
    ~foo(){cout<<"foo's collapsing..."<<endl;
};
int
main()
{
    demo * pd = new demo;
    delete (foo*)pd;
    return 0;
}

foo童鞋真是可怜，让我们来了个借尸还魂，Orz，是借刀杀人才对！

• 在栈上创建。在执行函数时，函数内局部变量的存储单元都在栈上创建，函数执行结束时这些存储单元自动被释放。栈内存分配运算内置于处理器的指令集中，一般使用寄存器来存取，效率很高，但是分配的内存容量有限。
• 从堆上分配，亦称动态内存分配。程序在运行的时候用malloc或new申请任意多少的内存，程序员自己负责在何时用free或delete来释放内存。动态内存的生存期由程序员自己决定，使用非常灵活。
• 从静态存储区域分配。内存在程序编译的时候就已经分配好，这块内存在程序的整个运行期间都存在。例如全局变量，static变量。
• 文字常量分配在文字常量区，程序结束后由系统释放。
• 程序代码区。