The core parameters of ThreadPoolExecutor include corePoolSize, maximumPoolSize, keepAliveTime, workQueue and handler, which together determine the behavior of the thread pool. 1. corePoolSize specifies the number of core threads, and will not be recycled even if they are idle (unless allowCoreThreadTimeOut is enabled); 2. maximumPoolSize defines the maximum number of threads and controls the upper limit of the thread pool; 3. keepAliveTime sets the idle timeout time of non-core threads; 4. workQueue determines the task's queuing strategy, such as using the bounded queue ArrayBlockingQueue to prevent resource exhaustion; 5. handler is used to deal with rejection policies when new tasks cannot be accepted, and CallerRunsPolicy is recommended to implement the backpressure mechanism. Setting these parameters reasonably and understanding their impact will help avoid memory overflow, improve system stability, and ensure the completion of tasks through shutdown() and awaitTermination when the application is closed, thus giving full play to the value of the thread pool.

Java's thread pool executor (ThreadPoolExecutor) is one of the core components in concurrent programming. It can significantly improve program performance when used properly. But many people just know that Executors tool class can quickly create several common thread pools, but ignore the flexibility and control capabilities provided by ThreadPoolExecutor itself.

Understand the core parameters, don't rely solely on the default values

The constructor of ThreadPoolExecutor has seven parameters, the most critical of which are the following:

• corePoolSize : Number of core threads, which will not time out even if it is idle (unless allowCoreThreadTimeOut is set)
• maximumPoolSize : maximum number of threads, maximum number of threads, maximum number of threads for thread pool
• keepAliveTime : How long will non-core threads be recycled after they are idle?
• workQueue : task queue, used to store tasks waiting for execution
• handler : reject policy, how to handle when a task cannot be submitted

For example: If you set corePoolSize to 5, maximumPoolSize to 10, and workQueue capacity is 100, then the first 100 tasks will be queued and threads exceeding corePoolSize will not be created immediately. You will not consider creating a new thread until the queue is full, until maximumPoolSize is reached.

Many newbies use Executors.newFixedThreadPool(10) directly, which looks OK, but its queue is an unbounded queue, which may cause memory overflow. If you use ThreadPoolExecutor yourself, you can control these behaviors more carefully.

Task queue selection, key points that affect thread pool behavior

The selection of the task queue directly affects how the thread pool schedules tasks. Commonly used queues include:

• LinkedBlockingQueue : Default unbounded, suitable for most scenarios, but may hide the problem of resource exhaustion
• ArrayBlockingQueue : Bounded queues can better control resource caps and avoid system overload
• SynchronousQueue : No elements are stored, each insertion operation must wait until another thread is fetched, suitable for high concurrency and low latency scenarios.
• PriorityBlockingQueue : a task queue sorted by priority, suitable for scenarios where task order needs to be dynamically adjusted

It is recommended to select the appropriate queue type based on the actual load. For example, when processing requests in a web server, using bounded queues and appropriate rejection policies (such as CallerRunsPolicy) can allow the calling thread to handle tasks by itself when there is a high pressure, which can play a current limiting role.

Rejection strategies are not decorations, they must work at critical moments

When the thread pool and task queue are full, new tasks need to be dealt with through rejection policies. JDK has four built-in strategies:

• AbortPolicy : Throw an exception, default behavior
• CallerRunsPolicy : The calling thread executes the task itself
• DiscardPolicy : Silently discard tasks
• DiscardOldestPolicy : discard the oldest task in the queue and try to resubmit the current task

In practical applications, the most recommended is CallerRunsPolicy because it can slow down the task submission speed and form a "backpression" mechanism instead of simply discarding or throwing exceptions.

Of course, you can also customize the Handler, record logs, alarms or do other processing.

Thread pool lifecycle management, don't forget to close

Many people just ignore the thread pool after writing it, but in fact the thread pool also needs to be properly closed. There are two main methods:

• shutdown() : No new tasks are accepted, but will wait for the submitted tasks to be completed
• shutdownNow() : Try to interrupt all executing tasks and return the list of tasks waiting to be executed

It is recommended to call shutdown() when the application is closed, and wait with awaitTermination to ensure that the task is completed:

 executor.shutdown();
try {
    if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {
        executor.shutdownNow();
    }
} catch (InterruptedException e) {
    executor.shutdownNow();
}

This can prevent tasks from being forced to be interrupted and ensure data consistency.

Basically that's it. ThreadPoolExecutor is powerful, but it is also easy to misuse. Only by understanding the role of each parameter and the mechanism behind it can it truly exert its value.

The above is the detailed content of Deep Dive into Java Thread Pool Executors. For more information, please follow other related articles on the PHP Chinese website!