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

This article introduces the knowledge of "Why disable Executors to create thread pool". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Definition of thread pool

Manage a set of worker threads. Reusing threads through the thread pool has the following advantages:

Reduce resource creation = > reduce memory overhead, create threads to occupy memory

Reduce system overhead = > it takes time to create threads and delays requests that are processed

Improve stability and stability = > avoid OutOfMemoryError caused by unlimited creation threads [OOM]

The way Executors creates a thread pool

Creating thread pools based on the type of object returned can be divided into three categories:

Create a return ThreadPoolExecutor object

Create a return ScheduleThreadPoolExecutor object

Create a return ForkJoinPool object

This article only discusses creating a ThreadPoolExecutor object that returns

ThreadPoolExecutor object

Let's introduce ThreadPoolExecutor before we introduce Executors's method of creating a thread pool, because these static methods of creating a thread pool return a ThreadPoolExecutor object, and the difference from manually creating a ThreadPoolExecutor object is that we don't need to pass the parameters of the constructor ourselves.

There are four constructors for ThreadPoolExecutor, but they all end up calling the same one:

Public ThreadPoolExecutor (int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)

Constructor argument description:

CorePoolSize = > number of core threads in the thread pool

MaximumPoolSize = > maximum number of thread pools

KeepAliveTime = > idle thread survival time

Unit = > time unit

WorkQueue = > buffer queues used by the thread pool

ThreadFactory = > Thread Pool creates factories used by threads

Handler = > Thread pool's strategy for rejecting tasks

The relationship between thread pool execution task logic and thread pool parameters

Execution logic description:

Determine whether the number of core threads is full, and the number of core threads is related to the corePoolSize parameter. If not, create a thread to execute the task.

If the core thread pool is full, determine whether the queue is full. Whether the queue is full is related to the workQueue parameter. If not, join the queue.

If the queue is full, determine whether the thread pool is full, and whether the thread pool is full is related to the maximumPoolSize parameter. If not, the created thread executes the task.

If the thread pool is full, the reject policy is used to deal with the tasks that cannot be executed. The reject policy is related to the handler parameter.

Executors creation returns ThreadPoolExecutor object

There are three ways for Executors to create a return ThreadPoolExecutor object:

Executors#newCachedThreadPool = > create cacheable thread pool

Executors#newSingleThreadExecutor = > create a single threaded thread pool

Executors#newFixedThreadPool = > create a fixed-length thread pool

Executors#newCachedThreadPool method

Public static ExecutorService newCachedThreadPool () {return new ThreadPoolExecutor (0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue ());}

CachedThreadPool is a thread pool that creates new threads as needed.

CorePoolSize = > 0, the number of core thread pools is 0

MaximumPoolSize = > Integer.MAX_VALUE, the maximum number of threads can be considered unlimited

KeepAliveTime = > 60L

Unit = > seconds

WorkQueue = > SynchronousQueue

When a task is submitted, corePoolSize does not create core threads for 0. SynchronousQueue is a queue that does not store elements, which can be understood to mean that the queue is always full, so non-core threads are eventually created to execute the task.

For non-core threads that are idle for 60 seconds, it will be recycled. Because Integer.MAX_VALUE is very large, it can be considered that threads can be created indefinitely, and it is easy to cause OOM exceptions in the case of limited resources.

Executors#newSingleThreadExecutor method

