正确声明线程池#

线程池必须手动通过 ThreadPoolExecutor 的构造函数来声明，避免使用**Executors** 类创建线程池，会有 OOM 风险。

Executors 返回线程池对象的弊端如下：

• FixedThreadPool 和 SingleThreadExecutor：使用的是无界的 LinkedBlockingQueue，任务队列最大长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。
• CachedThreadPool：使用的是同步队列 SynchronousQueue, 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致 OOM。
• ScheduledThreadPool 和 SingleThreadScheduledExecutor : 使用的无界的延迟阻塞队列DelayedWorkQueue，任务队列最大长度为 Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。

说白了就是：使用有界队列，控制线程创建数量。

除了避免 OOM 的原因之外，不推荐使用 Executors提供的两种快捷的线程池的原因还有：

• 实际使用中需要根据自己机器的性能、业务场景来手动配置线程池的参数比如核心线程数、使用的任务队列、饱和策略等等。
• 我们应该显示地给我们的线程池命名，这样有助于我们定位问题。

监测线程池运行状态#

你可以通过一些手段来检测线程池的运行状态比如 SpringBoot 中的 Actuator 组件。

除此之外，还可以利用 ThreadPoolExecutor 的相关 API 做一个简陋的监控。ThreadPoolExecutor提供了获取线程池当前的线程数和活跃线程数、已经执行完成的任务数、正在排队中的任务数等等。

下面是一个简单的 Demo。printThreadPoolStatus()会每隔一秒打印出线程池的线程数、活跃线程数、完成的任务数、以及队列中的任务数。

1
/**
2
 * 打印线程池的状态
3
 *
4
 * @param threadPool 线程池对象
5
 */
6
public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) {
7
    ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false));
8
    scheduledExecutorService.scheduleAtFixedRate(() -> {
9
        log.info("=========================");
10
        log.info("ThreadPool Size: [{}]", threadPool.getPoolSize());
11
        log.info("Active Threads: {}", threadPool.getActiveCount());
12
        log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount());
13
        log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());
14
        log.info("=========================");
15
    }, 0, 1, TimeUnit.SECONDS);
16
}

建议不同类别的业务用不同的线程池#

很多人在实际项目中都会有类似这样的问题：我的项目中多个业务需要用到线程池，是为每个线程池都定义一个还是说定义一个公共的线程池呢？

一般建议是不同的业务使用不同的线程池，配置线程池的时候根据当前业务的情况对当前线程池进行配置，因为不同的业务的并发以及对资源的使用情况都不同，重心优化系统性能瓶颈相关的业务。

我们再来看一个真实的事故案例

上面的代码可能会存在死锁的情况，为什么呢？

试想这样一种极端情况：假如我们线程池的核心线程数为 n，父任务（扣费任务）数量为 n，父任务下面有两个子任务（扣费任务下的子任务），其中一个已经执行完成，另外一个被放在了任务队列中。由于父任务把线程池核心线程资源用完，所以子任务因为无法获取到线程资源无法正常执行，一直被阻塞在队列中。父任务等待子任务执行完成，而子任务等待父任务释放线程池资源，这也就造成了 “死锁” 。

解决方法也很简单，就是新增加一个用于执行子任务的线程池专门为其服务。

别忘记给线程池命名#

初始化线程池的时候需要显示命名（设置线程池名称前缀），有利于定位问题。

默认情况下创建的线程名字类似 pool-1-thread-n 这样的，没有业务含义，不利于我们定位问题。

给线程池里的线程命名通常有下面两种方式：

1. 利用 guava 的 ThreadFactoryBuilder

   1
   ThreadFactory threadFactory = new ThreadFactoryBuilder()
   2
                           .setNameFormat(threadNamePrefix + "-%d")
   3
                           .setDaemon(true).build();
   4
   ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory)

2. 自己实现 ThreadFactory****。

   1
   import java.util.concurrent.ThreadFactory;
   2
   import java.util.concurrent.atomic.AtomicInteger;
   3
   
   4
   /**
   5
    * 线程工厂，它设置线程名称，有利于我们定位问题。
   6
    */
   7
   public final class NamingThreadFactory implements ThreadFactory {
   8
   
   9
       private final AtomicInteger threadNum = new AtomicInteger();
   10
       private final String name;
   11
   
   12
       /**
   13
        * 创建一个带名字的线程池生产工厂
   14
        */
   15
       public NamingThreadFactory(String name) {
   16
           this.name = name;
   17
       }
   18
   
   19
       @Override
   20
       public Thread newThread(Runnable r) {
   21
           Thread t = new Thread(r);
   22
           t.setName(name + " [#" + threadNum.incrementAndGet() + "]");
   23
           return t;
   24
       }
   25
   }

