Java 高效算法（散列、排序）

我有以下问题-我得到一个文本文件，其中包含大量的单词，允许重复。我需要写一个算法，输出1000个出现频率最多的单词，并按降序排列。这里有一个例子

**input.txt**

aa aa bb cc bb bb bb dd dd

**output.txt** (note - frequencies can be repeated)

bb 4
aa 2
dd 2
cc 1

这是我解决这个问题的方法。首先阅读所有单词，并以单词为键将它们存储在内存中。这样做的最终结果是我拥有了所有的单词及其频率

现在，我迭代并为每个键值对创建一个对象{word，frequency}，然后将其插入（我为此编写了一个比较器）

现在，我只需迭代1000次就可以得到结果

我想知道解决这个问题的更好办法

谢谢

有没有更好的办法解决这个问题

有两种方式来看待这个问题。。。这取决于你所说的“更好”的意思

如果“更好”意味着“使用更少的时间和/或内存”，那么根据问题的大小和您可用的资源，有可能解决这一问题。例如：

>P>如果文本文件（或文件）大到足以证明这一点，可以考虑将问题划分为在多处理器上运行。但这不是直截了当的。。。如果问题太小，分区的开销实际上会使解决方案变慢
• 链接的Q&A描述了一种可能加快步骤2和步骤3的方法。关键在于，如果您对代码进行基准测试，您可能会发现步骤1是花费大部分CPU时间的地方。（而且输入文件越大，效果越明显…）

如果“更好”意味着“更快地解决问题”，那么答案可能是“不”。假设你有一个你描述的算法的良好实现版本，那么在使用一个（可能）更快的更复杂的算法时所付出的努力可能是不值得的

计算机时间比软件开发时间便宜

---

我的建议是：

对现有程序进行基准测试。它在真实的输入文件上运行是否足够快？如果“是”，则调用程序已完成

配置在真实输入文件上运行的现有程序。分析是否显示了任何明显的性能热点？有没有进行代码调优的机会？如果回答为“是”，请尝试它们，并重复基准测试步骤，看看它们是否真的有帮助

查看GC日志。是否有迹象表明您的代码有过多的GC开销？如果“是”，请查看一些简单的GC调优（如增加堆大小）是否会产生影响

如果您在完成上述所有操作后仍然没有获得可接受的性能，那么现在是开始寻找替代算法的时候了

有没有更好的办法解决这个问题

有两种方式来看待这个问题。。。这取决于你所说的“更好”的意思

如果“更好”意味着“使用更少的时间和/或内存”，那么根据问题的大小和您可用的资源，有可能解决这一问题。例如：

>P>如果文本文件（或文件）大到足以证明这一点，可以考虑将问题划分为在多处理器上运行。但这不是直截了当的。。。如果问题太小，分区的开销实际上会使解决方案变慢
• 链接的Q&A描述了一种可能加快步骤2和步骤3的方法。关键在于，如果您对代码进行基准测试，您可能会发现步骤1是花费大部分CPU时间的地方。（而且输入文件越大，效果越明显…）

如果“更好”意味着“更快地解决问题”，那么答案可能是“不”。假设你有一个你描述的算法的良好实现版本，那么在使用一个（可能）更快的更复杂的算法时所付出的努力可能是不值得的

计算机时间比软件开发时间便宜

---

我的建议是：

对现有程序进行基准测试。它在真实的输入文件上运行是否足够快？如果“是”，则调用程序已完成

配置在真实输入文件上运行的现有程序。分析是否显示了任何明显的性能热点？有没有进行代码调优的机会？如果回答为“是”，请尝试它们，并重复基准测试步骤，看看它们是否真的有帮助

查看GC日志。是否有迹象表明您的代码有过多的GC开销？如果“是”，请查看一些简单的GC调优（如增加堆大小）是否会产生影响

---

如果您在完成上述所有操作后仍无法获得可接受的性能，那么现在是开始寻找替代算法的时候了。

让我们重点关注第2步和第3步。假设有N个单词，每个单词有一个给定的频率，你必须找到前K个单词（在你的例子中是1000个）

您的方法在O（N log N）中运行。正如Stephen提到的，这已经足够好了：）无论如何，这里有一些可能的改进

第一种方法：根据链接中的建议，您可以使用最小堆（您可以使用优先级队列）来维护前1000名。实施起来并不难。一旦你有了频率图，就开始在上面迭代。如果最小堆的大小小于K，则继续推送该对（字、频率）。如果堆的大小为K，则将映射中当前项的频率与堆的根（堆中的最低频率）进行比较。如果新频率较低，则忽略它。如果它更高，则从堆中弹出最低值并推送当前值。这种方法将在O（N log K）中运行

秒