Under what circumstances is thread pool technology suitable?

Thread Pool: processes a large number of connection requests per unit of time, but the processing time is relatively short. The main feature is to use and create technology to allocate the overhead of thread creation and destruction to a specific task. The more times a task is executed, the more time it will save. The other one is that the thread pool adopts an upper bound with the size of the thread pool created by the creation technology, which can solve the problem that some servers cannot create a certain number of threads at the same time. The thread pool abstracts tasks related to thread execution at a high-level level so that they are irrelevant to specific execution tasks. In addition, the thread pool is dynamically scalable. It can automatically adjust the number of threads in the thread pool according to the execution task severity .( BesidesWaitxxxYou can also manually suspend the startup thread for implementation, but this is more troublesome.,We thought we still need to set a management thread to listen to the occurrence of the event and then adjust the status of each thread in the thread pool. It is better to let the thread in the thread pool listen directly to wait for the arrival of the event and other objects.) If we need to deal with a long connection, that is, a connection is a task that has been executed for a long time, or even a task that does not stop, then we do not need to use the thread pool technology. Instead, you can simply adopt the "instant creation and immediate destruction" policy. This is what we are talking about. We need to design different solutions based on actual needs. Why thread pool? Currently, most network servers, including Web servers, email servers, and database servers, share the same thing: a large number of connection requests must be processed per unit time, but the processing time is relatively short. The server model we use in the traditional multithreading solution is to create a new thread for the thread to execute the task once the request is received. After the task is executed, the thread exits. This is the policy of "instant creation and destruction. Although the thread creation time has been greatly shortened compared with the creation process, if the task submitted to the thread is executed for a short time, and the execution times are extremely frequent, the server will not stop creating threads and destroy the State of the threads. We divide the thread Execution Process in the traditional solution into three processes: T1, T2, and T3. T1: thread creation time t2: thread execution time, including thread synchronization time t3: thread destruction time so we can see that the proportion of thread overhead is (t1 + T3) /(t1 + T2 + T3 ). If the thread execution time is short, the overhead may be about 20%-50%. If the task is executed frequently, this overhead cannot be ignored. In addition, the thread pool can reduce the number of created threads. Generally, the concurrent threads allowed by the thread pool have an upper bound. If the number of concurrent threads needs to exceed the upper bound, some threads will wait. In traditional cases, if the number of requests is 2000 at the same time, the system may need to generate 2000 threads in the worst case. Although this is not a large number, some machines cannot meet this requirement. Therefore, the appearance of the thread pool focuses on reducing the overhead brought by the thread pool itself. The thread pool adopts the pre-created technology and is used in applications. Program After startup, a certain number of threads (N1) will be created immediately and put into the idle queue. These threads are all in the congested State, which does not consume CPU, but takes up a small amount of memory space. When the task arrives, the buffer pool selects an idle thread to pass the task to this thread for running. When N1 threads are processing tasks, the buffer pool automatically creates a certain number of new threads for processing more tasks. After the task is executed, the thread does not exit, but continues to wait for the next task in the pool. When the system is idle, most threads remain in the paused state. The thread pool automatically destroys some threads and recycles system resources. Based on this pre-creation technology, the thread pool allocates the overhead of thread creation and destruction to specific tasks. The more execution times, the smaller the thread overhead shared by each task, but we may also need to consider the overhead of synchronization between threads.