正确配置线程池参数#

我们先来看一下各种书籍和博客上一般推荐的配置线程池参数的方式，可以作为参考。

别忘记关闭线程池#

当线程池不再需要使用时，应该显式地关闭线程池，释放线程资源。

线程池提供了两个关闭方法：

• shutdown（） :关闭线程池，线程池的状态变为 SHUTDOWN。线程池不再接受新任务了，但是队列里的任务得执行完毕。
• shutdownNow（） :关闭线程池，线程池的状态变为 STOP。线程池会终止当前正在运行的任务，停止处理排队的任务并返回正在等待执行的 List。

调用完 shutdownNow 和 shuwdown 方法后，并不代表线程池已经完成关闭操作，它只是异步的通知线程池进行关闭处理。如果要同步等待线程池彻底关闭后才继续往下执行，需要调用awaitTermination方法进行同步等待。

在调用 awaitTermination() 方法时，应该设置合理的超时时间，以避免程序长时间阻塞而导致性能问题。另外。由于线程池中的任务可能会被取消或抛出异常，因此在使用 awaitTermination() 方法时还需要进行异常处理。awaitTermination() 方法会抛出 InterruptedException 异常，需要捕获并处理该异常，以避免程序崩溃或者无法正常退出。

1
// ...
2
// 关闭线程池
3
executor.shutdown();
4
try {
5
    // 等待线程池关闭，最多等待5分钟
6
    if (!executor.awaitTermination(5, TimeUnit.MINUTES)) {
7
        // 如果等待超时，则打印日志
8
        System.err.println("线程池未能在5分钟内完全关闭");
9
    }
10
} catch (InterruptedException e) {
11
    // 异常处理
12
}

线程池尽量不要放耗时任务#

线程池本身的目的是为了提高任务执行效率，避免因频繁创建和销毁线程而带来的性能开销。如果将耗时任务提交到线程池中执行，可能会导致线程池中的线程被长时间占用，无法及时响应其他任务，甚至会导致线程池崩溃或者程序假死。

因此，在使用线程池时，我们应该尽量避免将耗时任务提交到线程池中执行。对于一些比较耗时的操作，如网络请求、文件读写等，可以采用异步操作的方式来处理，以避免阻塞线程池中的线程。

线程池使用的一些小坑#

