Configuration of the Java thread pool

1. Important parameters of Threadpoolexecutor

 1、Corepoolsize: Number of core threads * Core threads are always alive, no tasks needed to execute in time * When the number of threads is less than the number of core threads, the thread pool prioritizes the creation of new threading even when the thread is idle * Set upAllowcorethreadtimeout=True(DefaultFalse), the core thread times out and shuts down 2、Queuecapacity: Task queue capacity (blocking queue) * When the maximum number of core threads is reached, new tasks are queued for execution 3、Maxpoolsize: Maximum number of threads * When the number of threads >=Corepoolsize, and the task queue is full. Line pool Create a new thread to process the task * When the number of threads =Maxpoolsize, and when the task queue is full, the thread pool rejects processing the task and throws an exception 4、KeepAliveTime: Thread Idle Time * When thread idle time reachesKeepAliveTime, the thread exits until the number of threads =Corepoolsize* IfAllowcorethreadtimeout=True, it will be until the number of threads =0 5、Allowcorethreadtimeout: Allow core threads to time out 6、Rejectedexecutionhandler: Task Reject Processor * The processing of the task is rejected in two cases: - When the number of threads has reachedMaxpoolsize, the cut queue is full and new tasks are rejected - When the thread pool is calledShutdown() will wait for the line constructor task to complete, and thenShutdown。 If you call theShutdown() and thread pool reallyShutdownSubmit a task between, will reject the new task * The thread pool will callRejectedexecutionhandlerTo handle this task. If not set by default YesAbortPolicy, an exception is thrown * threadpoolexecutor -< Span class= "PLN" > abortpolicy  Discard task, throw runtime exception  - callerrunspolicy  Perform tasks  - discardpolicy Span class= "pun" > ignore, nothing will happen  -  Discardoldestpolicy  Kick out of the queue the first task to enter the queue (last execution) *  implement rejectedexecutionhandler  interface, customizable processor               

2. Thread pool Queue Selection

Wordqueue task queue, which is used to transfer and block submitted tasks, that is, task queues are running threads, and task queues work according to Corepoolsize and Maximumpoolsize:

1. When the running thread is less than corepoolsize, line pool creates a new thread

2. When the task queue is not full when it is greater than corepoolsize, the entire task is jammed into the queue

3. New thread execution task is created when the task queue is larger than corepoolsize and is less than maximumpoolsize

4. When greater than maximumpoolsize, threads are processed according to handler policy

There are three modes of the task queue:

1. submit directly. The default option for the Task Force column is SynchronousQueue that it will submit the task directly to the thread without keeping them. Here, if there is no thread available to run the task immediately, attempting to join the task to the queue will fail, and a new thread will be constructed. This policy avoids locking when processing a set of requests that may have internal dependencies. Direct submissions typically require unbounded maximumpoolsizes to avoid rejecting newly submitted tasks. This policy allows the possibility of an increase in the number of lines that are allowed to continue when the command arrives in a row that exceeds the average that the queue can handle.

2. unbounded queues. using unbounded queues (for example, without a predefined capacity LinkedBlockingQueue ) will cause all corepoolsize threads to be busy waiting in the queue. This way, the created thread will not exceed corepoolsize. (therefore, the value of the maximumpoolsize is not valid.) When each task is completely independent of other tasks, that is, when task execution does not affect each other, it is appropriate to use a unbounded queue, for example, in a Web page server. This queueing can be used to handle transient burst requests, which allow the possibility of an increase in the number of lines that are allowed to occur when the command reaches an average of more than the queue can handle.

3. Bounded queues. when using limited maximumpoolsizes, bounded queues (such as ArrayBlockingQueue ) help prevent resource exhaustion, but may be difficult to adjust and control. The queue size and maximum pool size may need to be compromised: using large queues and small pools minimizes CPU usage, operating system resources, and context switching overhead, but can result in artificially reduced throughput. If tasks are frequently blocked (for example, if they are I/O boundaries), the system may schedule more threads than you permit. Using small queues typically requires a large pool size, high CPU utilization, but may encounter unacceptable scheduling overhead, which also reduces throughput.

3. Saturation strategy of thread pool

1. In the default ThreadPoolExecutor.AbortPolicy , the handler is rejected and the runtime is thrown RejectedExecutionException .

2. In ThreadPoolExecutor.CallerRunsPolicy , the thread invokes the execute itself that runs the task. This strategy provides a simple feedback control mechanism that can slow down the submission of new tasks.

3. In ThreadPoolExecutor.DiscardPolicy , the task that cannot be performed will be deleted.

4. In ThreadPoolExecutor.DiscardOldestPolicy , if the execution program has not been closed, the task in the head of the work queue is deleted, and then the program is retried (repeat this process if it fails again).

