Why Netty’s IntObjectHashMap Beats HashMap: A Deep Dive into Performance and Design

Pulling Source Code

The investigation starts by locating the IntObjectHashMap class in Netty’s source repository. The author checks the 4.0 branch, finds the class and its benchmark, and notes that the 4.1 branch lacks it directly.

IntObjectHashMap

IntObjectHashMap replaces the standard HashMap with a map that uses primitive int keys and stores values directly, eliminating the need for wrapper objects and reducing memory footprint.

Key design points include:

Open addressing with linear probing for collision resolution.

Capacity is always adjusted to an odd number to avoid probing issues.

The hashIndex method evolved through three commits, ending with return (key % keys.length + keys.length) % keys.length;, which guarantees a non‑negative index.

The put method works by:

Computing the index via hashIndex.

If value[index] == null, the key/value pair is stored.

If the slot is occupied, it checks whether the existing key matches; if not, it probes the next slot (wrapping around) until an empty slot or the same key is found.

When the map reaches its maxSize, it grows by doubling its capacity.

Deletion implements compaction: when a key is removed, subsequent entries that were displaced due to collisions are shifted back to fill the gap, which can be costly (up to O(N)) if the map is full, hence a smaller loadFactor (default 0.5) is recommended.

Extra Point

The article highlights that a high loadFactor (e.g., 1) delays resizing, causing more collisions and longer probe sequences. By setting loadFactor to a lower value, resizing occurs earlier, improving performance.

Netty 4.1

Although the class is absent in the 4.1 source tree at first glance, it is generated from a Groovy template during the build. The generated version adjusts capacity to the nearest power‑of‑two, which appears to contradict the odd‑capacity rule in 4.0, illustrating the subtle differences between branches.

Even capacities can break probing.

Overall, the deep dive shows that IntObjectHashMap achieves better performance than a regular HashMap by:

Using primitive keys to avoid boxing.

Storing only values, eliminating node objects.

Employing linear probing with careful capacity handling.

Providing a compaction‑based delete that keeps the map dense.

These optimizations can translate into substantial resource savings in high‑throughput systems such as Qunar’s ticket‑pricing service.