使用两个哈希表的java比使用一个好？

我有8000个键/值对。我读到散列速度是O（1），但随着键上的冲突，它将变成O（n），其中n是日志（项目编号），请纠正我，如果我的概念是错误的

然后我想如果我使用多个表，比如在hashtable1中放入1到3000，在hashtable1中放入3001到6000，那么性能应该有更高的机会达到2*O（1）？此外，如何确定表1、2等的最佳尺寸

---

另外，我读过一篇文章，如果我不使用多线程访问hashmap，那么使用hashmap会更好？它是真的吗？

冲突的概率仅取决于元素数量和哈希表大小之间的比率

您可以指定一个初始值，如果不指定，Java会很好地处理这个问题

---

是的，如果您没有并发访问权限，请使用HashMap，因为您不会有同步数据结构的额外负担。

您在第一句话中自己回答了这个问题：我知道hash速度是O（1），但键上有冲突

如果作为键的对象属于您编写的类，那么您可以完全控制如何计算

hashCode（）

。使用单个映射并实现

hashCode（）

，以避免冲突

如果您不控制

hashCode（）

的操作方式，您仍然可以编写一个类来包装键对象并为它们计算自己的哈希代码，并且结果将比使用多个映射的东西更容易读取

---

在大多数应用程序中，多映射方法是一种黑客攻击——哈希冲突导致的性能问题非常罕见——优化I/O之类的东西比这种微观优化带来的好处要大得多。因此，通常最好以可读性为目标。

在探查器证明这是一个瓶颈之前，不要想得太多，所以对所有密钥使用单个映射。是的，使用

HashMap

而不是

Hashtable

类。您可以通过事先计算准确的数量（或足够接近的数量）或条目来确定最佳大小（并相应地设置大小+加载因子）。当然这是相当简单的……我想是的，但我想知道这个概念思维是否正确？谢谢这是过早的优化，这是所有问题的根源。对于编辑器来说，只使用“`”字符格式化为代码，嗯，代码。O（N）不是代码。您还可以指定负载因子，以便在哈希表的性能不足以满足您的需要时对其进行优化。虽然对于键来说，它通常也是一个糟糕的散列函数。比如说10个项，其中3个在散列后将成为同一个键，这会破坏哈希表的性能吗，即使比率很小？thanks@manhon如果它们都有相同的键，看起来更像是散列方法中的一个问题。我不知道，我只是使用Java哈希表，并在其中添加一些单词，比如“apple”、“orange”，我不会检查散列后，这些水果是否有相同的键？或者我应该做些什么来看看是否存在冲突？@manhon再一次：如果你的应用程序出现性能问题，请使用探查器来确定它们在哪里。如果探查器显示问题出在

Map

（

Hashtable

、

HashMap

或您使用的任何实现）操作中，那么请开始担心，否则不要担心。