java.util.HashMap 类的 keySet() 方法的时间复杂度是多少？

Question

I am trying to implement a plane sweep algorithm and for this I need to know the time complexity of java.util.HashMap class' keySet() method. I suspect that it is O(n log n). Am I correct?

Point of clarification: I am talking about the time complexity of the keySet() method; iterating through the returned Set will take obviously O(n) time.

Answer 1

Getting the keyset is O(1) and cheap. This is because HashMap.keyset() returns the actual KeySet object associated with the HashMap .

The returned Set is not a copy of the keys, but a wrapper for the actual HashMap 's state. Indeed, if you update the set you can actually change the HashMap 's state; eg calling clear() on the set will clear the HashMap !

---

... iterating through the returned Set will take obviously O(n) time.

Actually that is not always true:

• It is true for a HashMap is created using new HashMap<>() . The worst case is to have all N keys land in the same hash chain. However if the map has grown naturally, there will still be N entries and O(N) slots in the hash array. Thus iterating the entry set will involve O(N) operations.

• It is false if the HashMap is created with new HashMap<>(capacity) and a singularly bad (too large) capacity estimate. Then it will take O(Cap) + O(N) operations to iterate the entry set. If we treat Cap as a variable, that is O(max(Cap, N)) , which could be worse than O(N) .

There is an escape clause though. Since capacity is an int in the current HashMap API, the upper bound for Cap is 2 ³¹ . So for really large values of Cap and N , the complexity is O(N) .

On the other hand, N is limited by the amount of memory available and in practice you need a heap in the order of 2 ³⁸ bytes (256GBytes) for N to exceed the largest possible Cap value. And for a map that size, you would be better off using a hashtable implementation tuned for huge maps. Or not using an excessively large capacity estimate!

Answer 2

Surely it would be O(1). All that it is doing is returning a wrapper object on the HashMap.

If you are talking about walking over the keyset, then this is O(n), since each next() call is O(1), and this needs to be performed n times.

Answer 3

This should be doable in O(n) time... A hash map is usually implemented as a large bucket array, the bucket's size is (usually) directly proportional to the size of the hash map. In order to retrieve the key set, the bucket must be iterated through, and for each set item, the key must be retrieved (either through an intermediate collection or an iterator with direct access to the bucket)...

**EDIT: As others have pointed out, the actual keyset() method will run in O(1) time, however, iterating over the keyset or transferring it to a dedicated collection will be an O(n) operation. Not quite sure which one you are looking for **

Answer 4

Java collections have a lot of space and thus don't take much time. That method is, I believe, O(1). The collection is just sitting there.

Answer 5

To address the "iterating through the returned Set will take obviously O(n) time" comment, this is not actually correct per the doc comments of HashMap :

Iteration over collection views requires time proportional to the "capacity" of the HashMap instance (the number of buckets) plus its size (the number of key-value mappings). Thus, it's very important not to set the initial capacity too high (or the load factor too low) if iteration performance is important.

So in other words, iterating over the returned Set will take O(n + c) where n is the size of the map and c is its capacity, not O(n) . If an inappropriately sized initial capacity or load factor were chosen, the value of c could outweigh the actual size of the map in terms of iteration time.

Answer 6

Tangential answer:

... iterating through the returned Set will take obviously O(n) time.

Actually that is not always true:

• It is true for a HashMap is created using new HashMap<>() . The worst case is to have all N keys land in the same hash chain. However if the map has grown naturally, there will still be N entries and O(N) slots in the hash array. Thus iterating the entry set will involve O(N) operations.

• It is false if the HashMap is created with new HashMap<>(capacity) and a singularly bad (too large) capacity estimate. Then it will take O(Cap) + O(N) operations to iterate the entry set. If we treat Cap as a variable, that is O(max(Cap, N)) , which could be worse than O(N) .

There is an escape clause though. Since capacity is an int in the current HashMap API, the upper bound for Cap is 2 ³¹ . So for really large values of Cap and N , the complexity is O(N) .

On the other hand, N is limited by the amount of memory available and in practice you need a heap in the order of 2 ³⁸ bytes (256GBytes) for N to exceed the largest possible Cap value. And for a map that size, you would be better off using a hashtable implementation tuned for huge maps. Or not using an excessively large capacity estimate!