Analyzing a JDK ConcurrentLinkedQueue Memory Leak Bug in Jetty's QueuedThreadPool

The author begins with a personal anecdote before diving into a technical deep‑dive of a JDK bug (bug_id=8137185) that triggers memory leaks when Jetty's QueuedThreadPool uses ConcurrentLinkedQueue (CLQ) as its work queue.

The root cause is that the remove() method of CLQ does not unlink a node whose value has been set to null , leaving the node linked in the list and preventing garbage collection. This leads to gradual memory growth and increasingly slow queue operations.

A demonstration program repeatedly calls queue.add(obj) and queue.remove(obj) in a tight loop. When run on JDK 1.7.0_71, the demo shows the duration between iterations growing dramatically, the queue size staying at 1, and heap usage climbing until an OOM occurs after about 61 hours. The same demo on JDK 1.8.0_212 runs quickly with stable timings and no memory leak.

The article uses three monitoring tools—jconsole, VisualVM, and jmc—to visualize the heap usage trend, confirming the classic upward‑sloping memory‑leak pattern. Heap dumps reveal that CLQ nodes occupy over 94% of the retained heap.

Later JDK releases (7, 8, 9) include a fix that adds an unlink operation at the end of remove() , eliminating the leak. The author shows the patched source and notes that the issue is fully resolved in JDK 1.8.0_212 and later. Recommendations include using newer JDK versions, monitoring long‑running services with the mentioned tools, and being aware of similar concurrency bugs.