我遇到了几个问题和文章，说 Java 中的字典实现最好使用 tries。但是据我看来，大多数文章都没有涉及到重要的问题。因此，下面是一个真实世界的任务：
假设我需要使用 Java 实现一个词典（比如 Lingvo，但更简单）。对于我的特定任务，需要存储单词定义，并执行快速的词典查找。
请回答以下问题：
P.S.：非常感谢提供代码示例。
先前的更新：如果我们在谈论 Java 中的标准 DS 实现，那么 HashTable 是否是这个特定任务的最佳选择？为什么不是 HashMap、TreeMap 或 LinkedHashMap？
我只想针对你问题中的一个点进行解答:
Trie不是通用的字典数据结构。原因在于，trie是一种专门用于（子）字符串搜索的专业化搜索树。通常，您会更关心通用搜索树，例如二叉搜索树或B树。
所有这些实现都依赖于字典元素的排序，并且它们所有常见操作的平均和最坏情况下的运行时间都是对数级别。
相比之下，哈希表不需要元素相对顺序。相反，它需要元素是可哈希的并且可以相等比较。常见哈希表特征的最坏情况特性比树更差，即与元素数量成线性关系。
然而，通过小心处理，哈希表操作的平均情况可以做到常数（即独立于容器大小）。此外，可以证明较慢的操作非常少见。
在实践中，这意味着除非是非常专业化的用例，否则哈希表都能胜过基于树的字典。
这样做的缺点是哈希表对其元素施加了一个看似随意的顺序。如果您想按排序后的顺序获取字典中的项目，则不应使用哈希表。
(还有其他有趣的字典实现，例如跳表与搜索树竞争并且像布隆过滤器这样的概率实现。)
只有当您处理字符串值的字典时才可以使用基于trie的实现。在这种情况下，它实际上经常是一个不错的选择，特别是如果字典中的许多字符串共享共同前缀并且相当短。
编辑：请不要再点赞了，我误读了问题。原帖并不是想要一个词典来验证单词的拼写、建议、自动完成或其他类似功能（我当时认为这是他想要的）。原帖想要的是一个键值映射，其中每个单词都有一个定义。
作为一名曾经从事过词典开发的人员，我可以告诉你，你正在采用错误的方法。
这并不像选择哈希表还是trie树那么简单。
你提到了Lingvo：它远不止于一个表格。
你是否希望提供与输入单词相近的建议？那么你可能需要对用户输入的内容进行排列组合，并查看每个排列组合是否存在于词典中：如果存在，则需要计算其Levenhstein编辑距离，并首先建议具有最短LED的单词。
你是否希望自动完成/建议最可能的匹配项（就像Google所做的那样）？那么你需要一个非常高级的数据结构，例如BK树（基本上是一个LED树，如果我理解正确的话）。
你的字典中将有多少个单词？如果使用字符串和其他重量级Java对象/数据结构制作包含400,000个单词的字典，性能将会受到严重影响（再次强调：一个字典不仅仅是一个哈希表，一个字典通常涉及多个数据结构）。这将难以适应用户计算机内存。有已知的可搜索的方法来存储单词，其中每个单词可以在少于15位比特的情况下打包（没错，少于15位比特的情况下）。
除此之外，你可能还希望根据语音学进行建议，例如使用双metaphone映射。
一个“单词字典”真的远不止于一个键值表。由于用户期望的功能和涉及的数据量，它确实是一个复杂的生物。只是英语+一些专业领域的术语、医学、计算机科学等就会给你带来数十万条数据：试着把它们放入Java HashMap中，然后......炸了！
HashTable是一个线程安全的HashMap（类似于Vector和ArrayList的区别），因此当您知道多个线程不会与其交互时，使用HashMap更好。有趣的是，Collections.synchronizedMap(new HashMap())比HashTable更快，并且似乎提供了相同的安全性。TreeMap要求其键是可比较的，并使用红黑树。LinkedHashMap使用左/右/父引用（如果我没记错的话）而不是数组。这类似于ArrayList和LinkedList之间的差异。就我个人而言，在 Java 中，我很少使用Linked...集合。 - KitsuneYMG