1
@GetMapping("wrong")
2
public String wrong() throws InterruptedException {
3
    // 自定义线程池
4
    ThreadPoolExecutor executor = new ThreadPoolExecutor(5,10,1L,TimeUnit.SECONDS,new ArrayBlockingQueue<>(100),new ThreadPoolExecutor.CallerRunsPolicy());
5

6
    //  处理任务
7
    executor.execute(() -> {
8
      // ......
9
    }
10
    return "OK";
11
}

1
@Configuration
2
@EnableAsync
3
public class ThreadPoolExecutorConfig {
4

5
    @Bean(name="threadPoolExecutor")
6
    public Executor threadPoolExecutor(){
7
        ThreadPoolTaskExecutor threadPoolExecutor = new ThreadPoolTaskExecutor();
8
        int processNum = Runtime.getRuntime().availableProcessors(); // 返回可用处理器的Java虚拟机的数量
9
        int corePoolSize = (int) (processNum / (1 - 0.2));
10
        int maxPoolSize = (int) (processNum / (1 - 0.5));
11
        threadPoolExecutor.setCorePoolSize(corePoolSize); // 核心池大小
12
        threadPoolExecutor.setMaxPoolSize(maxPoolSize); // 最大线程数
13
        threadPoolExecutor.setQueueCapacity(maxPoolSize * 1000); // 队列程度
14
        threadPoolExecutor.setThreadPriority(Thread.MAX_PRIORITY);
15
        threadPoolExecutor.setDaemon(false);
16
        threadPoolExecutor.setKeepAliveSeconds(300);// 线程空闲时间
17
        threadPoolExecutor.setThreadNamePrefix("test-Executor-"); // 线程名字前缀
18
        return threadPoolExecutor;
19
    }
20
}

线程池和 ThreadLocal 共用的坑#

线程池和 ThreadLocal共用，可能会导致线程从ThreadLocal获取到的是旧值/脏数据。这是因为线程池会复用线程对象，与线程对象绑定的类的静态属性 ThreadLocal 变量也会被重用，这就导致一个线程可能获取到其他线程的ThreadLocal 值。

不要以为代码中没有显示使用线程池就不存在线程池了，像常用的 Web 服务器 Tomcat 处理任务为了提高并发量，就使用到了线程池，并且使用的是基于原生 Java 线程池改进完善得到的自定义线程池。

当然了，你可以将 Tomcat 设置为单线程处理任务。不过，这并不合适，会严重影响其处理任务的速度。

1
server.tomcat.max-threads=1

解决上述问题比较建议的办法是使用阿里巴巴开源的 TransmittableThreadLocal(TTL)。TransmittableThreadLocal类继承并加强了 JDK 内置的InheritableThreadLocal类，在使用线程池等会池化复用线程的执行组件情况下，提供ThreadLocal值的传递功能，解决异步执行时上下文传递的问题。

TransmittableThreadLocal 项目地址：https://github.com/alibaba/transmittable-thread-local 。

Correct declaration of thread pools#

Thread pools must be declared manually through ThreadPoolExecutor ‘s constructor; avoid using the Executors class to create thread pools, which can lead to OOM.

Executors returning thread pool objects has the following drawbacks:

• FixedThreadPool and SingleThreadExecutor: use an unbounded LinkedBlockingQueue; the task queue can reach a maximum length of Integer.MAX_VALUE, which may accumulate a large number of requests and lead to OOM.
• CachedThreadPool: uses the synchronous queue SynchronousQueue, allowing up to Integer.MAX_VALUE threads, which may create a large number of threads and cause OOM.
• ScheduledThreadPool and SingleThreadScheduledExecutor: use the unbounded delaying queue DelayedWorkQueue, the task queue maximum length is Integer.MAX_VALUE, which may accumulate a large number of requests and lead to OOM.

In short: use bounded queues and control the number of threads created.

Besides avoiding OOM, there are other reasons not to use the two quick-thread-pool options provided by Executors:

• In practice you need to manually configure thread pool parameters according to your machine’s performance and your business scenario, such as core pool size, the task queue to use, saturation policies, etc.
• We should explicitly name our thread pools, which helps us locate problems.

Monitoring thread pool status#

You can monitor the running state of a thread pool through various means, such as Spring Boot’s Actuator component.

In addition, you can use the APIs of ThreadPoolExecutor to build a simple monitor. ThreadPoolExecutor provides methods to obtain the current pool size, the number of active threads, the number of completed tasks, the number of tasks in the queue, and so on.

Here is a simple Demo. printThreadPoolStatus() prints the thread pool size, active count, completed task count, and the number of tasks in the queue every second.

1
/**
2
 * Print the status of a thread pool
3
 *
4
 * @param threadPool the thread pool object
5
 */
6
public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) {
7
    ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false));
8
    scheduledExecutorService.scheduleAtFixedRate(() -> {
9
        log.info("=========================");
10
        log.info("ThreadPool Size: [{}]", threadPool.getPoolSize());
11
        log.info("Active Threads: {}", threadPool.getActiveCount());
12
        log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount());
13
        log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());
14
        log.info("=========================");
15
    }, 0, 1, TimeUnit.SECONDS);
16
}

Use different thread pools for different types of work#

Many people encounter this question in real projects: My project has multiple business areas that require thread pools—should I define a separate pool for each area, or should I define a single shared pool?

The usual recommendation is to use different thread pools for different businesses, configuring each pool according to the current business scenario, because different businesses have different concurrency levels and resource usage, and the optimization should focus on the system’s bottlenecks.

Let’s look at a real incident case

The code above may have a deadlock situation. Why?

Imagine an extreme scenario: suppose the core pool size of our thread pool is n, the number of parent tasks (charge deduction tasks) is n, and under each parent task there are two sub-tasks (sub-tasks under the deduction task), one of which has already completed while the other is queued. Because the parent task has exhausted the core thread resources, the sub-task cannot obtain a thread resource and cannot proceed, so it remains blocked in the queue. The parent task waits for the sub-task to complete, while the sub-task waits for the parent task to release the thread pool resources, which leads to a “deadlock”.

