Blocking and concurrent queues at a glance

Think of them as different loading docks. Some docks have a bounded waiting area and make trucks wait outside when it fills. Some docks are pure hand-offs with no storage at all. Some docks never block, they just let workers check whether a package is available and move on.

For this lesson, we'll map the queue family, not rebuild the concurrency machinery underneath it. We'll focus on BlockingQueue method families, ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQueue, DelayQueue, SynchronousQueue, TransferQueue, ConcurrentLinkedQueue, ConcurrentLinkedDeque, LinkedBlockingDeque, back-pressure and the producer-consumer poison-pill pattern. Deeper lock, condition, CAS and memory-model internals are covered in the Concurrency module.

01Picture it first: pick the queue by the kind of waiting

Start with the question, not the class name: should a thread wait, return immediately, or hand work directly to another thread? Once you answer that, the family becomes much less memorisation-heavy.

The decision tree below is the map I use in code reviews.

Fig. 1

A decision tree starts with whether threads need to wait, then branches to BlockingQueue choices such as bounded FIFO, linked FIFO, priority, delay and hand-off queues, or to non-blocking lock-free FIFO queues

Notice the first fork. BlockingQueue is about coordination through waiting. ConcurrentLinkedQueue is about safe concurrent access without waiting. Both are thread-safe, but they solve different problems.

02BlockingQueue under the hood: four ways to ask

BlockingQueue is the interface behind the classic producer-consumer pattern. It extends Queue, but adds methods that know how to wait for capacity or wait for data.

The answer to the prompt is offer(item, 200, TimeUnit.MILLISECONDS). That method is useful when you want back-pressure, but you also want a request thread to fail or shed load instead of waiting forever.

Here is the minimum producer-consumer shape:

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.TimeUnit;

record OrderJob(String id, int amountCents) {}

BlockingQueue<OrderJob> queue = new ArrayBlockingQueue<>(100);

boolean accepted = queue.offer(new OrderJob("o-42", 49900), 200, TimeUnit.MILLISECONDS);
if (!accepted) {
    throw new IllegalStateException("too many orders queued");
}

OrderJob next = queue.take(); // waits while the queue is empty

Notice three things:

• put and take are coordination points. They block the calling thread.
• offer with a timeout is often better at service boundaries because it gives you a limit.
• BlockingQueue rejects null, so null can safely mean "nothing available" for poll.

Fig. 2

Two producers put jobs into a bounded blocking queue while two consumers take jobs out; when the buffer is full producers wait, creating back-pressure

Back-pressure is the important production word here. If consumers can process 200 jobs per second and producers send 1,000 jobs per second, a queue does not create capacity. A bounded queue makes the overload visible by slowing or rejecting producers. An unbounded queue hides the overload as growing memory and longer latency.

03The BlockingQueue family at a glance

Let's name the pieces first, then compare them. You do not need every internal lock path for a Collections interview, but you should know what each queue is for.

ArrayBlockingQueue: bounded array, one lock

ArrayBlockingQueue is a fixed-size circular array. You choose the capacity in the constructor, and it never grows. Internally it uses one lock with two conditions: one for "not empty" and one for "not full".