内存空间及映射

内存空间及映射

[ 2005-09-14 09:10:21 | Author: snox ]

Font Size: Large | Medium | Small

内存映射文件(Mapping File)是Windows内存管理中的重要一环，也是编程技术中比较高级的一个话题。目前关于这方面的资料比较少，而其实内存映射文件其实对我们的对于Windows的内存了解很重要，在这里把笔者的心得写出来，和大家一起讨论。
原文: http://dev.csdn.net/article/14/14320.shtm

相信大家都已经知道，在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



这样,相信大家都已经清楚了程序访问中的地址空间和具体的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文件的时候,系统是自动这么处理的.那么如果是一般的数据文件要使用这种特性可以吗?答案是肯定的,也就是我们绕了一个大圈子最终要说的今天的话题:内存映射文件.

内存映射文件

前面已经提到:内存映射文件是拿文件直接当作系统的内存使用,那么它主要的用途是什么呢?主要有以下两点:

1. 直接用内存映射文件来访问磁盘上的数据文件,无需再进行文件的I/0操作.
2. 用来在多个进程之间共享数据.进程间共享数据有很多种方法,比如发送消息WM_COPYDATA,匿名管道等等,但他们的低层都毫无例外的使用到了Mapping File.然而因为WM_COPYDATA一定需要使用同步函数SendMessage,所以在实时性方面表现的不是很好.

(至于同步和异步的区别可以参考笔者的另一篇文章: http://www.csdn.net/Develop/read_article.asp?id=14204 )

前面已经提到过,内存映射文件的位置在3G—4G的空间中,这部分是Win32所有进程都看的到并且共享的,自然可以用来传输数据,另外各个进程所共享的DLL等也是映射在这个空间范围.

内存映射文件的使用可以分为以下三步:

1.CreateFileMapping 创建一个文件映射内核对象
2.MapViewOfFile 将文件数据映射进进程地址空间
3.UnmapViewOfFile 从进程地址空间解除这个映射

下面以Mapping File的两个主要作用分别给出两个简单的例子:

A 直接用内存映射文件访问文件.
首先在C盘下创建一个Mapping.txt里面输入1234567

 HANDLE hFile=CreateFile("c://mapping.txt",
 GENERIC_READ|GENERIC_WRITE,
 FILE_SHARE_READ|FILE_SHARE_WRITE,
 NULL,
 OPEN_EXISTING,
 FILE_ATTRIBUTE_NORMAL,
 NULL);

 HANDLE hFilemap = CreateFileMapping(hFile..);
 NULL,
 PAGE_READWRITE,
 0,
 100, // 只是开辟100个
 NULL);

LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
Char *Buf=(char *)pVoid;
Buf[0]=”T”
CloseHandle(hFile);
CloseHandle(hFilemap);
UnmapViewOfFile(pVoid);

(注意:没有考虑异常情况)
这样,当我们再打开Mapping.txt的文件的时候,就发现第一个字节”1”已经被改为了’T’.也许有些读者会提问:干吗这么麻烦呢?直接用fopen或者CreateFile不就OK了?是的,小文件是,可是如果这个文件有上百兆呢?MappingFile为我们提供了一种直接映射存取的方便之道.
这里有个小小的地方要注意,创建映射对象的时候有个保护属性fdwProtect可以选择PAGE_WRITECOPY,顾名思义是用来写拷贝的,系统在收到这个参数后,将会从页面文件中额外的提交物理内存(前面已经提到过,映射对象不使用页面文件).当发生读操作的时候,系统仍旧使用映射文件,当发生写操作的时候,系统从页面文件中分配页面,从映射文件中拷贝到该页进行访问,这样使得原先的写操作被丢弃.读者可以试着照上面的例子把CreateFileMapping和MapViewOfFile里面的两个对应字节改为PAGE_WRITECOPY和FILE_MAP_COPY,这样原文件即使有写操作也不会被改动.

B 在不同的进程间共享数据
要进行共享如果每次都要在硬盘上创建一个文件该是多么的麻烦啊, Windows提供了这样一种机制:当在创建映射对象的时候如果hFile填上(HANDLE)0xFFFFFFFF,系统会自动从页面文件中创建文件对象.
另外有书上提到共享方式是以p2p的方式还是c/s的架构来进行,我想不过是打开的方式不同吧,没有别的差别,(一个用CreateFileMapping打开看是否为已经存在,另一个用OpenFileMapping打开)

来看个例子;

# define WM_DATACOMING WM_USER+100

进程A:

HANDLE hFilemap=CreateFileMapping((HANDLE)0xFFFFFFFF,
 NULL,
 PAGE_READWRITE,
 0,
 100,
 "SHARED");
LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
memset(pVoid,0,100);
strcpy((char *)pVoid,"this is a mapping file test");
HANDLE hDes=FindWindow(NULL,"MAPPING"); // 对象窗口的名称
SendMessage(hDes, WM_DATACOMING,0,0);
CloseHandle(hFilemap);
UnmapViewOfFile(pVoid);

进程B(拥有窗口名称为MAPPING)

// WM_DATACOMING消息捕捉函数
HANDLE hFilemap=OpenFileMapping(NULL,NULL,"SHARED");
LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
Label1->Caption=(char *)pVoid;

可以看到数据已经被正确的传送过来.可能有些读者已经注意到,在这种情况下需要给映射对象取个名字(例子中为SHARED),是的,在这种用途下需要给它取个名字,而在第一种应用中这个地方可以被忽略.这里可能会引起打架的地方就是这个名字了,如果多个进程创建了多个映射对象,根据名字来不是比较容易冲突了吗?是的,这是个问题,笔者建议可以采用窗体的名称(MAPPING)或者别的唯一的ID来使得不引起混淆.
请注意这个函数:MapViewOfFile,注意到里面有个单词:Viewà视这个函数是把创建好的映射对象真正提交到地址空间去,这就产生了一个视.Windows中允许映射统一数据文件的多个视,比如说可以将一个文件的全部映射到一个视,然后将他的前10K单独映射为一个视.那么系统是不是真正区别这多个视呢?答案是要看是什么系统,如果是Win9x,系统并没有额外再映射一个新的地址给它,而只是把原先的基地址加上一个偏移量做为新的视的地址而返回,换句话说地址空间只有一份,而WinNT则是真正的新产生了一个地址空间返回来.
看看下面这个小例子:

HANDLE hFilemap=CreateFileMapping((HANDLE)0xFFFFFFFF,
 NULL,
 PAGE_READWRITE,
 0,
 100,
 "SHARED");
// 提交整个地址给空间
LPVOID pVoid1=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);

// 从偏移40产生一个新视
LPVOID pVoid2= MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,40,0);
If(pVoid1+40==pVoid2)
 MessageBox(“Run On Win95”);
else
 MessageBox(“Run On NT”);

可以注意到返回的值为0x8…这符合地址列表中MappingFile的位置.必然在“Server”中开启的映射对象的地址和”Client”中利用MapViewOfFile返回的地址是一致的(9x环境).这也是因为这个部分的地址空间是大家共享的.
那么既然是一样的,能不能直接使用这个值呢?比如上面的进程间共享数据的例子:如果进程A的发送语句改为:

 // 把指针值作为参数传递
 SendMessage(hDes, WM_DATACOMING,(WPARAM) pVoid,0);

进程B的接受消息部分改为:

 LPVOID pVoid=(LPVOID)MSG.WPARAM;
 Label1->Caption=(char *)pVoid;

可以看到可以正确的显示出来,因为指针所指的地方的确是有这么一笔数据,那么是不是意味着我们就能这么使用呢?答案是否定的,首先这个值相等只是在Win9x的环境下,在NT环境下是不相等的,另外NT下访问这个地址空间的时候要求一定要先使用MapViewOfFile函数.这是第一个原因,更加重要的是内存映射对象属于内核对象(Kernal Object),这种对象的最大不同就在于它是系统维护的一块数据结构,用户只能通过相应的接口函数进行间接的访问.每访问一次就增加一个引用记数(reference count),当计数器变为0的时候,系统自动释放这个内核对象.在上面的例子中,尽管Server端和Client的值是一样的,但是如果Server端执行UnmapViewOfFile释放内核对象的时候,这部分数据将会被系统释放掉,因为它的引用计数只是1,只有我们在Client端使用MapViewOfFile增加这个对象的计数的时候,才不会被系统释放掉.

堆

Win32的堆位于进程私有空间内,属于自由分配区,比如大家在C++中常使用的new操作符就是在这个地方分配的,关于堆的操作有HeapCreate和HeapAlloc等,这里就不再继续讨论了.

后记
Mapping File一直是个比较难以讨论的问题,在CSDN上也看到不少网友讨论的比较模糊,最后不了了之.笔者对这个问题也一直想搞个明白,在看Richter的大作<Advanced Windows>的时候,因为内存这个部分是连在一起的好几章,理论也比较抽象和繁杂,看的很是头痛.写出这篇文章也是希望帮助大家更好的理解这个部分,对内存有着进一步的了解以便更好的开发程序.有兴趣进一步研究者可联系 QQ:33854303

xrbeck写于2002/7/3

参考资料:

1. Windows 高级编程指南 Jeffery Richter
2. Windows程序设计 Charles Petzold
3. Win32多线程程序设计 侯捷译