The solution is simple: add a new thread pool dedicated to executing the sub-tasks.

Don’t forget to name your thread pools#

When initializing a thread pool, you should explicitly name it (set a thread pool name prefix); this helps with debugging.

By default, created thread names look like pool-1-thread-n, which lacks business meaning and makes it harder to locate problems.

There are usually two ways to name the threads in a thread pool:

1. Using Guava’s ThreadFactoryBuilder

1
ThreadFactory threadFactory = new ThreadFactoryBuilder()
2
                        .setNameFormat(threadNamePrefix + "-%d")
3
                        .setDaemon(true).build();
4
ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory)

2. Implementing your own ThreadFactory.

1
import java.util.concurrent.ThreadFactory;
2
import java.util.concurrent.atomic.AtomicInteger;
3

4
/**
5
 * Thread factory that sets thread names to help locate issues.
6
 */
7
public final class NamingThreadFactory implements ThreadFactory {
8

9
    private final AtomicInteger threadNum = new AtomicInteger();
10
    private final String name;
11

12
    /**
13
     * Create a thread factory with a name prefix.
14
     */
15
    public NamingThreadFactory(String name) {
16
        this.name = name;
17
    }
18

19
    @Override
20
    public Thread newThread(Runnable r) {
21
        Thread t = new Thread(r);
22
        t.setName(name + " [#" + threadNum.incrementAndGet() + "]");
23
        return t;
24
    }
25
}

Correctly configure thread pool parameters#

Let’s first review the common ways books and blogs recommend configuring thread pool parameters, which can serve as a reference.

Don’t forget to shut down thread pools#

When a thread pool is no longer needed, you should explicitly shut it down to release resources.

Thread pools offer two shutdown methods:

• shutdown(): shuts down the thread pool; its state becomes SHUTDOWN. It will not accept new tasks, but tasks in the queue will be completed.
• shutdownNow(): shuts down the thread pool; its state becomes STOP. It will attempt to stop currently executing tasks, halt processing of queued tasks, and return a list of tasks that are awaiting execution.

Calling shutdownNow and shutdown does not mean the shutdown is complete; it merely asynchronously requests the pool to stop. If you need to wait synchronously for the pool to fully shut down before proceeding, you should call awaitTermination to wait.

1
// ...
2
// Shutdown the thread pool
3
executor.shutdown();
4
try {
5
    // Wait for shutdown, up to 5 minutes
6
    if (!executor.awaitTermination(5, TimeUnit.MINUTES)) {
7
        // If waiting times out, log
8
        System.err.println("Thread pool did not terminate within 5 minutes");
9
    }
10
} catch (InterruptedException e) {
11
    // Exception handling
12
}

Try to avoid submitting long-running tasks to the thread pool#

The purpose of a thread pool is to improve task execution efficiency and avoid the overhead of repeatedly creating and destroying threads. If you submit long-running tasks to the pool, threads may be occupied for a long time, preventing timely responses to other tasks, and could even cause the pool to crash or the program to hang.

Therefore, when using a thread pool, try to avoid submitting time-consuming tasks to it. For long-running operations such as network requests or file I/O, consider asynchronous processing to avoid blocking threads in the pool.

Some gotchas when using thread pools#

