DEV Community

Leo Han
Leo Han

Posted on

JDK: Understanding Map

#juc #jdk #jvm #microservices

Summary: The article explains HashMap as a data structure with hashing, buckets, resizing, collision handling, and iteration behavior.

Intended Reader

Java developers who use Map heavily and want to understand performance and correctness details.

Why This Matters

JDK collection types look simple at the API level, but their behavior depends on data structures, resizing, iteration, hashing, and concurrency assumptions.

Map performance depends on hash quality, capacity, load factor, resizing behavior, collision handling, and concurrency assumptions.

Mental Model

Choose collections by access pattern and mutation pattern, not by habit.

The practical way to read this article is to look for the boundary it clarifies: what state exists, who owns it, which operation changes it, and what evidence proves the system behaved as expected.

Implementation Walkthrough

  • Start with construction parameters such as initial capacity and load factor.
  • Follow put behavior through hashing, bucket selection, collision handling, and update logic.
  • Understand resize behavior because it affects latency and memory during growth.
  • Read deletion and clear behavior as part of lifecycle and memory management.

Pitfalls and Tradeoffs

  • A low load factor reduces collisions but increases memory use.
  • A poor initial capacity can trigger repeated resizing under large inserts.
  • HashMap is not safe for concurrent mutation without external protection.

Verification Checklist

  • Choose capacity based on expected size when loading large maps.
  • Avoid mutable keys that change hash behavior.
  • Use ConcurrentHashMap or synchronization for concurrent updates.

Practical Takeaways

  • List and Map implementations optimize different operations; the wrong choice can quietly become a performance bottleneck.
  • Hashing, resizing, ordering, and null handling are part of the practical contract.
  • Collections are not automatically thread-safe; concurrency needs an explicit design.
  • Reading the JDK source helps connect API behavior with memory and performance costs.

Visual Evidence

The migrated local images are preserved as supporting figures. They keep the English edition aligned with the same diagrams, screenshots, or console evidence used by the source article.

Figure 1: Supporting visual from the original technical note.
Figure 2: Supporting visual from the original technical note.
Figure 3: Supporting visual from the original technical note.

Selected Technical Snippets

The following snippets are preserved only when they are safe to publish in English without broken encoding or translated identifiers.

static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
Enter fullscreen mode Exit fullscreen mode 
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
public V putIfAbsent(K key, V value) {
return putVal(hash(key), key, value, true, true);
}
Enter fullscreen mode Exit fullscreen mode 
public V remove(Object key) {
Node<K,V> e;
return (e = removeNode(hash(key), key, null, false, true)) == null ?
null : e.value;
}
public boolean remove(Object key, Object value) {
return removeNode(hash(key), key, value, true, true) != null;
}
Enter fullscreen mode Exit fullscreen mode

Source Notes

  • Topic: JDK
  • Original source
  • Original publication date: 2024-01-03
  • This English edition is localized from the migrated article metadata, source structure, technical terms, local assets, and clean implementation evidence.

Closing Thoughts

The goal of this English edition is not to imitate the original wording sentence by sentence. It preserves the engineering argument, removes migration noise, and presents the article as a publishable technical note that future readers can use for design, debugging, or implementation review.

Top comments (0)