Java thread pool principle and implementation method

Definition of thread pool

The thread pool is a form of multithreading that adds tasks to the queue during processing, and then automatically starts those tasks after the thread is created. Thread pool threads are background threads

Why use a thread pool

1. Reduce the time spent on creating and destroying threads and the overhead of system resources

2. Creating too many threads in one JVM can cause the system to run out of memory or "over-switch" due to excessive memory consumption. To prevent resource shortages, server applications need some way to limit the number of requests processed at any given moment.

Thread pool Component

1. Thread pool Manager (Threadpoolmanager): Used to create and manage thread pools, including creating a thread pool, destroying the thread pool, adding new tasks;

2, worker thread (poolworker): Thread pool threads, in the absence of a task in the waiting state, you can cycle the execution of tasks;

3, Task interface (tasks): Each task must be implemented by the interface for the task of scheduling the execution of tasks, it mainly specifies the entry of the task, the completion of the task after the end of the task, the implementation of the mission status, etc.;

4. Task Queue (Taskqueue): Used to hold tasks awaiting processing. Provides a buffering mechanism.

JDK comes with thread pool introduction (4 kinds)

1, Newfixedthreadpool Create a fixed-size thread pool. Whenever a task is committed to create a worker thread, until the thread reaches its maximum size, the size of the thread pool remains the same once the maximum is reached, and if a thread ends up executing an exception, the thread pool complements a new thread.

2, Newcachedthreadpool create a cacheable thread pool. This type of thread pool is characterized by:
1). There is almost no limit to the number of worker threads created (there are actually limits, and the number is Interger. Max_value), which gives you the flexibility to add threads to the thread pool. This thread pool does not limit the size of the thread pool, and the thread pool size is entirely dependent on the maximum thread size that the operating system (or JVM) can create.
2). If a task is not submitted to the thread pool for a long time, that worker thread will automatically terminate if the worker thread is idle for the specified time (by default, 60s). After termination, if you submit a new task again, the thread pool re-creates a worker thread.

3, Newsinglethreadexecutor create a single-threaded executor, that is, only create a unique worker thread to perform the task, if the thread unexpectedly ends, there will be another to replace it , to ensure that the order of execution. The most important feature of a single worker thread is that it is guaranteed to perform each task sequentially and that no multiple threads are active at any given time.

4, Newschedulethreadpool Create a fixed length (infinite size) of the thread pool, and support timed and periodic task execution, similar to the timer.

Some of the more important classes

The top interface of the thread pool in Java is executor, but strictly speaking, executor is not a thread pool, but a tool for executing threads. The real thread pool interface is Executorservice

Executorservice	A true thread pool interface.
Scheduledexecutorservice	can be similar to Timer/timertask to solve problems that require repetitive execution of tasks.
Threadpoolexecutor	The default implementation of Executorservice.
Scheduledthreadpoolexecutor	Inheriting Threadpoolexecutor's Scheduledexecutorservice interface implementation, the class implementation of periodic task scheduling.

To configure a thread pool is more complex, especially if the thread pool principle is not very clear, it is likely that the thread pool configured is not superior, so there are some static factories in the executors class that generate some common thread pools. As in the previous 4, they all pre-defined settings for most of the usage scenarios.

Risk of using the thread pool

Pool-related deadlocks, insufficient resources, concurrency errors, thread leaks

Dead lock

Any multithreaded application has a deadlock risk. When each of a set of processes or threads waits for an event that only another process in that group can cause, we say that the set of processes or threads is deadlocked . The simplest case of a deadlock is that thread A holds an exclusive lock on object X and waits for the lock of object Y, while thread B holds an exclusive lock on object Y, but waits for the lock of Object X. Unless there is some way to break the wait on the lock (Java lock does not support this method), the deadlock thread will wait forever.

Although there is a risk of deadlock in any multithreaded program, the thread pool introduces another deadlock possibility, in which case all pool threads are performing the task of executing the results of another task in the blocked wait queue, but the task cannot run because there are no unused threads. When the thread pool is used to simulate simulations involving many interactive objects, the simulated objects can send queries to each other, and the queries are then executed as queued tasks, and the query object synchronously waits for the response to occur.

Insufficient resources

One advantage of the thread pool is that they typically perform well relative to other alternative scheduling mechanisms (some we've already discussed). This is true only if the thread pool size is properly adjusted. Threads consume a large amount of resources, including memory and other system resources. In addition to Thread the memory required by the object, each thread requires two potentially large execution call stacks. In addition, the JVM may create a native thread for each Java thread that consumes additional system resources. Finally, although the scheduling overhead of switching between threads is small, environment switching can severely affect program performance if there are many threads.

If the thread pool is too large, the resources consumed by those threads can severely affect system performance. Switching between threads can be a waste of time, and using a thread that is more than you actually need may cause a resource scarcity problem because the pool thread is consuming some resources that might be more efficiently exploited by other tasks. In addition to the resources used by the thread itself, the work done by the service request may require additional resources, such as JDBC connections, sockets, or files. These are also limited resources, and too many concurrent requests can cause failures, such as the inability to allocate JDBC connections.

Concurrency errors

The thread pool and other queuing mechanisms rely on usage wait() and notify() methods, both of which are difficult to use. If the encoding is incorrect, you may lose the notification, causing the thread to remain idle, preferably using an existing implementation that already knows to work, such as a util.concurrent package.

Thread leaks

A serious risk in various types of thread pools is a thread leak, which occurs when a thread is removed from the pool to perform a task and the thread does not return the pool after the task has completed. One scenario in which a thread leak occurs occurs when a task throws one or the other RuntimeException Error . If the pool class does not snap to them, then the thread will only exit and the size of the thread pool will be permanently reduced by one. When this happens enough times, the thread pool is eventually empty and the system stops because there are no threads available to handle the task.

Some tasks may wait forever for certain resources or input from the user, and these resources are not guaranteed to become available, the user may have gone home, and such tasks will be permanently stopped, and these stopped tasks will cause the same problem as thread leaks. If a thread is permanently consumed by such a task, it is actually removed from the pool. For such tasks, you should either give them only their own threads, or just allow them to wait for a limited amount of time.

Request overload

This is possible only if the request is overwhelmed by the server. In this case, we may not want to queue every incoming request to our work queue, because the tasks queued for execution may consume too much system resources and cause resource shortages. Deciding what to do in this situation is up to you; In some cases, you can simply discard the request and rely on a higher level of protocol to retry the request later, or you can reject the request with a response that states that the server is temporarily busy.

Guidelines for effective use of thread pools

1. Do not queue up for tasks that synchronize the results of other tasks. This can lead to the type of deadlock described above, in which all threads are occupied by tasks that wait in turn for the results of the queued tasks that cannot be executed because all the threads are busy.

2. Be careful when using a shared thread for operations that can take a long time. If a program must wait for a resource such as I/O completion, specify the maximum wait time, and then either expire or re-queue the task for later execution. This ensures that some progress will eventually be made by releasing a thread to a task that might be successfully completed.

3, understanding the task. To effectively adjust the thread pool size, you need to understand which tasks are queued and what they are doing. Are they CPU-bound (cpu-bound)? Are they I/O-bound (i/o-bound)? Your answer will affect how you adjust your application. If you have different task classes with distinct characteristics, it might make sense to set up multiple work queues for different task classes so that each pool can be adjusted accordingly.

Reference from:

http://xtu-xiaoxin.iteye.com/blog/647580

http://blog.csdn.net/w2393040183/article/details/52177572

https://www.ibm.com/developerworks/cn/java/j-jtp0730/

Java thread pool principle and implementation method