Understanding HashMap Resize Behavior and the Revision from Expansion Count to Resize Count in Alibaba's Developer Manual

While reviewing the latest "Alibaba Development Manual – Songshan Edition", I discovered that the description of HashMap's expansion behavior for 1024 elements has been corrected: the term "expansion count" is replaced by "resize count" to avoid ambiguity.

The manual explains that when a HashMap is created with the no‑argument constructor, no storage is allocated initially; the first put call triggers a resize() to allocate the default capacity of 16 (in JDK 1.8). This operation is now counted as a resize rather than an expansion.

HashMap provides four constructors:

public HashMap(int initialCapacity, float loadFactor) { }
public HashMap(int initialCapacity) { this(initialCapacity, DEFAULT_LOAD_FACTOR); }
public HashMap() { this.loadFactor = DEFAULT_LOAD_FACTOR; }
public HashMap(Map
m) { this.loadFactor = DEFAULT_LOAD_FACTOR; putMapEntries(m, false); }

Using the no‑argument constructor results in only the default load factor (0.75) being set. When put is invoked, the internal putVal method checks whether the table is null; if so, it calls resize() to create the table.

public V put(K key, V value) { return putVal(hash(key), key, value, false, true); }
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
    Node
[] tab; Node
p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
    // ... rest of the method ...
}

The Songshan edition states that the total number of resize() calls when inserting 1024 elements without an initial capacity is eight. The first resize occurs during the initial put , and subsequent resizes happen each time the size reaches the threshold (capacity × loadFactor), doubling the capacity until it reaches 1024.

Therefore, depending on interpretation, some consider the initial allocation a resize (resulting in eight resizes), while others count only the subsequent capacity doublings (seven resizes). The manual adopts the unambiguous "resize count" terminology.

In practice, to avoid the performance cost of eight resizes, it is recommended to initialize the HashMap with an appropriate capacity (e.g., 2048) when storing a large number of elements.