内存映射文件之剖析(一)

经作者同意转载自  http://blog.csdn.net/xrbeck

内存映射文件之剖析

                                                                              作者:xrbeck

 

内存映射文件(Mapping File)是Windows内存管理中的重要一环，也是编程

技术中比较高级的一个话题。目前关于这方面的资料比较少，而其实内存映射

文件其实对我们的对于Windows的内存了解很重要，在这里把笔者的心得写

出来，和大家一起讨论。

 

                          内存空间及映射

    相信大家都已经知道，在WIN32中和16位Windows的最大不同就是WIN32

引入了面向进程的独立虚拟地址，这个地址的寻址空间达到了4GB（2^32），当然

这个地址是虚拟的。每个进程拥有自己的独立空间,进程A的地址0X10000000

和进程B的地址0X10000000没有丝毫的联系(只是在用户进程地址空间,不包括其他

范围)。说到这个地方可能大家会奇怪了,我的机器中只有64M（或者128M等）内存呀，怎么会有这么大的地址空间呢？而进程A和进程B的同样的地址又会如何识别使得不冲突呢？

   这里先让我们来看看Windows的内存空间(注：这里我们都以Win9X来讨论,

当然Win2K或者WinNT和9X在某些方面会不大一样)

                    

                     0x00000000----0x003FFFFF     4M      属于系统保留区域

 

            0x00400000---0x7FFFFFFF    2G-4M   面向进程独立的地址空间

 

            0x80000000--0xBFFFFFFF     1G       Win32共享的空间,用来存放

                                                  内存映射文件等

         

            0xC0000000---0xFFFFFFFF    1G       用来存放Vxd等

 

有上面的列表可知,用户的程序运行在第二个地址范围中,而我们用来讨论的映射文件则放在了第三个地址范围中.而我们调试程序的时候经常有看到某个指针变量的值

为多少,这个值就指的是虚拟地址空间中的地址.

    那么Windows是如何将这个虚拟地址空间转化为实际的PC上的RAM的地址呢?

这就牵涉到映射的问题,也就是以页(page)为基本单位实现两个地址的对应.这个相信

在操作系统这门课里已经学习过,这里就不再重复了.在上面这个问题中,地址情况

可能如下:

           进程A                   RAM                    进程B

 

 

 

 

0x10000000

1页

………

 

1页          

 

 

 

 

0x10000000

 

 

 

 

 

 

 

这样,相信大家都已经清楚了程序访问中的地址空间和具体的OS访问的地址之间的关系了吧(关于页的大小,不同的平台有不同的值,Windows的是4K,我们可以用GetSystemInfo这个API返回的SYSTEM_INFO中的dwPageSize得知道)

(备注2:实际的映射过程中,是以64K为边界对齐的)

   

虚拟内存

然而,我们知道RAM是宝贵而稀少的,早在16位的Windows时代已经推出

了硬盘交换文件以提供虚拟内存,Win32则是提供了硬盘上的页面文件来继续

支持虚拟内存.根据Richter的说法:”系统页面的大小是决定应用程序能使用多少

物理内存的最重要的因素,RAM只是很小的影响”.在实际的内存访问过程中,系统

先会上RAM中寻找需要的资料,如果找不到,就会提供一个页面错误让OS上页面

文件上去找,如果找到则把页面文件的内容加载到RAM继续访问,否则就报错

提示”无效的页面错误”(也是我们最常碰到的程序错误).在这里,我们不妨把页面

文件理解为”后备的RAM”.(Windows提供给用户控制虚拟内存的方法是在

控制面板中的系统选项).所以在这种情况下,RAM的主要作用只是起到了

和硬盘上的页面文件做数据的交换,所以才有了Richter的说法.

      如果用户程序要自己使用虚拟内存,那么首先的第一步是在进程地址

空间中保留(rerserve)一块地址(在4M—2G中),然后再把这块空间提交(commit)

给真正的内存.Windows提供给我们的对虚拟内存的操作界面是VirtualAlloc和

VirtualFree这一组API,这样我们就可以利用虚拟内存的庞大的特性来处理

一般程序难以解决的问题.比如假设有个二维结构Item[300][256];里面每个单位

为200个字节, 现在要修改里面的某个单元,要实际的分配这么大的内存几乎是

不可能的,而分匹处理又难以体现二维结构直接用下标访问的简洁性,这样我们

就可以先保留下这个庞大的结构,然后只提交要修改的部分给实际的内存,使得

最后的操作简洁而有效.

Windows提供的保留和提交虚拟内存的函数只是一个:VirtualAlloc,不过是里面

的参数不一样,拿上面的例子而言,我们可以这样处理:

 

LPVOID  pStart = NULL;      

LPVOID  pItem = NULL;

DWORD  Offset=0;

  // 在系统默认位置保留整个数据结构,返回保留的首地址 

pStart =VirtualAlloc(NULL,300*256*200, MEM_RESERVE,PAGE_READWRITE);

  …

  // 计算出要存取的偏移位置

  ….

// 只提交其中的一部分给内存

pItem =VirtualAlloc(pStart+Offset,200,MEM_RESERVE,PAGE_READWRITE);

  // 直接修改

pItem=….  

VirtualFree(pStart, 300*256*200, PAGE_READWRITE); 

 

     可是虚拟内存也会带来不方便的地方,假设我们要运行一个程序,按照前面

的做法是要使用到页面文件来作为虚拟内存而访问,这样系统必然是先保留

程序的地址空间,然后提交物理内存,接下来把数据和代码从硬盘上的程序文件

拷贝到系统的页面文件,最后加载运行.这样的结果必然是使得加载一个应用

程序的时间变的很长,所以系统真正的做法是把程序文件(.exe)直接当作是内存

文件而使用,这样就不再从页面文件中分配空间使得加载的时间大大增加.

     这个特性无疑是非常诱人的,居然可以直接拿文件当内存,那不是很方便吗?

是的.在系统加载exe文件和dll文件的时候,系统是自动这么处理的.那么如果

是一般的数据文件要使用这种特性可以吗?答案是肯定的,也就是我们绕了一个

大圈子最终要说的今天的话题:内存映射文件