内存映射读取大于2G的单个文件时MapFileView()报错？读取800M文件时内存被用光？请问大侠，如何才能既不占太多内存、又能快速的读取大文

[Hawk_lp]

内存映射在读取巨型文件时，MapFileView()通不过，且在读取800M文件时，256M内存几乎被用光，若连续处理800M文件，程序将申请不到资源而导致系统奔溃。
请不吝赐教：
有什末方法在读取巨型文件时，既快速，又不太占资源？

[lanzhengpeng2]

我不相信800M的数据都有不可分割的逻辑关系。所以，需要那部分读哪部分的数据进内存，使用，释放，再读。
处理巨型文件还象处理几十K,几M的文件那样处理，只能说明楼主的IQ有问题

[suntt]

可以分割开来

[SecretGarden]

老兄，你可以创建整个文件的map，
但是你绝对没有必要将整个文件MapFileView，
你每次view一小部分，然后处理，然后Unmap
再mapview另一部分....
肯定不能整个一起map的，你的地址空间就那么2G啊
这种处理方法决不会受2G文件的限制的

[ttzzgg_80713]

gz

[fang_jb]

文本的话，先拆分，

二进制的话，我只想说写这文件的人真是BT

[Hawk_lp]

是否可以用多线程结合内存映射

[iterator]

这个方法很蠢。一个人可以吃一百头牛，不过你为什么非要一顿吃下去？这不是技术能否实现的问题，是……呵呵^^

[jishiping]

直接用读文件的函数读文件啊。如：C的函数read fread, Windows API函数
ReadFile，你为了省事，使用文件映射，对于打文件，当然不行啦。

[sh210]

用CreateFile()打开要读的文件，再用ReadFile()和WriteFile(),如：
while(1)
{ReadFile(CreateFile(),……，toread,……，……，……）；
if(toread==0)
break;
WriteFile(……）；
}
这样就行了，但必须打开的文件句柄有效.

[Hawk_lp]

API的ReadFileHuge可以用吗？
JSP说的对
读文件使用双缓存不知JSP赞同吗，索定两块内存，缓存1读入文件的时候，用多线程去处理缓存2中的数据，处理完缓存2后，缓存2刷新数据，同时用一个线程处理缓存1中的数据。
清JSP回复！

[Bird1945]

你要快速到什么样子啊??

划二个内存区,一个用于读一个用于写,用两个线程,完全可以满足DVD的对数据
的要求,


to fang_jb(寂寞如雪) ( ) 信誉：100

大数据库里的数据文件都有上百兆,不是ASIC码的吧

我们这里的数据库,(oracle)一个天下来就有几十万条数据...

[tianye606]

MapViewOfFile()使得文件的一部分映射到调用进程的地址空间。所以如果你要读取大文件，又不想消耗太多的内存，你就完全可以根据实际的应用来处理。比如你可以开辟两个线程，一个用于处理数据，一个用于小块小块的映射文件。根据需求来设定两个线程的优先级。
如果你一次将大文件所有数据都映射到内存，肯定不够用。虽然每个进程可以有18G的虚拟内存，但是物理内存还是要取决与你的电脑的内存条。你如果一次将10G的虚拟内存映射到物理内存，你想一下你的物理内存有10G吗？

[Hawk_lp]

ReadFileHuge()可以用吗？

一般大于2G，小于4G的文件都可以用CreateFile()得到句柄，得到楼上的HELP，我总结出两种方法供参考：

1. 双缓存多线程：
用VirtualAllocMem分配两块内存，当线程1处理缓存1种的数据时，线程2把数据读入缓存2中；直到线称1处理完，线程2处理缓存2中的数据，同时线程1读数据到缓存1刷新，如此反复，最后释放分配的内存。

2. 内存映射多线程:
线程1映射大文件中的小块文件，线程2处理线程1映射出的小块文件。

方法2中，线程2需要线程1返回的指针，不知是否可以在线程1得到数据指针后就可以释放映射所占的资源，还是要等到线程2处理完数据后才可以？
在有就是在连续用内存映射处理文件时，极易产生内存碎片，导致后续文件的处理越来越慢！所以方法2要慎用。

若有什末建议，贴子请上！

[hhoking]

up and 收藏

[In355Hz]

SecretGarden(天堂鸟) 说的正确，MapFileView()基本上是View多少就占用多少内存，物理内存不够就用交换页面代替。一下子View 2G多，就是地址空间都不够用啊。

[xkak2]

唉，我觉得即使用脚趾头思考，也不应该把2G的文件都map啊！
难道不能读一部分处理一部分吗？
现在的程序员们都怎么了？！！！

[rick29]

难不成是你的硬盘都不够大了？

[horris]

SecretGarden(天堂鸟) 说的对。
Win32应用程序的地址空间是4G(2的32次方)。但是这4G中操作系统要占去一部分，进程间共享内存要占去一部分，进程引用的DLL要占去一部分，所以进程可以申请的空间不到 4G，对NT内核（NT4/2K/XP）来讲，自由空间是小于2G的，对于98内核是小于3G的。
CreateFileMapping可以处理大于4G的文件，但是MapViewOfFile可以Map的大小是取决于当前进程的自由地址空间的，一般来讲小于2G，所以要用SecretGarden(天堂鸟)讲的办法。但MapViewOfFile决不会取决于物理内存的大小，那样的话File Mapping就没有意义了，不要忘记Windows是虚拟内存系统！说它和当前硬盘空闲空间有关关系还差不多。

[bljbljbljblj]

倒

[chenm001]

楼主的处理方法真是令我佩服的五体投地
要是我象你一样写程序地话，连一天的数据都处理不了！（我每小时的数据量为372MB左右）