Situation: Program using lots of threads, communicating between them
with LinkedBlockingQueues.
Problem: Unbounded queue throws OutOfMemoryError. How to
anticipate/measure system capcity, and ultimately adjust queue sizes as
conditons on the server changes (to avoid throwing the excepton at
all).

Filling a Queue (LinkedBlockingQueue) with elements, I run into a
number of total elements in the queue where I throw a Heap error:
OutOfMemoryError. Once the queue (unbounded) reaches this heap limit,
it throws Java Heap OutOfMemoryError. The heap is used to track all
objects in memory, right? I thought RAM was used to store objects, and
heap was used to track each object in all threads.

This might not be a queue error at all, but merely a "too many objects
in all threads to keep track of" problem. Filling the queue with too
many elements might just trigger the condition.

Is there a way to anticipate the queue's capacity for objects, and thus
stop offer()-ing and direct element candidates elsewhere until the
queue's capacity increases? If the known system capacity for elements
in the queue were known, I could manage the queue capacity threshold
for each queue. The idea might be to anticipate the system's capacity
at runtime and configure a limit to the queue, instead of leaving it
unbounded.

In addition, I wonder if using a ConcurrentLinkedQueue might be more
robust than the LinkedBlockingQueue I'm using now. I can't seem to find
any performance comparisons or benchmarks.

TIA!

BogusException