好的，所以我最近已经阅读了很多关于HashMap的内容，我认为有些人会让它比实际上更混乱。我想知道这个程序是否正确。
所以当你有一个Key和Value，例如 Peter Dirichlet 出生时 1805-02-13 ，在这种情况下Key为"Peter Dirichlet"，Value，"1805-02-13"。
第一步是在Key上使用哈希函数，即"Peter Dirichlet"。并且让我们说哈希函数将其生成到桶nr 5。这意味着在该特定存储桶中，在索引5上，将存储键/值对"Peter Dirichlet","1805-02-13"。
因此，如果我们想要检索此信息，我们使用get("Peter Dirichlet")并使用哈希函数，将找到索引号，并找到键/值对Peter Dirichlet 1805-02-13。
然后我们遇到了碰撞的情况。我们现在说"Leo Euler"出生"1783-09-18"。由于某种原因，我们的哈希函数将宝贵的Leo也放在索引号5中。由于Key-Value 不与Peter Dirichlet相同，因此无法替换。
现在，在＆＃34;桶＆＃34;第五，我们有Leo Euler和Peter Dirichlet。
如果我们现在想要检索Leo，我们使用get("Leo Euler")，哈希函数将指向我们的第五个桶。 ＆＃34; Woops ＆＃34;，HashMap说，＆＃34; 这里是一次碰撞＆＃34;。
然后我们将迭代这些对象，直到找到"Leo Euler".equals("Leo Euler")。那么它会得到key.equals(key)？
因此，对于Leo而言，true "Peter Dirichlet" true不会HashMap，而是返回Key / Value对。
这是QueryBuilder qb = matchQuery(
"username_field",
"user123"
);
SearchResponse response = Client().prepareSearch("users_dashboard").setQuery(qb)
.setSource("username_field")
.execute().actionGet();
的正确解释吗？
答案 0 :(得分：1)
是的，这是正确的解释。 .hashcode()（对于Java，其他编程语言的等价物）是不够的。 冲突可能会发生。它将遍历存储桶，并为每个元素将查询（一个键）与该键值对的键进行比较。当然，从找到正确的密钥的那一刻起，返回其对应的值。如果在桶中找不到密钥，我们知道它不在hashmap中。
这就是.equals和.hashcode彼此签订合同的原因：如果a.equals(b)，那么a的哈希码必须等于{{1} }：b。请注意，相反的情况并非如此：具有相同的哈希码并不意味着对象是等效的。
对您的问题可能只是一个小小的评论，即HashMap的内部数组不是由键值对组成，它由键值的集合组成对。在许多情况下，这可能是a.hashcode() == b.hashcode()或LinkedList。有些实现使用二叉搜索树，但一般来说它往往不会有太大的回报：毕竟使用好的哈希函数应该减少冲突量。