How a JDK Bug Makes ConcurrentLinkedQueue Leak Memory

From a Bug to Memory Leak

Recently a JDK bug (bug_id=8137185) was discovered that causes memory leaks when using ConcurrentLinkedQueue (CLQ) in server‑side code.

Impact on Jetty's QueuedThreadPool

Jetty's QueuedThreadPool uses CLQ for its internal queue. The bug makes the remove method leave a node detached but not unlinked, so the node cannot be reclaimed by GC, leading to slow growth of the queue and increasing latency.

Jetty source shows only size, add, and remove are used.

Community Investigation

Developer “max” reproduced the issue and posted a demo. Greg Wilkins, a Jetty core contributor, confirmed the problem, expressed surprise, and proposed a fix that replaces the CLQ with a CurrentHashSet or uses ConcurrentHashMap.newKeySet() in newer JDK versions.

Demo and Performance Observation

A test program repeatedly adds and removes a single element from a CLQ. On JDK 1.7.0_71 the duration between loops grows, the queue size stays at 1, and memory usage continuously rises, eventually causing OOM after many hours.

On JDK 1.8.0_212 the same program runs quickly, the duration remains stable, and memory usage does not increase, confirming that the bug was fixed.

Monitoring Tools

Tools such as jconsole, VisualVM, and JMC were used to visualize heap usage, showing a classic upward‑trend graph for the leaking version and a flat line for the fixed version.

Take‑away

The bug demonstrates how a small implementation mistake in a core library can cause severe memory leaks and performance degradation in production systems, and highlights the importance of proper monitoring and timely upgrades.