Producer-Consumer Pattern in Java — BlockingQueue vs wait/notify

Producer-consumer decouples work generation from work processing via a shared queue.

The production answer — BlockingQueue

• LinkedBlockingQueue(capacity) or ArrayBlockingQueue(capacity) — always bounded
• Producer: queue.put(item) — blocks when full, giving backpressure
• Consumer: queue.take() — blocks when empty, no polling
• Thread-safety, locking, waiting, signaling — all internal
• Write simple loops; ship the code

Why not wait/notify

• It's the hand-rolled version from before Java 5
• Error-prone: while not if (spurious wakeups), notifyAll not notify, inside synchronized, InterruptedException handling
• BlockingQueue implementations do exactly this correctly and faster
• Only reason to know wait/notify: interviews and legacy code

Implementing wait/notify (for the interview)

synchronized (lock) {
  while (queue.size() == capacity) lock.wait();
  queue.offer(item);
  lock.notifyAll();
}

• while, not if: wait() can wake spuriously
• notifyAll, not notify: producers and consumers may share the lock; notify might wake the wrong kind
• Inside synchronized (lock): else IllegalMonitorStateException
• Catch InterruptedException; at minimum preserve the flag

BlockingQueue variants

• ArrayBlockingQueue(capacity) — fixed, two-lock ReentrantLock internally, good under contention
• LinkedBlockingQueue(capacity) — separate head/tail locks, better throughput at low contention
• LinkedBlockingQueue() — unbounded; dangerous, OOM risk
• SynchronousQueue — zero buffer, direct handoff (used by newCachedThreadPool)
• LinkedTransferQueue — unbounded with optional direct transfer, high-throughput
• PriorityBlockingQueue, DelayQueue — specialized ordering, but unbounded

Capacity sizing

• Formula: burst_size + safety_margin
• HTTP request queue: typically 50–200
• Log events: 100–500
• ETL pipeline with slow downstream: 10–100
• Unbounded is almost always wrong — slow consumer piles up work until OOM

Shutdown patterns

• Poison pill: sentinel object; one per consumer; deterministic drain
• Volatile flag + poll(timeout): simpler, wakes periodically
• shutdownNow(): interrupts consumers on take(); in-flight work may be lost
• Pick based on whether you need to drain or can discard

Multiple producers/consumers

• Safe with any BlockingQueue
• Default non-fair is fine for throughput
• ArrayBlockingQueue(capacity, true) for fairness if needed

Recommendation: For production code, always `BlockingQueue` with a bounded capacity — never unbounded. Sized to accommodate expected burst plus a safety margin. Use `LinkedBlockingQueue(capacity)` as the default, or ArrayBlockingQueue when you need more stable throughput under heavy contention. Handle shutdown explicitly with poison pills or a volatile drain flag. Never hand-roll wait/notify — the failure modes are subtle and BlockingQueue is already battle-tested across every Java codebase. If you find yourself needing priority or delay ordering, reach for PriorityBlockingQueue / DelayQueue but add upstream rate-limiting since they're unbounded.