Introduction

LinkedBlockingQueue.poll() without a timeout does not block forever. If the queue is empty, it returns null immediately. So when developers say poll() "hangs," the real problem is usually one of three things: they are calling the timed overload, the thread is blocked somewhere around the call, or the producer side stopped making progress.

Know Which poll You Are Calling

There are two important overloads:

E poll()
E poll(long timeout, TimeUnit unit)

The first version is non-blocking. The second version waits up to the given timeout. That distinction matters because code reviews often miss it when the timeout call is wrapped by helper methods.

Example:

1import java.util.concurrent.LinkedBlockingQueue;
2import java.util.concurrent.TimeUnit;
3
4public class Demo {
5    public static void main(String[] args) throws Exception {
6        LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<>();
7
8        System.out.println(queue.poll());
9        System.out.println(queue.poll(2, TimeUnit.SECONDS));
10    }
11}

The first line returns immediately. The second waits for up to two seconds.

A "Hung" Consumer Often Means a Starved Producer

If a consumer repeatedly calls poll(timeout, unit) and producers stop enqueueing work, the consumer thread may spend most of its time waiting. That can look like a queue bug even though the queue is behaving correctly.

Here is a small example:

1import java.util.concurrent.LinkedBlockingQueue;
2import java.util.concurrent.TimeUnit;
3
4public class ConsumerDemo {
5    public static void main(String[] args) throws Exception {
6        LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<>();
7
8        String item = queue.poll(5, TimeUnit.SECONDS);
9        if (item == null) {
10            System.out.println("No work arrived");
11        }
12    }
13}

If no producer writes into the queue, the thread waits because you asked it to wait.

Look Around the Queue Call

Even with the non-blocking overload, the surrounding code may be what is stuck. Common examples include:

• logging or metrics calls that block
• work performed after the queue returns an item
• synchronized code around the queue access
• deadlocked producer threads
• executor saturation that prevents producers from running

That is why a thread dump is more useful than staring at the queue class. If the dump shows the thread waiting in poll(timeout, unit), the wait is expected. If it shows the thread elsewhere, poll() is probably innocent.

Use Timeouts Deliberately

Timed polling is often the right tool because it lets a consumer wake up periodically, check a stop flag, and exit cleanly:

1import java.util.concurrent.LinkedBlockingQueue;
2import java.util.concurrent.TimeUnit;
3import java.util.concurrent.atomic.AtomicBoolean;
4
5public class Worker implements Runnable {
6    private final LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<>();
7    private final AtomicBoolean running = new AtomicBoolean(true);
8
9    @Override
10    public void run() {
11        try {
12            while (running.get()) {
13                String task = queue.poll(1, TimeUnit.SECONDS);
14                if (task != null) {
15                    System.out.println("Processing " + task);
16                }
17            }
18        } catch (InterruptedException e) {
19            Thread.currentThread().interrupt();
20        }
21    }
22}

In this pattern, the timeout is part of the design. A one-second wait is not a hang. It is controlled idling.

When to Suspect Something Else

If you are truly using poll() with no timeout and the thread still appears frozen, investigate:

• whether another lock is held before the call
• whether the thread is blocked in downstream processing
• whether the JVM is CPU-starved or deadlocked
• whether you are reading the wrong stack trace or wrong thread

LinkedBlockingQueue is widely used and well tested. Apparent hangs are usually application-level concurrency issues around it.

Common Pitfalls

• Confusing poll() with poll(timeout, unit).
• Assuming a waiting consumer proves the queue is broken when producers may be stalled.
• Ignoring thread dumps and debugging by intuition alone.
• Holding external locks around queue operations and then blaming the queue.
• Treating an intentional timeout wait as a bug instead of a control-flow choice.

Summary

• Plain poll() returns immediately with null if the queue is empty.
• The timed overload is allowed to wait and is often what developers are actually calling.
• Many apparent queue hangs are really producer starvation or blocking code around the queue.
• Thread dumps are the fastest way to see where the thread is actually waiting.
• Diagnose the whole producer-consumer pipeline, not only the queue method name.