1
@GetMapping("wrong")
2
public String wrong() throws InterruptedException {
3
    // Custom thread pool
4
    ThreadPoolExecutor executor = new ThreadPoolExecutor(5,10,1L,TimeUnit.SECONDS,new ArrayBlockingQueue<>(100),new ThreadPoolExecutor.CallerRunsPolicy());
5

6
    //  Process tasks
7
    executor.execute(() -> {
8
      // ......
9
    }
10
    return "OK";
11
}

1
@Configuration
2
@EnableAsync
3
public class ThreadPoolExecutorConfig {
4

5
    @Bean(name="threadPoolExecutor")
6
    public Executor threadPoolExecutor(){
7
        ThreadPoolTaskExecutor threadPoolExecutor = new ThreadPoolTaskExecutor();
8
        int processNum = Runtime.getRuntime().availableProcessors();
9
        int corePoolSize = (int) (processNum / (1 - 0.2));
10
        int maxPoolSize = (int) (processNum / (1 - 0.5));
11
        threadPoolExecutor.setCorePoolSize(corePoolSize);
12
        threadPoolExecutor.setMaxPoolSize(maxPoolSize);
13
        threadPoolExecutor.setQueueCapacity(maxPoolSize * 1000);
14
        threadPoolExecutor.setThreadPriority(Thread.MAX_PRIORITY);
15
        threadPoolExecutor.setDaemon(false);
16
        threadPoolExecutor.setKeepAliveSeconds(300);
17
        threadPoolExecutor.setThreadNamePrefix("test-Executor-");
18
        return threadPoolExecutor;
19
    }
20
}

Pitfalls where ThreadLocal and thread pools collide#

Using a thread pool with ThreadLocal can cause a thread to read stale or dirty values. This happens because the pool reuses worker threads, and the ThreadLocal variables bound to the thread’s class are reused as well, so a thread might read another thread’s ThreadLocal value.

Don’t assume that not explicitly using a thread pool in your code means there’s no thread pool involved; web servers like Tomcat use thread pools to handle requests and concurrency, often using custom thread pools built on top of native Java thread pools.

Of course, you could configure Tomcat to handle requests with a single thread, but this is not advisable as it would severely limit throughput.

1
server.tomcat.max-threads=1

A recommended solution to the above issue is Alibaba’s open-source TransmittableThreadLocal (TTL). The TransmittableThreadLocal class extends and enhances the JDK’s built-in InheritableThreadLocal. In components that pool and reuse threads, TTL provides propagation of ThreadLocal values to solve context transmission problems in asynchronous execution.

TransmittableThreadLocal project page: https://github.com/alibaba/transmittable-thread-local.

正しいスレッドプールの宣言#

スレッドプールは必ず手動で ThreadPoolExecutor **のコンストラクタを介して宣言する必要があります。Executors クラスを使ってスレッドプールを作成するのは避けてください。OOM のリスクがあります。

Executors が返すスレッドプールオブジェクトのデメリットは以下のとおりです：

• FixedThreadPool と SingleThreadExecutor：無界の LinkedBlockingQueue を使用しており、タスクキューの最大長は Integer.MAX_VALUE、大量のリクエストが蓄積されて OOM になる可能性があります。
• CachedThreadPool：SynchronousQueue を使用し、作成可能なスレッド数が Integer.MAX_VALUE で、大量のスレッドを作成して OOM になる可能性があります。
• ScheduledThreadPool と SingleThreadScheduledExecutor: 無界の遅延ブロックキュー DelayedWorkQueue を使用しており、タスクキューの最大長は Integer.MAX_VALUE、大量のリクエストが蓄積されて OOM になる可能性があります。

要するに：有界キューを使用して、スレッド作成数を制御する。

実際の OOM を避ける以外にも、Executors が提供する2つの快捷なスレッドプールを推奨しない理由は以下のとおりです：

• 実際の運用では、マシンの性能やビジネスシナリオに応じて、コアスレッド数、使用するタスクキュー、飽和時の策略などを手動で設定する必要があります。
• また、スレッドプールを命名することは重要です。名前を付けることで問題の特定が容易になります。

スレッドプールの実行状態の監視#

SpringBoot の Actuator など、スレッドプールの実行状態を検知する手段を利用できます。

それに加えて、ThreadPoolExecutor の関連 API を用いて簡易的な監視を行うことも可能です。ThreadPoolExecutor は現在のスレッド数やアクティブスレッド数、完了したタスク数、待機中のタスク数などを取得できます。

以下は簡易 Demo です。printThreadPoolStatus() は1秒ごとにスレッドプールの総数、アクティブなスレッド数、完了したタスク数、キュー内のタスク数を表示します。

1
/**
2
 * 打印线程池的状态
3
 *
4
 * @param threadPool 线程池对象
5
 */
6
public static void printThreadPoolStatus(ThreadPoolExecutor threadPool) {
7
    ScheduledExecutorService scheduledExecutorService = new ScheduledThreadPoolExecutor(1, createThreadFactory("print-images/thread-pool-status", false));
8
    scheduledExecutorService.scheduleAtFixedRate(() -> {
9
        log.info("=========================");
10
        log.info("ThreadPool Size: [{}]", threadPool.getPoolSize());
11
        log.info("Active Threads: {}", threadPool.getActiveCount());
12
        log.info("Number of Tasks : {}", threadPool.getCompletedTaskCount());
13
        log.info("Number of Tasks in Queue: {}", threadPool.getQueue().size());
14
        log.info("=========================");
15
    }, 0, 1, TimeUnit.SECONDS);
16
}

異なるカテゴリのビジネスには別々のスレッドプールを推奨#

多くの人が実務で以下のような問題に直面します：私のプロジェクトには複数のビジネスでスレッドプールを使う必要があります。各スレッドプールを定義すべきか、それとも共用のスレッドプールを使うべきか？

一般的には、異なるビジネスには別々のスレッドプールを使用し、現在のビジネスの状況に応じてそのスレッドプールを設定します。なぜなら、ビジネスごとに並行性やリソースの使用状況が異なるため、システムの性能ボトルネックに焦点を合わせたビジネスを最適化する必要があるからです。

実際の事故ケースを見てみましょう

上記のコードは死結が発生する可能性があります。なぜでしょうか？

極端なケースを想像してみましょう：スレッドプールのコアスレッド数を n、親タスク（課金タスク）の数を n、親タスクの下に2つのサブタスク（課金タスク下のサブタスク）があり、そのうち1つがすでに実行完了し、もう1つがタスクキューに入っています。親タスクがスレッドプールのコアスレッド資源を使い切っているため、子タスクはスレッド資源を取得できず正常に実行できず、キューで待機し続けます。親タスクは子タスクの実行完了を待ち、子タスクは親タスクがスレッドプール資源を開放するのを待つことになり、これが「デッドロック」を引き起こします。

解決方法は非常に単純で、子タスクを実行する専用の別のスレッドプールを新たに追加して、それを子タスク専用にします。

スレッドプールに名前を付けるのを忘れずに#

スレッドプールを初期化する際には明示的に名前を付ける（スレッドプール名のプレフィックスを設定する）と、問題の特定に役立ちます。

デフォルトで作成されるスレッド名は pool-1-thread-n のようなもので、業務の意味を持たず、問題の特定には不便です。

スレッドプール内のスレッドに名前を付けるには、通常次の2つの方法があります：

1. Guava の ThreadFactoryBuilder

   1
   ThreadFactory threadFactory = new ThreadFactoryBuilder()
   2
                           .setNameFormat(threadNamePrefix + "-%d")
   3
                           .setDaemon(true).build();
   4
   ExecutorService threadPool = new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, TimeUnit.MINUTES, workQueue, threadFactory)

