为什么在 HashMap.put() 中以一种奇怪的方式比较键？ [复制]答案

【问题标题】：Why keys are compared in a strange way in HashMap.put()? [duplicate]为什么在 HashMap.put() 中以一种奇怪的方式比较键？ [复制]
【发布时间】：2013-12-17 00:00:07
【问题描述】：

在浏览 HashMap 的 put() 代码时，我遇到了一段奇怪的代码。考虑下面的代码摘录：

490  public V put(K key, V value) {
491        if (table == EMPTY_TABLE) {
492            inflateTable(threshold);
493     }
494  if (key == null)
495   return putForNullKey(value);
496     int hash = hash(key);
497     int i = indexFor(hash, table.length);
498     for (Entry<K,V> e = table[i]; e != null; e = e.next) {
499         Object k;
500         if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
501             V oldValue = e.value;
502             e.value = value;
503             e.recordAccess(this);
504             return oldValue;
505         }
506     }

在第 500 行，为什么将键分配给一个新变量k，然后在 OR 条件中使用？为什么不能直接写成这样：

if (e.hash == hash && (e.key == key || key.equals(e.key))) {

我不知道为什么它是这样写的，但我确信它的编码背后有一些原因。是某种优化吗？
有人能解释一下吗？

【问题讨论】：

标签： java optimization reference hashmap

【解决方案1】：

他们正在保存对象取消引用。

(e.key == key || key.equals(e.key))

那必须跟着 e->key 两次。

这跟在后面一次：

((k = e.key) == key || key.equals(k))

虽然节省很少，但在现代编译器/优化器/等中甚至可能根本没有节省。请记住，这段代码是很久以前编写的，很可能是由具有 C++ 编程背景的人编写的，在这种情况下，这类事情既更常见也更有用。

对一个非常频繁访问的类进行非常频繁的操作可能是有意义的。在大多数情况下，虽然微不足道的节省并不能弥补可读性的损失。

【讨论】：