| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| java:threadpoolexecutor [2025/02/21 23:50] – add section on implementation carl | java:threadpoolexecutor [2025/02/22 18:40] (current) – [ScheduledThreadPoolExecutor] carl |
|---|
| |
| * In a **cached** ThreadPoolExecutor, the core pool size is 0 and the task queue is permanently empty. When a caller tries to submit a task, there is no space in the queue. This is due to the task queue being a `SynchronousQueue`, which requires a consuming thread to be listening on it. Because the caller cannot add the item to the queue, and because the core pool size is less than the max pool size, ThreadPoolExecutor spawns a new thread to handle the additional task. | * In a **cached** ThreadPoolExecutor, the core pool size is 0 and the task queue is permanently empty. When a caller tries to submit a task, there is no space in the queue. This is due to the task queue being a `SynchronousQueue`, which requires a consuming thread to be listening on it. Because the caller cannot add the item to the queue, and because the core pool size is less than the max pool size, ThreadPoolExecutor spawns a new thread to handle the additional task. |
| * In a **fixed** ThreadPoolExecutor, the core pool size is N where N was set at instantiation. When a caller tries to submit a task, the task is added to a (usually unbounded) task queue, and then consumed by one of the N thread later. | * In a **fixed** ThreadPoolExecutor, the core pool size is N where N was set at instantiation. When a caller tries to submit a task, the task is added to a (usually unbounded) task queue, and then consumed by one of the N threads later. |
| |
| |
| As we can see, the core pool size has an intricate inter play with the task queue. By constraining the task queue, we can make ThreadPoolExecutor spawn more threads, up to the maximum. By unbounding the task queue, we can limit the number of threads handling tasks. By default, a cached threadpool is both an unlimited number of thread, and a limited task queue. A fixed threadpool is an unlimitted number of tasks, and a limited thread pool. The constructor overloads of ThreadPoolExecutor let us customize this even more, but these are the most common cases. The behavior of the pool is a consequence of the task queue and thread spawning rules. | As we can see, the core pool size has an intricate interplay with the task queue. By constraining the task queue, we can make ThreadPoolExecutor spawn more threads, up to the maximum. By unbounding the task queue, we can limit the number of threads handling tasks. By default, a cached threadpool is both an unlimited number of thread, and a limited task queue. A fixed threadpool is an unlimitted number of tasks, and a limited thread pool. The constructor overloads of ThreadPoolExecutor let us customize this even more, but these are the most common cases. The behavior of the pool is a consequence of the task queue and thread spawning rules. |
| |
| |
| |
| | ====== 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. |
| |
