Executor Framework

Look at the numbers together: if active threads equal max and the queue keeps growing, the pool is saturated. If completed tasks stop increasing while threads stay busy, tasks are stalled (blocked). If the queue stays empty and threads are mostly idle, the pool isn't the problem.

newFixedThreadPool uses an unbounded LinkedBlockingQueue, so under overload the queue grows without limit and can run the JVM out of memory instead of rejecting work. A safer setup constructs a ThreadPoolExecutor directly with a bounded queue and an explicit rejection policy.

An unbounded queue stores unlimited waiting tasks, so the pool never grows past its core size and can run out of memory. A bounded queue limits waiting tasks and lets the pool add threads up to the max. A SynchronousQueue holds nothing, handing each task directly to a thread.

execute vs submit is a small local choice. What really controls behavior under load is the execution policy: how many threads, how big the queue, and what happens when both are full. The Executor interface hides that policy behind one method, so you can set it centrally — but it can't pick the right numbers for you or stop teams from sharing one pool unsafely.

Size the pool so concurrently-due tasks aren't starved: a single thread serializes everything, so one slow job delays the rest. ScheduledExecutorService gives relative, best-effort timing with no persistence, no cron expressions, and no clustering — for those you reach for Quartz, a cron service, or a distributed scheduler.

It depends on whether tasks mostly use the CPU or mostly wait (on I/O). CPU-bound work needs roughly as many threads as CPU cores; I/O-bound work can use many more because threads spend most of their time waiting. Always measure rather than guess.

Plain Future only lets you block on get() or poll isDone() — you can't attach a callback, chain steps, or combine several Futures without blocking a thread. CompletableFuture adds non-blocking composition and callbacks; structured concurrency manages a whole group of tasks with shared cancellation and scope.

Periodically read the pool's accessors (active, pool size, queue size, completed tasks) and publish them as metrics, e.g. register gauges with Micrometer or expose an MBean over JMX, so a system like Prometheus can scrape and graph them.

CallerRunsPolicy runs the rejected task on the submitting thread. If that thread is a critical or shared thread (like an event loop or another pool's worker), running long tasks there can stall the system or even deadlock. It also makes task latency unpredictable for the unlucky caller.