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

スレッドプールは必ず手動で 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。