Detailed explanation of thread pool parameters

Reprinted from: http://blog.csdn.net/zhouhl_cn/article/details/7392607 and http://www.cnblogs.com/dolphin0520/p/3932921.html


The powerful concurrent package was introduced in JDK1.5, the most commonly used one is the thread pool implementation ThreadPoolExecutor, which brings us great convenience, but at the same time, inappropriate settings for the thread pool may also cause The efficiency does not achieve the desired effect, and even only equals or lowers the efficiency of a single thread.

The parameters that can be set by the ThreadPoolExecutor class are as follows:

  • corePoolSize

After the thread pool is created, by default, there are no threads in the thread pool, but wait for a task to arrive before creating a thread to execute the task, ( unless the prestartAllCoreThreads() or prestartCoreThread() method is called, from these two methods As can be seen from the name, it means pre-creating threads, that is, creating corePoolSize threads or a thread before no tasks arrive).

By default, after the thread pool is created, the number of threads in the thread pool is 0. When a task arrives, a thread will be created to execute the task. When the number of threads in the thread pool reaches corePoolSize, it will be sent to The tasks are placed in the cache queue. Core threads will timeout when allowCoreThreadTimeout is set to true, and will not exit by default.

  • maxPoolSize
When the number of threads is greater than or equal to core threads and the task queue is full, the thread pool will create new threads until the number of threads reaches maxPoolSize. If the number of threads is equal to maxPoolSize and the task queue is full, the processing capacity of the thread pool has been exceeded, and the thread pool will refuse to process the task and throw an exception.
  • keepAliveTime

When the thread idle time reaches keepAliveTime, the thread will exit until the number of threads equals corePoolSize. If allowCoreThreadTimeout is set to true, all threads will exit until the thread count reaches 0.

  • allowCoreThreadTimeout

Whether to allow core threads to exit idle, the default value is false.

  • queueCapacity

Task queue capacity. As can be seen from the description of maxPoolSize, the capacity of the task queue will affect the change of threads, so the length of the task queue also needs to be set appropriately.


There is also  workQueue : a blocking queue used to store tasks waiting to be executed. The choice of this parameter is also very important and will have a significant impact on the running process of the thread pool. Generally speaking, the blocking queue here has the following options:

ArrayBlockingQueue;
LinkedBlockingQueue;
SynchronousQueue;
PriorityBlockingQueue 
ArrayBlockingQueue and PriorityBlockingQueue are used less, and LinkedBlockingQueue and Synchronous are generally used. The queuing strategy of the thread pool is related to BlockingQueue.
  • threadFactory: thread factory, mainly used to create threads;
  • handler: Indicates the strategy when refusing to process a task, with the following four values:
ThreadPoolExecutor.AbortPolicy: Aborts the task and throws a RejectedExecutionException.
ThreadPoolExecutor.DiscardPolicy: also discards tasks, but does not throw exceptions.
ThreadPoolExecutor.DiscardOldestPolicy: Discard the task at the front of the queue and retry the task (repeat this process)
ThreadPoolExecutor.CallerRunsPolicy: The task is handled by the calling thread

The thread pool executes tasks with the following behavior

  1. Threads are created when the number of threads is less than the number of core threads.
  2. When the number of threads is greater than or equal to the number of core threads, and the task queue is not full, the task is put into the task queue.
  3. When the number of threads is greater than or equal to the number of core threads, and the task queue is full
    1. If the number of threads is less than the maximum number of threads, create a thread
    2. If the number of threads is equal to the maximum number of threads, an exception is thrown and the task is rejected

system load

The parameter setting is directly related to the system load. The following are the relevant parameters of the system load:

  • tasks, the maximum number of tasks to be processed per second
  • tasktime, the time required to process the first task
  • responsetime, the system allows the maximum response time of the task, for example, the response time of each task should not exceed 2 seconds.


parameter settings


corePoolSize:

Each task requires tasktime seconds to process, so each thread can process 1/tasktime tasks per note. If the system has tasks per second to be processed, the number of threads required is: tasks/(1/tasktime), that is, the number of tasks*tasktime threads. Assuming that the number of tasks per second in the system is 100~1000, and each task takes 0.1 second, 100*0.1 to 1000*0.1 is required, that is, 10~100 threads. Then corePoolSize should be set to be greater than 10. The specific number is best based on the 8020 principle, that is, the number of tasks per second in the system in 80% of the cases, if the number of tasks per second in 80% of the system is less than 200, and the maximum is 1000, then corePoolSize can be set is 20.


queueCapacity:

The length of the task queue depends on the number of core threads and the system's requirements for task response time. The queue length can be set to (corePoolSize/tasktime)*responsetime: (20/0.1)*2=400, that is, the queue length can be set to 400.

If the queue length is set too large, the task response time will be too long. Do not write the following:

LinkedBlockingQueue queue = new LinkedBlockingQueue();

This is actually setting the queue length to Integer.MAX_VALUE, which will cause the number of threads to always be corePoolSize and never increase again. When the number of tasks increases sharply, the task response time will also increase sharply.


maxPoolSize:

When the system load reaches the maximum value, the number of core threads can no longer process all tasks on time. At this time, it is necessary to increase the number of threads. 200 tasks per second require 20 threads, then when 1000 tasks per second are reached, (1000-queueCapacity)*(20/200) is required, that is, 60 threads, and maxPoolSize can be set to 60.


keepAliveTime:

The number of threads only increases and does not decrease. When the load decreases, the number of threads can be reduced, and if a thread idle time reaches keepAliveTiime, the thread exits. By default the thread pool will keep at least corePoolSize threads.


allowCoreThreadTimeout:

By default, the core thread will not exit, you can make the core thread exit by setting this parameter to true.


The above calculation of the number of threads does not take into account the CPU. If combined with the CPU situation, for example, when the number of threads reaches 50 and the CPU reaches 100%, it is not appropriate to set maxPoolSize to 60. At this time, if the system load is maintained at 1000 tasks per second for a long time, it will exceed the thread pool processing. capacity, should try to reduce the processing time of each task (tasktime).

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325564122&siteId=291194637