Public static ExecutorService newSingleThreadExecutor () {return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor (1,1,0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue ();}

SingleThreadExecutor is a single-thread thread pool with only one core thread

CorePoolSize = > 1, the number of core thread pools is 1

MaximumPoolSize = > 1, only one non-core thread can be created

KeepAliveTime = > 0L

Unit = > seconds

WorkQueue = > LinkedBlockingQueue

When a task is submitted, it will first create a core thread to execute the task. If it exceeds the number of core threads, it will be placed in the queue. Because LinkedBlockingQueue is a queue of length Integer.MAX_VALUE, it can be considered as an unbounded queue, so an unlimited number of tasks can be inserted into the queue, which can easily cause OOM exceptions when resources are limited. At the same time, because of the unbounded queue, the maximumPoolSize and keepAliveTime parameters will be invalid. Non-core threads will not be created at all

Executors#newFixedThreadPool method

Public static ExecutorService newFixedThreadPool (int nThreads) {return new ThreadPoolExecutor (nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue ());}

FixedThreadPool is a thread pool for fixed core threads, and the number of fixed core threads is passed in by the user.

CorePoolSize = > 1, the number of core thread pools is 1

MaximumPoolSize = > 1, only one non-core thread can be created

KeepAliveTime = > 0L

Unit = > seconds

WorkQueue = > LinkedBlockingQueue

It is similar to SingleThreadExecutor, except that the number of core threads is different, and because it uses LinkedBlockingQueue, it is easy to cause OOM exceptions when resources are limited.

Summary:

FixedThreadPool and SingleThreadExecutor = > the allowed request queue length is Integer.MAX_VALUE, which may pile up a large number of requests, resulting in an OOM exception

CachedThreadPool = > the number of threads allowed to be created is Integer.MAX_VALUE, which may create a large number of threads and cause OOM exceptions

This is why it is forbidden to use Executors to create thread pools, but it is recommended to create ThreadPoolExecutor yourself.

OOM exception test

In theory, there will be an OOM exception, and you have to test a wave of previous claims:

Test class: TaskTest.java

Public class TaskTest {public static void main (String [] args) {ExecutorService es = Executors.newCachedThreadPool (); int I = 0; while (true) {es.submit (new Task (iTunes +));}

Add threads indefinitely to the thread pool using the CachedThreadPool created by Executors

Before starting the test class, adjust the JVM memory smaller, otherwise it is easy to run the computer out of the problem, in idea: Run-> Edit Configurations

JVM parameter description:

-Xms10M = > Java Heap memory initialization value

-Xmx10M = > Java Heap memory maximum

Running result:

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" Disconnected from the target VM, address: '127.0.0.1 Disconnected from the target VM 60416, transport:' socket'

Start reporting OOM errors when creating more than 3w threads

The other two thread pools will not be tested, and the test methods are the same, but the thread pools created are different.

How to define thread pool parameters

CPU-intensive = > Thread pool size is recommended as the number of CPU + 1 number of CPU can be obtained according to the Runtime.availableProcessors method

IO-intensive = > number of CPU * CPU utilization * (1 + thread wait time / thread CPU time)

Mixed = > divide tasks into CPU-intensive and IO-intensive, and then use different thread pools to process them, so that each thread pool can be adjusted according to its own workload

Blocking queues = > bounded queues are recommended. Bounded queues help avoid resource exhaustion

Reject policy = > AbortPolicy reject policy is adopted by default, and RejectedExecutionException exception is thrown directly in the program (because it is a runtime exception, catch is not forced), which is not elegant. There are several comparative recommendations for handling rejection strategies:

Catch the RejectedExecutionException exception in the program, and handle the task in the catch exception. For the default deny policy

Using the CallerRunsPolicy reject policy, the task is handed over to the thread calling execute to execute [usually the main thread], where the main thread will not be able to submit any tasks for a period of time, causing the worker thread to process the executing task. At this point, the submitted thread will be saved in the TCP queue, and the full TCP queue will affect the client, which is a gentle performance degradation.

To customize the rejection policy, you only need to implement the RejectedExecutionHandler interface.

If the task is not particularly important, it is also possible to discard the task using DiscardPolicy and DiscardOldestPolicy reject policies

If you use Executors's static method to create a ThreadPoolExecutor object, you can use Semaphore to limit the flow of task execution and avoid OOM exceptions.

That's all for "Why disable Executors to create thread pools". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.