Java 散列一个长字符串进行比较快还是比较两个字符串快？

假设我有一个非常长的字符串列表（40-1000个字符）。用户需要能够在列表中输入术语，列表将报告该术语是否存在

除了存储之外，在长字符串旁边存储散列是否更有效，然后当用户尝试查找时，它会对输入进行散列，并将其与散列列表进行比较

---

假设数据适合堆（即内存），最好使用集合（或映射，如果每个字符串都有相关数据）。如果确实需要列表，可以将存储从列表更改为集合（使用HashSet），也可以维护一个单独的集合

计算字符串的

hashcode（）

的时间与字符串的长度成正比。查找字符串的时间相对于集合中的字符串数是恒定的（一旦计算了hashcode），假设一个正确实现的

hashcode（）

集大小正确

如果在未排序的列表上使用

equals（）

，则查找时间可能与列表中的项目数成比例。如果对列表进行排序，则可以使用比较数进行二进制搜索，以查找与列表中项目数日志成比例的一个字符串（每次比较都必须比较字符，直到找到差异）

本质上，集合有点像是将字符串的hashcode放在手边，但它更进一步，以一种非常快速的方式存储数据，直接跳转到具有该hashcode值的集合元素

---

请注意，两个字符串的equals比较可以在发现差异后立即退出，但可能必须比较两个字符串中的每个字符（当它们相等时）。如果字符串具有类似的长前缀，则可能会影响性能。有时，您可以从对数据类型内容的了解中获益（从性能角度）。例如，如果您的所有字符串都以相同的1K前缀开头，但结尾不同，您可以通过重写

equals（）

实现从结尾到开头进行比较来获益，这样您就可以更早地发现差异。

您的问题不够具体

首先，我假设您的意思是“我有一组很长的字符串”，因为列表对于状态查找来说是非常低效的结构

一些想法：

• 取决于字符串集（即域）的属性，前缀树在内存和速度方面可能比任何类型的哈希表都要高效得多。前缀树表示比较，而不是哈希计算
• 否则，您应该使用某种哈希表，这意味着您无论如何都应该计算哈希代码，每个字符串至少计算一次。在这种情况下，将哈希代码与字符串一起存储似乎是合理的。但是为了保证严格的正确性，最后还是应该按内容比较字符串，因为哈希冲突是可能的
• 理论上，分布良好的哈希函数的最大速度是3-4字节/时钟周期（即哈希函数每CPU周期消耗3-4字节）
• 流比较的速度-取决于某些条件和代码的编译方式，现代CPU上的指令允许每个周期最多比较16个字节。有趣的是，

  array.equals

  方法是内部化的，但是

  sun.misc.Unsafe

  类中没有“原始”内存比较方法

以Lucene为例：