2. 自分で実装する ThreadFactory。

   1
   import java.util.concurrent.ThreadFactory;
   2
   import java.util.concurrent.atomic.AtomicInteger;
   3
   
   4
   /**
   5
    * 线程工厂，它设置线程名称，有利于我们定位问题。
   6
    */
   7
   public final class NamingThreadFactory implements ThreadFactory {
   8
   
   9
       private final AtomicInteger threadNum = new AtomicInteger();
   10
       private final String name;
   11
   
   12
       /**
   13
        * 创建一个带名字的线程池生产工厂
   14
        */
   15
       public NamingThreadFactory(String name) {
   16
           this.name = name;
   17
       }
   18
   
   19
       @Override
   20
       public Thread newThread(Runnable r) {
   21
           Thread t = new Thread(r);
   22
           t.setName(name + " [#" + threadNum.incrementAndGet() + "]");
   23
           return t;
   24
       }
   25
   }

正しいスレッドプールのパラメータ設定#

まず、さまざまな書籍とブログで一般的に推奨されるスレッドプールのパラメータ設定方法を見てみましょう。参考として。

スレッドプールを閉じるのを忘れないでください#

スレッドプールが不要になったときには、明示的にスレッドプールを閉じ、スレッド資源を解放すべきです。

スレッドプールには2つのシャットダウン方法があります：

• shutdown(): スレッドプールをシャットダウンします。スレッドプールの状態は SHUTDOWN となり、新しいタスクは受け付けられなくなりますが、キュー内のタスクは完了します。
• shutdownNow(): スレッドプールを強制的にシャットダウンします。状態は STOP となり、現在実行中のタスクを強制終了し、待機中のタスクの処理を停止して、実行待ちの List を返します。

shutdownNow と shutdown を呼び出した後も、直ちにスレッドプールが完全に閉じるわけではなく、非同期で閉じ処理が通知されているだけです。完全に閉じるまで待つ必要がある場合は、awaitTermination を呼んで同期的に待機します。

