Why a Simple HashMap Bug Caused Massive Memory Leaks in High‑Concurrency Java Services

A new architect with a BAT background joined the department, boasting massive high‑concurrency experience and immediately took on the most concurrent task: collecting the average response time and total request count of all interfaces.

He implemented the monitoring logic with a ConcurrentHashMap, storing a monitor key and value for every request, and claimed that no comments were needed.

Because the key class did not override equals() and hashCode(), each request generated a distinct key object, leading to millions of duplicate entries in the heap and eventually an OutOfMemoryError. Monitor$MonitorKey@15aeb7ab The team used jmap and Eclipse MAT to analyze the heap and found that MonitorKey and MonitorValue objects filled the memory.

A quick fix was attempted by adding a synchronized keyword to the visit method, but this introduced a coarse‑grained lock.

public synchronized void visit(String url, String desc, long timeCost)

A more efficient solution was proposed: use ConcurrentHashMap.putIfAbsent to create the value atomically and then update counters.

MonitorKey key = new MonitorKey(url, desc);
MonitorValue value = monitors.putIfAbsent(key, new MonitorValue());
value.count.getAndIncrement();
value.totalTime.getAndAdd(timeCost);
value.avgTime = value.totalTime.get() / value.count.get();

The discussion escalated, with the technical director arguing that a simple synchronized method is safer for production, while others advocated the lock‑free approach.

Ultimately the bug was resolved by correctly overriding equals() and hashCode() for the monitor key and by adopting the putIfAbsent pattern, eliminating the memory leak and stabilizing the service.