Is there a way to determine how many runnables are in a newFixedThreadPool Queue?

Question

I'm firing up

Executors.newFixedThreadPool(100);

in a main program and the producer is pumping in jobs faster than the consumers can keep up. Is there a way to see how many items are queued up in the underlying unbounded queue that the newFixedThreadPool uses?

Answer 1

Use java.util.concurrent.ThreadPoolExecutor#getTaskCount to get the number of the scheduled tasks in the thread pool. However, note that this is just an approximation and may not be exact.

If you want to solve the issue of the producer produsing tasks faster than the consumer, limit the size of the underlying quese and pass in one of the implementations of RejectedExecutionHandler while creating the java.util.concurrent.ThreadPoolExecutor. See the snippet below from the docs of ThreadPoolExecutor:

Rejected tasks

New tasks submitted in method execute(java.lang.Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. In either case, the execute method invokes the RejectedExecutionHandler.rejectedExecution(java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) method of its RejectedExecutionHandler. Four predefined handler policies are provided:

1. In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime RejectedExecutionException upon rejection.
2. In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself runs the task. This provides a simple feedback control mechanism that will slow down the rate that new tasks are submitted.
3. In ThreadPoolExecutor.DiscardPolicy, a task that cannot be executed is simply dropped.
4. In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down, the task at the head of the work queue is dropped, and then execution is retried (which can fail again, causing this to be repeated.)

It is possible to define and use other kinds of RejectedExecutionHandler classes. Doing so requires some care especially when policies are designed to work only under particular capacity or queuing policies.