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

This article will explain in detail what the CallerRunsPolicy rejection strategy of ThreadPoolExecutor is. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

First, let's introduce the construction method of ThreadPoolExecutor:

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

MaximumPoolSize .

MaximumPoolSize: maximum number of threads

WorkQueue: waiting queue. When a task is submitted, if the number of threads in the thread pool is greater than or equal to corePoolSize, the task is encapsulated as a Worker object and placed in the waiting queue.

KeepAliveTime: the thread pool maintains the idle time allowed by threads. When the number of threads in the thread pool is greater than corePoolSize, if no new task is submitted at this time, threads outside the core thread will not be destroyed immediately, but will wait until the waiting time exceeds keepAliveTime

ThreadFactory: this is a variable of type ThreadFactory that is used to create a new thread. Executors.defaultThreadFactory () is used by default to create threads. When you use the default ThreadFactory to create a thread, the newly created thread has the same NORM_PRIORITY priority and is not a daemon thread, and the name of the thread is also set.

Handler: this is a variable of type RejectedExecutionHandler that represents the saturation policy of the thread pool. If the blocking queue is full and there are no idle threads, if you continue to submit the task, you need to adopt a strategy to deal with the task. Thread pools provide four strategies:

AbortPolicy: throw an exception directly, which is the default policy

CallerRunsPolicy: use the caller's thread to execute the task

DiscardOldestPolicy: discards the first task in the blocking queue and executes the current task

DiscardPolicy: discarding tasks directly

To put it simply, if the state is always RUNNING when the execute () method is executed, the execution process is as follows:

If workerCount

= corePoolSize, and the blocking queue in the thread pool is not full, the task is added to the blocking queue

If workerCount > = corePoolSize & & workerCount

= maximumPoolSize, and the blocking queue in the thread pool is full, the task is processed according to the reject policy, and the default is to throw an exception directly.

Lab: reject Policy CallerRunsPolicy

Test what it is like to use the caller's thread to execute the task when the reject policy is CallerRunsPolicy.

Experimental environment

Jdk 1.8

Postman simulation concurrency

Mysql5.7

Intellj

Springboot 2.1.4.RELEASE

Experimental code

The code for this experiment is under the threadManagement directory under https://github.com/vincentduan/mavenProject.

Experimental procedure

1. First, configure the contents of the maven pom.xml file. The key contents are as follows:

Org.springframework.boot spring-boot-dependencies 2.1.4.RELEASE import pom org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-configuration-processor True mysql mysql-connector-java org.springframework.boot spring-boot-starter-jdbc com.alibaba druid 1.1.6 org.projectlombok lombok 1.18.6

two。 Configure database connection pooling:

@ SpringBootConfigurationpublic class DBConfiguration {@ Autowired private Environment environment; @ Bean public DataSource createDataSource () {DruidDataSource druidDataSource = new DruidDataSource (); druidDataSource.setUrl (environment.getProperty ("spring.datasource.url")); druidDataSource.setUsername (environment.getProperty ("spring.datasource.username")); druidDataSource.setPassword (environment.getProperty ("spring.datasource.password")); druidDataSource.setDriverClassName (environment.getProperty ("spring.datasource.driver-class-name")) Return druidDataSource;}}

3. Configure the thread pool:

