这不是面试题，这是真事

搞个HashMap
key：Integer，用数字的前面6位
value：int[]，每个元素是 数字的后面9位（不超过10亿，所以，int可以表达）
如果value的int[]数组比较长，基本上每个15位的数字，可以节省4个字节（不考虑HashMap的key所在的内存，int[]数组本身所占的内存）

楼主能否对以上方案来个内存使用分析，并实际运行下后反馈下效果呢？
ps：我也思考了一下大整数拆分，想把位图表示成为二位数组，不过内存应该没有得到改进，比较关注你的这个新思路！

楼主，一个Integer占多少字节？何苦为了省long的4个字节而用hashmap呢，我觉得long数组是合理的。

Integer远比你想象的多（16字节）http://www.ibm.com/developerworks/cn/java/j-codetoheap/

所以我才提醒你没必要用Hashmap呀。

能说什么？这么庞大的一个功能，牵扯到的技术和细节太多了，需要做的测试也太多了，
比如，是不是真的需要2g内存，，？
比如你查分文件的策略是什么？这个文件在读的时候是不是继续写数据，
比如，数据分布是不是很均匀等等。
多线程，你定义好了，，需要那些技术吗？那些线程读数据，那些线程处理数据，那些线程验证数据等等？，有没有想过怎么在多线程的情况下组织线程的使用了？
按照你的需求，你可以重写一个map，，既然你只要只要得到两个以上的，那么你可以定义两个个set，第一个是2个以上，第二个1个，，就行了，
需要你那么麻烦啊，先问题复杂化，从复杂中看出简单，就开始做，

能不能把题目再说清楚一点。你怎么去得到第二列的整数都成问题吧。

既然第二列存的是个整数，也不会出现极端情况(比如同一个数字出现Interger.Max_Value次)，那么不用分文件，不依赖第三档库，用java.io就能搞定，对内存要求很低，只需要一个2.2G左右的临时文件。
大致算法：
1.创建临时文件
2.读取要解析的文件，每次读一行数据，读到第二列的整数n
3.利用RandomAccessFile读取临时文件的第n个byte(file.seek(n);file.read(byte[1]);)
4.如果读不到数据，或读到的是0，那么向这个位上写入一个1
5.如果读到的是大于0的数字，那么把该数字+1之后再回文件这个byte上(按楼主的要求，如果大于2的话不再写入也正确，因为用于计数的只有一个byte，记录不了太多重复)
6.读取完成后，遍历一次临时文件，如果读到第x位的值大于2，说明整数x出现过超过两次或以上

我感觉：
两个问题必须解决。
1.内存内处理，必然内存崩溃；
2.文件方式处理，必然速度慢；

个人建议：
1：拆分小文件，要看数据的情况，尽量给相似（比如开头两个或三个数字相同的）数值分派到不同文件；
2：对小文件进行排序排重处理；
3：存储小文件时记录行号，这样就可以直接确定结果行；
4：拆分小文件时尽量减少读写次数，可以采用内存缓冲方式，比如存储1w条即写文件。

请使用布隆算法

思路类似位图，而且貌似解决了内存问题，当然也增加了io，这个io是不是比拆分文件的io效率高很多了，学习了！