Shulou(Shulou.com)06/02 Report--

This article mainly explains "how many threads should be set for java multithreading". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how many threads should be set for java multithreading.

When we use thread pools, there are two questions:

Setting too many threads in the thread pool will lead to fierce thread competition.

If the number of threads is set too little, the system will not be able to make full use of computer resources.

So how to set it without affecting system performance?

In fact, there is a way to set up the thread pool, not based on a simple estimate. Today, let's take a look at what calculation methods can be reused and what is the relationship between the parameters in the thread pool. Let's talk about this article slowly.

Thread pool principle

Before we start tuning, let's take a look at how thread pools are implemented, which will help you better understand what's going on.

In HotSpot VM's threading model, Java threads are mapped one-to-one to kernel threads. When Java uses a thread to execute a program, it needs to create a kernel thread; when the Java thread is terminated, the kernel thread is also recycled. Therefore, the creation and destruction of Java threads will consume some computer resources, thus increasing the performance overhead of the system.

In addition, a large number of creation threads will also bring performance problems to the system, because memory and CPU resources will be preempted by threads. If not handled properly, there will be memory overflow, CPU utilization overload and other problems.

To solve the above two kinds of problems, Java provides the concept of thread pool. For business scenarios where threads are created frequently, thread pools can create a fixed number of threads, and at the bottom of the operating system, lightweight processes will map these threads to the kernel.

Thread pools can improve thread reuse and fix the maximum thread usage to prevent unlimited thread creation.

When a program needs a thread to submit a task, it will go to the thread pool to find out if there are any idle threads. If so, it will directly use the threads in the thread pool to work. If not, it will determine whether the number of threads currently created exceeds the maximum number of threads. If not, create new threads. If so, queue up or throw an exception.

Thread Pool Framework Executor

Java initially provided ThreadPool to implement thread pool. In order to better achieve user-level thread scheduling and more effectively help developers to carry out multithreaded development, Java provides a set of Executor framework.

This framework includes two core thread pools, ScheduledThreadPoolExecutor and ThreadPoolExecutor. The former is used to perform tasks on a regular basis, while the latter is used to perform submitted tasks.

Since the core principles of the two thread pools are the same, let's focus on how the ThreadPoolExecutor class implements thread pooling.

Executors implements the following four types of ThreadPoolExecutor:

Executors uses the factory pattern to implement four thread pools, which we need to combine with the actual scenario in the production environment.

However, I do not recommend them, because choosing to use the factory class provided by Executors will ignore the parameter settings of many thread pools. Once the factory class chooses to set the default parameters, it is easy to fail to tune the parameter settings, resulting in performance problems or waste of resources.

I recommend that you use ThreadPoolExecutor to customize a set of thread pools (it is also recommended in the Ali specification not to use Executors to create thread pools, but to use ThreadPoolExecutor to create thread pools).

After entering the four factory classes, we can find that all the other classes except the newScheduledThreadPool class are implemented using the ThreadPoolExecutor class.

You can simply take a look at this method through the following code

CorePoolSize: the number of core threads in the thread pool

MaximumPoolSize: the maximum number of threads in the thread pool

KeepAliveTime: the maximum time for excess idle threads to survive when the number of threads is greater than the number of core threads

Unit: unit of time

WorkQueue: task queue, which is used to store queues waiting for tasks to be executed

ThreadFactory: thread factory, which is used to create threads. It is generally available by default.

Handler: reject policy. When too many tasks are submitted and cannot be processed in time, we can customize the policy to handle the task.

We can also use the following diagram to understand the relationship between the parameters in the downthread pool:

From the figure above, we find that the thread pool has two thread settings, one is the number of core threads, and the other is the maximum number of threads. After the thread pool is created, by default, there are no threads in the thread pool and wait until there is a task to create a thread to execute the task.

One exception, however, is that if you call the prestartAllCoreThreads () or prestartCoreThread () method, you can create a number of threads equal to the number of core threads in advance, which is called prefetch and is often used in panic buying systems.

When the number of threads created is equal to corePoolSize, the submitted tasks are added to the set blocking queue. When the queue is full, threads are created to execute the task until the number in the thread pool is equal to maximumPoolSize.

When the number of threads is equal to maximumPoolSize, the newly submitted task cannot be added to the waiting queue, nor can we create a non-core thread for direct execution, and we have not set a rejection policy for the thread pool. In this case, the thread pool will throw a RejectedExecutionException exception, that is, the thread pool refuses to accept the task.

When the number of threads created in the thread pool exceeds the set corePoolSize, after some thread has finished processing the task, if there is still no new task assigned to it after waiting for keepAliveTime time, then the thread will be reclaimed. When the thread pool reclaims threads, the so-called "core threads" and "non-core threads" are treated equally, and the recycling process does not stop until the number of threads in the thread pool is equal to the set corePoolSize parameter.

Even for corePoolSize threads, in some non-core business thread pools, if the number of threads is occupied for a long time, it may affect the core business thread pool, so it is necessary to recycle the threads that have not been assigned tasks.

We can request the thread pool through the allowCoreThreadTimeOut setting item: all threads that have no task assignment, including the "core thread", will be recycled after waiting for keepAliveTime time.

We can use the following figure to understand the thread allocation process of the downthread pool:

Calculate the number of threads

After understanding the implementation principle and framework of thread pool, we can practice optimizing the setting of thread pool.

We know that the environment is changeable, and it is not possible to set an absolutely accurate number of threads, but we can calculate a reasonable number of threads through some practical factors to avoid performance problems caused by unreasonable thread pool settings. Let's take a look at the specific calculation method.

General multithreaded task types can be divided into CPU-intensive and Imax O-intensive. According to different task types, we have different methods to calculate the number of threads.

CPU intensive task

This kind of task mainly consumes CPU resources, and the number of threads can be set to N (number of CPU cores) + 1. A thread with more than the number of CPU cores is to prevent occasional page-missing interruptions from threads, or the impact of task pauses caused by other reasons.

Once the task is paused, the CPU is idle, and an extra thread in this case can make full use of the idle time of the CPU.

Let's use an example to verify the feasibility of this method. You can get the results by observing the performance of CPU-intensive tasks under different threads. You can click Github to run the test locally:

Public class CPUTypeTest implements Runnable {/ / overall execution time, including waiting time in queue List wholeTimeList; / / actual execution time List runTimeList; private long initStartTime = 0 / * Constructor * @ param runTimeList * @ param wholeTimeList * / public CPUTypeTest (List runTimeList, List wholeTimeList) {initStartTime = System.currentTimeMillis (); this.runTimeList = runTimeList; this.wholeTimeList = wholeTimeList } / * judge primes * @ param number * @ return * / public boolean isPrime (final int number) {if (number)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.