It is also possible to define and use other kinds of RejectedExecutionHandler classes, but doing so requires great care, especially when the policy is used only for specific capacity or queueing policies.

 Public classTest { Public Static voidMain (string[] args)throwsinterruptedexception {//you can use different abort and queue policies to look at the effects of executionRejectedexecutionhandler handler =NewThreadpoolexecutor.discardoldestpolicy (); Threadpoolexecutor Executor=NewThreadpoolexecutor (1, 2,                200, Timeunit.milliseconds,NewLinkedblockingdeque<> (2), handler);  for(inti = 0; I < 30; i++) {MyTask MyTask=NewMyTask (i); Try{executor.execute (mytask); }Catch(rejectedexecutionexception e) {System.out.println ("Task" +i+ "abandoned"); } System.out.println (Number of threads in thread pool: "+ executor.getpoolsize () +", Number of tasks waiting to be executed in queue: "+executor.getqueue (). Size ()+ ", number of tasks performed:" +Executor.getcompletedtaskcount ()); }        //Thread.CurrentThread (). Sleep (400000);Executor.shutdown (); }}classMyTaskImplementsRunnable {Private intTasknum;  PublicMyTask (intnum) {         This. Tasknum =num; } @Override Public voidrun () {System.out.println ("Executing task" +tasknum); Try{Thread.CurrentThread (). Sleep (1000); } Catch(interruptedexception e) {e.printstacktrace (); } System.out.println ("Task" + Tasknum + "execution Complete"); }}

4. Thread pool Configuration Policy

Typically, this is a complex job.

1. According to the nature of the task set

To properly configure the thread pool, you must first analyze the task characteristics, which can be analyzed from the following angles:

1) Nature of tasks: CPU-intensive tasks, IO-intensive tasks, and hybrid tasks.

2) Priority of tasks: high, medium and low.

3) The execution time of the task: long, medium and short.

4) Dependency of the task: whether to rely on other system resources, such as database connections.

Tasks of a different nature can be handled separately by thread pools of different sizes. CPU-intensive tasks are configured with as small a thread as possible, such as configuring the number of CPUs + 1 threads for the thread pool. IO-intensive tasks Configure as many threads as possible, such as the number of 2*CPU, because the thread is not always performing the task. Mixed-type tasks, if they can be split into a CPU-intensive task and an IO-intensive task, as long as the time difference between the two tasks is not too large, then the throughput rate after decomposition is higher than the serial execution throughput rate, if the two task execution time is too large, it is not necessary to decompose. We can get the number of CPUs for the current device through the Runtime.getruntime (). Availableprocessors () method.

Tasks with different execution times can be handled by different sizes of thread pools, or priority queues can be used to perform tasks that have a short execution time.

A task that relies on the database connection pool, because the thread submits the SQL and waits for the database to return the results, and the longer the CPU idle time waits, the greater the number of threads should be, so that the CPU can be better utilized.

It is recommended to use bounded queue, the bounded queue can increase the stability and early warning ability of the system, can be set to a larger point, such as thousands of. When I was testing a thread pool, I used loops to constantly submit new tasks, resulting in a task backlog of online pools, and the program was constantly throwing out the exceptions that threw away the task. With unbounded queues, the thread pool queues are increasing, potentially filling up with memory, causing the entire system to become unusable, not just a background task problem.

This is usually a rough way to set up.

2. The law of Zermatt

The law of Little is that a system request equals the product of the requested arrival rate and the average time spent on each individual request

We can use the Little law to determine the thread pool size. We only need to calculate the request arrival rate and the average time of request processing. Then, by placing the above values in the law of Little, you can calculate the average number of requests for the system. If the number of requests is less than the size of our thread pool, the thread pool size is reduced accordingly. Conversely, if the number of requests is larger than the thread pool size, things are a little more complicated.

When there are more requests to be processed, we first need to assess whether the system has sufficient capacity to support a larger thread pool. The premise of an accurate assessment is that we must evaluate which resources will limit the scalability of the application. In this article, we will assume that it is CPU, and in practice it may be another resource. The simplest case is that we have enough space to increase the size of the thread pool. If not, you have to consider other options, such as software tuning, adding hardware, or tuning and adding hardware.

Specifically, we can refer to this article:

Http://www.infoq.com/cn/articles/Java-Thread-Pool-Performance-Tuning

3. configuration file Configuration

If it is a thread pool that is very important to system performance, it is better to open up its parameters than to guess the reasonable size of the thread pool. Because the thread pool's reasonable size and system resources are also closely related, assuming that your thread pool size on device A is already optimal, it's not always optimal to put the program on device B. In the configuration file, it can be easily adjusted according to the operation of the system in the future.

Let's look at what parameters the Open Source Task Scheduler Framework Quartz Open:

<!-- Thread executor configuration for task registration - <bean id= "executor" class= "Org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor" > <property name= "Corepoolsize" value= "6"/> <property name= "maxpoolsize" value= "/>" <property name= "queuecapacity" value= "/>" </bean>

Quart opens up three important parameters for the number of core threads, the maximum number of threads, and the capacity of the task queue, all of which are related to system resources.

4, the thread pool monitoring

Monitored by the parameters provided by the thread pool. Line constructor There are some properties that can be used when monitoring the thread pool:

Taskcount: The number of tasks that the thread pool needs to perform.

Completedtaskcount: The number of tasks that the thread pool has completed during the run. Less than or equal to Taskcount.

Largestpoolsize: The maximum number of threads that the thread pool has ever created. This data lets you know if the thread pool is full. Equal to the maximum size of the thread pool means that the thread pool was once full.

Getpoolsize: The number of threads in the thread pool. If the thread pool is not destroyed, the threads in the pool are not automatically destroyed, so this size increases by no more than + Getactivecount: Gets the number of active threads.

Monitor by extending the thread pool. By inheriting the thread pool and overriding the Beforeexecute,afterexecute and terminated methods of the thread pool, we can do something before the task executes and before the thread pool shuts down. such as the average execution time of the monitoring task, the maximum execution time and the minimum execution time.

Configuration of the Java thread pool