1
// ...
2
// 关闭线程池
3
executor.shutdown();
4
try {
5
    // 等待线程池关闭，最多等待5分钟
6
    if (!executor.awaitTermination(5, TimeUnit.MINUTES)) {
7
        // 如果等待超时，则打印日志
8
        System.err.println("线程池未能在5分钟内完全关闭");
9
    }
10
} catch (InterruptedException e) {
11
    // 异常处理
12
}

スレッドプールには長時間実行タスクを入れない#

スレッドプール自体の目的は、タスクの実行効率を高めることと、頻繁なスレッド作成・破棄によるパフォーマンスコストを避けることです。長時間実行されるタスクをスレッドプールに投入すると、スレッドが長時間占有され、他のタスクへ迅速に応答できなくなり、最悪の場合スレッドプールが崩壊したり、プログラムがフリーズしたりする可能性があります。

したがって、スレッドプールを使う際には、長時間実行タスクをスレッドプールに投入することをできるだけ避けるべきです。ネットワーク要求、ファイルの読み書きなど、時間のかかる操作には非同期処理を用意して処理することで、スレッドプール内のスレッドのブロックを回避します。

スレッドプールの使用時の小さな落とし穴#

1
@GetMapping("wrong")
2
public String wrong() throws InterruptedException {
3
    // 自作のスレッドプール
4
    ThreadPoolExecutor executor = new ThreadPoolExecutor(5,10,1L,TimeUnit.SECONDS,new ArrayBlockingQueue<>(100),new ThreadPoolExecutor.CallerRunsPolicy());
5

6
    //  处理任务
7
    executor.execute(() -> {
8
      // ......
9
    }
10
    return "OK";
11
}

1
@Configuration
2
@EnableAsync
3
public class ThreadPoolExecutorConfig {
4

5
    @Bean(name="threadPoolExecutor")
6
    public Executor threadPoolExecutor(){
7
        ThreadPoolTaskExecutor threadPoolExecutor = new ThreadPoolTaskExecutor();
8
        int processNum = Runtime.getRuntime().availableProcessors(); // 利用可能なCPUコア数を返す
9
        int corePoolSize = (int) (processNum / (1 - 0.2));
10
        int maxPoolSize = (int) (processNum / (1 - 0.5));
11
        threadPoolExecutor.setCorePoolSize(corePoolSize); // コアプールサイズ
12
        threadPoolExecutor.setMaxPoolSize(maxPoolSize); // 最大スレッド数
13
        threadPoolExecutor.setQueueCapacity(maxPoolSize * 1000); // キューの容量
14
        threadPoolExecutor.setThreadPriority(Thread.MAX_PRIORITY);
15
        threadPoolExecutor.setDaemon(false);
16
        threadPoolExecutor.setKeepAliveSeconds(300);// スレッドのアイドル時間
17
        threadPoolExecutor.setThreadNamePrefix("test-Executor-"); // スレッド名のプレフィックス
18
        return threadPoolExecutor;
19
    }
20
}

スレッドプールと ThreadLocal の共用の落とし穴#

スレッドプールと ThreadLocal の共用は、スレッドプールがスレッドオブジェクトを再利用するため、スレッドオブジェクトに結びつくクラスの静的属性である ThreadLocal 変数も再利用され、別のスレッドの ThreadLocal 値を取得してしまう可能性があります。

コード上でスレッドプールを明示的に使用していないからといって、スレッドプールが存在しないわけではありません。例えば、一般的な Web サーバー Tomcat は高い同時処理を実現するためにスレッドプールを使用しており、原生 Java のスレッドプールを改善して得られた自作のスレッドプールを利用しています。

もちろん Tomcat を単一スレッドで処理するように設定することもできますが、それは適切ではなく、タスク処理速度に重大な影響を与えます。

1
server.tomcat.max-threads=1

この問題を解決するのに比較的推奨される方法は、Alibaba のオープンソースである TransmittableThreadLocal（TTL）を使用することです。TransmittableThreadLocal クラスは JDK 内蔵の InheritableThreadLocal を継承・拡張しており、スレッドプールなどのプーリング再利用されるスレッドを使用する場合に、ThreadLocal の値を伝搬させる機能を提供し、非同期実行時のコンテキスト伝搬の問題を解決します。

TransmittableThreadLocal プロジェクトのURL：https://github.com/alibaba/transmittable-thread-local。