windows的缓存管理

最近在写代码的时候发现了一个很有意思的问题：读取200个不同的文件比读取同一个文件200次要用多出好多倍的时间。不由的想了解一下windows是怎么做缓存管理的。

1：什么时候windows 会缓存文件数据

     当文件没有使用FILE_FLAG_NO_BUFFERING标志并且不是做为映射文件打开的时候，windows会对文件数据进行缓存。自然那些直接访问磁盘的方法是无法缓存数据

2：缓存的大小和位置

 

   

     可以看出缓存位于系统地址空间的两个位置,c1000000－e0ffffff,a4000000-bfffffff 一共960M的空间，这是缓存的最大值，而缓存的实际大小是和系统的物理内存相关的，具体的计算方法是：

128 MB + (X MB - 16 MB) / 4 MB * 64 MB，其中的X是系统安装的物理内存的大小。也就是说如果系统有

1g的物理内存，那么缓存的实际大小是16256M，这已经远远大于系统所能提供的最大值，那么系统的缓存值如何确定呢？如果LargeSystemCache注册表项为1，那么缓存的大小是960M，如果其为0，则缓存的实际大小为512M，使用windbg可以查看当前系统的缓存的大小：

从图中可以看出当前系统的缓存大小是1332M，很显然这不符合上面的公式了，这很可能

是SP3做的一个修正。

 

3：缓存的数据格式

缓存被划分为最小寻址单位为256K的一个个视图，每个视图使用一个虚拟地址描述块来描述，

缓存管理器初始化的时候从非分页内存中分配一块内存用于存放描述整个缓存的VACB块。

 

4：缓存的使用

我们通过WINDWOS API来操作文件的时候需要指定一个文件句柄，一个文件句柄对应于一个

文件对象，我们可以对同一个文件打开多个句柄，也就是说一个文件拥有多个文件对象，但一个

文件只有一个内存区对象，对系统来说一个文件就是意味着一个内存区对象。缓存的使用正是

从这里展开的。

通过句柄－－>文件对象－－>文件内存区对象－－>共享的文件缓存表。在共享的文件缓存表

中存在VACB的索引数组，数组第一个元素标识文件第一个256K在vacb数组中的索引，依次

类推。如此就可以知道需要的文件内容是否被缓存，已经被缓存在缓存的什么地方了。可以通过

windbg来验证一下：

1：首先先获取一个文件句柄，这里我们通过打开一个文件的方式来获取：

    

     测试的时候得到的文件句柄是0x00000fdc， 所在的进程id是 d70, 句柄都是位于进程的句柄表中的。

2：通过windbg的!handle命令获取对象的文件对象信息

    

    从上可以看出文件对象位于 0x86c93b30.

3：通过windbg的dt命令获取文件内存区对象的信息

   

    从上图可以看出内存区对象(SectionObjectPointer)位于0x873f0a9c

4：通过内存区对象获取文件共享缓存表

   

   从图中看共享缓存表为空，这是因为上面只是打开了文件而还没有进行读写，而文件缓存是发生在读写的时候，

  下面我们修改程序，读取文件实验一下：

  

   可以看出共享缓存表已经不为空了。通过讲sharedCacheMap结构dump出来即可知道文件在缓存中的

   分配情况了。

  

    

    其中的InitialVacbs是一个四个VACB元素的数组，存放文件前1M的VACB块,Vacbs用来存放文件后面的Vacb块。