I do not understand this ThreadPoolExecutor behavior

I have a ThreadPoolExecutor that is constructed with an unbounded queue (LinkedBlockingQueue) and a core and max pool size set to the number of cpus (say 4).

Every great while I get a RejectedExecutionException. The Executor is in a running state. My understanding is this should not happen with an unbounded queue.

I haven't been able to catch this in a debugger to see exactly what is 开发者_如何学Gohappening, but from the stack trace it looks like in ThreadPoolExecutor.execute, workQueue.offer is returning false, so it jumps to the bit where it tries to spin up a new thread. But poolSize is already at max, so it throws the rejected execution exception.

I don't quite understand this.

But regardless, should I make the max pool size a bit bigger than the core pool size?

---

LinkedBlockingQueue.offer() returns false when it is at its capacity. If the capacity is not specified, then Integer.MAX_VALUE is used.

Does this happen when adding 2147483647 more tasks than your pool size?

---

1. Even an "unbounded" LinkedBlockingQueue is actually bounded at Integer.MAX_VALUE. Yes, it's improbable that you're hitting that limit, but "once you eliminate the impossible...".
2. How certain are you that the executor is still in RUNNING state? In my source code, the check for state and the offer() call are both on the same line, so you wouldn't be able to distinguish them in a stack trace.