@ Configuration@EnableAsync@Slf4jpublic class ExecutorConfig {@ Autowired VisiableThreadPoolTaskExecutor visiableThreadPoolTaskExecutor; @ Bean public Executor asyncServiceExecutor () {log.info ("start asyncServiceExecutor"); ThreadPoolTaskExecutor executor = visiableThreadPoolTaskExecutor; / / configure core threads executor.setCorePoolSize (5); / / configure maximum number of threads executor.setMaxPoolSize (5); / / configure queue size executor.setQueueCapacity (5) / / configure the name prefix executor.setThreadNamePrefix ("async-service-") of the thread in the thread pool; / / rejection-policy: how to handle the new task when the pool has reached max size / / CALLER_RUNS: instead of executing the task in the new thread, the caller's thread executes the executor.setRejectedExecutionHandler (new ThreadPoolExecutor.CallerRunsPolicy ()) / / perform initialization executor.initialize (); return executor;}}

The VisiableThreadPoolTaskExecutor class acts as a bean and inherits ThreadPoolTaskExecutor

4. Next, create a service, and to simulate concurrency, we sleep the method for 30 seconds. As follows:

@ Service@Slf4jpublic class UserThreadServiceImpl implements UserThreadService {@ Autowired UserThreadDao userThreadDao; @ Override @ Async ("asyncServiceExecutor") public void serviceTest (String username) {log.info ("enable execution of a Service with a Service execution time of 30s, threadId: {}", Thread.currentThread (). GetId ()); userThreadDao.add (username, Integer.parseInt (Thread.currentThread (). GetId () + ")," started ") Try {Thread.sleep (30000);} catch (InterruptedException e) {e.printStackTrace ();} log.info ("execute a Service, threadId: {}", Thread.currentThread (). GetId ()); userThreadDao.update (username, Integer.parseInt (Thread.currentThread (). GetId () + ")," ended ") @ Override public void update (String username, int threadId, String status) {userThreadDao.update (username, threadId, status);}}

5. Dao is very simple, which is to insert and update data into the database.

6. Create a web Controller:

@ RestController@RequestMapping ("/ serviceTest") public class TestController {@ Autowired UserThreadService userThreadService; @ Autowired private VisiableThreadPoolTaskExecutor visiableThreadPoolTaskExecutor; @ GetMapping ("test/ {username}") public Object test (@ PathVariable ("username") String username) {userThreadService.serviceTest (username); JSONObject jsonObject = new JSONObject (); ThreadPoolExecutor threadPoolExecutor = visiableThreadPoolTaskExecutor.getThreadPoolExecutor (); jsonObject.put ("ThreadNamePrefix", visiableThreadPoolTaskExecutor.getThreadNamePrefix ()) JsonObject.put ("TaskCount", threadPoolExecutor.getTaskCount ()); jsonObject.put ("completedTaskCount", threadPoolExecutor.getCompletedTaskCount ()); jsonObject.put ("activeCount", threadPoolExecutor.getActiveCount ()); jsonObject.put ("queueSize", threadPoolExecutor.getQueue (). Size ()); return jsonObject;}} execute the test

Because the number of CorePoolSize is 5 and MaxPoolSize is also 5, the size of the thread pool is fixed. And the number of QueueCapacity is also 5. So when the first five requests are made, the response is returned:

When the current number of threads reaches CorePoolSize, the new request will enter the workQueue, as shown below:

The number of QueueCapacity is also 5, so after reaching the maximum limit of QueueCapacity, it also reaches the maximum limit of MaxPoolSize, and the task will be handled according to the rejection policy. When the strategy here is CallerRunsPolicy, the caller's thread is used to execute the task, which shows that the current page is blocked until the current caller's thread finishes execution. As follows:

You can also see from the console output that the CallerRunsPolicy policy execution thread is the caller thread:

2019-08-19 21 c.a.i.s.impl.UserThreadServiceImpl 06 INFO 50.255 INFO 1302-[async-service-4] c.a.i.s.impl.UserThreadServiceImpl: enable execution of a Service, this Service execution time is 30s, threadId:512019-08-19 21 06c.a.i.s.impl.UserThreadServiceImpl 50.271 INFO 1302-[async-service-4] cn.ac.iie.dao.UserThreadDao: threadId:51 JdbcTemplate:org.springframework.jdbc.core.JdbcTemplate@5d83694c2019-08-19 21 async-service-5 06 async-service-5 50.751 INFO 1302-[async-service-5] c.a.i.s.impl.UserThreadServiceImpl: enable execution of a Service, this Service execution time is 30s, threadId:522019-08-19 21 06V 50.771 INFO 1302-[async-service-5] cn.ac.iie.dao.UserThreadDao: threadId:52 JdbcTemplate:org.springframework.jdbc.core.JdbcTemplate@5d83694c2019-08-19 21 nio-8080-exec-1 06jdbcTemplate:org.springframework.jdbc.core.JdbcTemplate@5d83694c2019 55.028 INFO 1302-[nio-8080-exec-1] c.a.i.s.impl.UserThreadServiceImpl: enable execution of a Service, this Service execution time is 30s, threadId:242019-08-19 21 06VOV 55.036 INFO 1302-[nio-8080-exec-1] cn.ac.iie.dao.UserThreadDao: threadId:24 JdbcTemplate:org.springframework.jdbc.core.JdbcTemplate@5d83694c

Where [nio-8080-exec-1] indicates that it is the caller's thread. While other threads are [async-service-]

So much for sharing what ThreadPoolExecutor's CallerRunsPolicy rejection strategy is. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.