Differences

This shows you the differences between two versions of the page.

--- java:threadpoolexecutor [2025/02/22 08:02] – carl
+++ java:threadpoolexecutor [2026/08/28 16:48] (current) – carl
@@ Line 34: / Line 34: @@
+====== ScheduledThreadPoolExecutor ======
+This class is similar to ThreadPoolExecutor, but doesn't allow you to change the task queue.  The task queue is a priority queue, sorted on the task deadline.
+=== Living without a Queue ===
+A consequence of not being able to bound the queue is that the thread count is more important:
+  * You cannot have a cached ScheduledThreadPoolExecutor.  ThreadPoolExecutor will not create a thread if submission to the task queue succeeds.  Since submission always succeeds, no threads will be created.
+  * As mentioned in the javadocs, a core pool size of 0 is practically useless, since no threads will be alive to process the task.
+  * If all the threads in the ScheduledThreadPoolExecutor are busy (e.g. blocking), no new tasks can be executed.  This is important for periodically running tasks, such as those submitted with ''scheduleAtFixedRate()'' and ''scheduleWithFixedDelay()''.  These tasks will not be run in a timely manner.
+==== Experience using ThreadPoolExecutor ====
+/26/26
+I ran into an issue with our code.  We tried to limit the number of threads doing work, so they acquired a semaphore, and released it later.  All threads in our threadpool (minus like 2) were blocked waiting on the semaphore.   The threads that did win the semaphore needed like 5 more to do their work, but none were available, resulting in a deadlock.
+Replacing the Semaphore with an explicit queue only kinda worked, because a later bottle neck came up.  The threads that were trying to queue the work did, got back the future from their work, and then blocked on that, consuming the thread again.