Carl's Hacking Notes

User Tools

Site Tools

Trace:
java:threadpoolexecutor

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
java:threadpoolexecutor [2025/02/23 02:40] – [ScheduledThreadPoolExecutor] carljava:threadpoolexecutor [2026/08/28 16:48] (current) – carl
Line 46: Line 46:
   * 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.   * 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 ====
 +
 +8/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.
java/threadpoolexecutor.txt · Last modified: by carl