java - 为什么 HashMap.put() 中的键以奇怪的方式进行比较？

Question

这个问题已经有答案了:

Why not compare e.key directly instead of assigning it to a variable? (1 个回答)

已关闭 9 年前。

在浏览 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行，为什么把key赋给新变量k然后用在 OR 条件中？为什么不能直接写成如下:

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

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

Answer 1

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

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

必须跟随 e->key 两次。

下面是一次:

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

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

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