I think the LinkedHashMap
has to be faster in traversal due to a superior nextEntry
implementation in its Iterator
Here is why :
Let us go step by step from the values
implementation.
The HashMap
implementation of values
is this :
public Collection<V> values() {
Collection<V> vs = values;
return (vs != null ? vs : (values = new Values()));
}
The LinkedHashMap
extends from HashMap
and inherits the same implementation.
The difference is in the Iterator
implementation for the Values
in both.
for HashMap
it extends from java.util.HashMap.HashIterator
private final class ValueIterator extends HashIterator<V> {
public V next() {
return nextEntry().value;
}
}
but for LinkedHashMap
it extends from java.util.LinkedHashMap.LinkedHashIterator
private class ValueIterator extends LinkedHashIterator<V> {
public V next() { return nextEntry().value; }
}
so the difference essentially boils down to nextEntry
implementation.
For LinkedHashMap
it is just calling e.after where e is the Entry
,
but for HashMap
there is some work involved in traversing the Entry[]
array to find the next next.
UPDATE : Code for nextEntry()
in HashMap
final Entry<K,V> nextEntry() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
Entry<K,V> e = next;
if (e == null)
throw new NoSuchElementException();
if ((next = e.next) == null) {
Entry[] t = table;
while (index < t.length && (next = t[index++]) == null)
;
}
current = e;
return e;
}
The Entry[] is not a contiguous store. (There could be null values in between). If you take a look at the above code, what it does is point next to current and find the next next by iterating over the Entry[] .
But I think this performance gain will come at the cost of insertion. Check out the addEntry
method in both classes as an exercise.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…