我记得Dictionary是有大小限制的，忘了上限是多少了
像你这种情况，可以试试这样

Dictionary <string, Dictionary <string,int>>
将你要处理的内容，合理的处理一下，放到这里面  就不存在溢出问题了

类似问题确实前两天问过，分数不够分了，所以另开了一个帖子。
感谢大家的支持，我还是没明白dictionary为什么会占用那么多内存。呵呵。
为什么这么说呢？比如：我实验观察，将其保存到硬盘上是300M时，其占用内存达到1G左右。郁闷阿。
有的朋友说用lucence,我的经验是，他根本处理不了这么大数据，也就能玩个百八十个G撑死了。（06年的经验，新版本不清楚。呵呵）。
用数据库利用它的排序统计之类的肯定可以实现，不过，这么大的数据塞给数据库，第一，我需要再弄相同大小的硬盘，倒入，然后group by之类的，数据库我尝试过1G的，已经有点慢了。
至于还有位朋友说的，每个单词一个文件名，实现起来很简单，但唯一的缺点是，现有的操作系统目录下的文件如果过大的话，访问起来是一件很可怕的事情。呵呵。比如大家在一个文件夹下放上100W个文件，嘿嘿，哪怕是1k的，打开这个文件夹试试，就知道有多爽了。


我将文件分成10G一份，一个文件一个文件处理，然后倒入到数据库嘿嘿group by 一下，这样占用的很少，又利用的数据库的外排序统计功能，不过，毕竟还要操作好几步，不太爽阿。谁还有建议，大家再议议。

此言差矣,我并没有让你把20T的数据全部导入数据库然后再汇总,那是白痴.

我只是建议你把内存中的Dictionary转换成数据库表结构KeywordStats(Keyword, WordCOUNT),再建立好关于keyword字段的索引.
然后从你要统计的文件中一次读入一行,在数据库中如下更新:
然后用Update KeyWordStats SET WordCOUNT=WordCOUNT+1 WHERE Keyword='关键字'更新数据库.

如果你认为建立数据库,连硬盘都撑不下, 难道内存就能撑下了?!

把上边的方法综合一下，不要一次一更新，攒个1000-2000个记录到数据库更新一下

比如，DIC里面有了1000条记录，就序列化成XML到数据库里更新一下，然后清空DIC
等下次满了1000再更新一下

1000只是预计值，我估计如果允许，能几千更新一次


数据量在这摆着，再好的办法也能用不少时间

引用 29 楼 honkerhero 的回复:
把上边的方法综合一下，不要一次一更新，攒个1000-2000个记录到数据库更新一下

比如，DIC里面有了1000条记录，就序列化成XML到数据库里更新一下，然后清空DIC
等下次满了1000再更新一下

1000只是预计值，我估计如果允许，能几千更新一次


数据量在这摆着，再好的办法也能用不少时间


海量数据是真的，不过其实出现的词并不多，存下来估计也就2个G左右（这个我可以考虑用64位系统，8G内存搞定），问题是现在实验阶段一个文件，单词数2千多万，存储到硬盘上才300M，占用的内存就能达到2G，这是为什么呢？

hash就是这么占空间，这么大的数据量，hash冲突也很厉害，这种情况用Dictionary，时间与空间效率都不合算（由于冲突问题，上十万的数据就不要用hash了）。
如果是单词数2千多万，存储到硬盘上才300M，建议用B树结构，既能快速查询与修改，占用的空间又不会有Dictionary那么夸张。

Dictionary初始的时候是按Capacity占用内存的，当达到上限则会增长到至少2倍的内存，所以可能包含的数据量不大，但占用的内存却非常多。

这种任务是一次性的还是每周都要做一下，总得给个情况吧，20T什么之类的都不是什么问题，关键是你时间上的安排。人家有些解密算法光运算都要几个月呢

引用 23 楼 guoyichao 的回复:
 Dictionary初始的时候是按Capacity占用内存的，当达到上限则会增长到至少2倍的内存，所以可能包含的数据量不大，但占用的内存却非常多。


 是滴！Dictionary <K,T>当扩大规模时，每一次都是扩大一倍，而不是一个单元一个单元扩大。

 实际上还可以使用 SortedDictionary <TKey, TValue> 来牺牲一点（微不足道的）插入时间来换取最好的查询时间和存储空间。

 如果还超过内存空间，看起来只有将任务切分为多趟、每一趟使用磁盘来保存中间结果才可以。