有一个1G大小的一个文件，里面每一行是一个词，词的大小不超过16字节，内存限制大小是1M。返回频数最高的100个词

首次发现这个问题是还觉得挺好回答的，但是仔细一想，他说的限制内存为1M，那么就表示运行内存为1M，如果按照网上的答案：

https://blog.csdn.net/qq_41946557/article/details/102708581

的话，那么内存为1M是完不成的，因为要使用HashMap记录词频不需要内存吗？不是我太杠啊，真的需要考虑啊，那么有没有一个更加可行的方案呢？其实是有的，不使用hashmap，但是和他类似的方案，即以单词为文件的命名方案，如果匹配到了一个单词，那么直接创建以这个单词名为文件名的文件，如果已存在直接在文件里将单词的个数+1.
当然打开文件是需要消耗内存的，但是可以忽略不计了，如果非要抬杠的话，那么在之前的计算1M能存放多少的单词上就需要修改了，为打开文件做内存预留。
但是这里就有一个悖论了，如果2^16个2字节的单词是1M，那么打开这个文件的内存消耗是哪里来的呢？哈哈哈，真不是我抬杠啊，只是在这里提出一个疑问，如果只是简单的给出一个思路，那是完全没得问题的。
但是仔细又有一想，欸，可以啊，我又不是一次性将所有的数据都读出来，我可以使用迭代器模式一个一个的读，然后在一个一个的取建立文件或是在已存在的文件中去修改数据，所以说一次性将所有的数据都读经来太傻了。那么。。。。。。，还需要之前的大文件分成吗？貌似不需要了啊，并且由于是大文件，那么内部的数据极有可能是连续的，如果分成小文件的话，那么就没有必要了，因为这样会导致磁盘上的磁针来回的切换，一般的分成小文件不都是多线程的操作么但是这里只有1M，那么多线程估计都开不起来，只能是单线程的，那么还分个毛线啊。。。。。。
所以说我认为对于这个题目来说不需要分成小文件，只需要一个打开文件的索引，然后依次读取行，一行一行的毒，然后一行一行的判断，写文件（这样内存消耗就只是一个io文件流-未知字节，但是应该会小于1k吧（这个没有求证过，如果有知道的，可以在评论区说下，谢谢）+读取的数据–2字节）。
最后统计所有的单词文件，然后就是排序了，由于内存只有1M，所以建立一个只有100个元素的大顶堆（我不明白为什么网上的都是小顶堆，不是显示词频最大的前100个吗？为啥是小顶堆？）
碰巧看到了有了点疑惑，发表下自己的见解，如有不对，请不吝指正！