I.はじめに
最近、リファクタリングされた Dubbo サービスのスレッド プールが調整され、ワーカー スレッドが CachedThreadPool スレッド戦略を使用していましたが、オンラインになった後、スレッド プールが一気に増加し、オンライン事故を引き起こしそうになりました。
そこで、この記事ではスレッド プールの謎を明らかにします。
2. Dubbo スレッド プールの概要
Dubbo の CachedThreadPool ソース コード
package org.apache.dubbo.common.threadpool.support.cached;
import org.apache.dubbo.common.URL;
import org.apache.dubbo.common.threadlocal.NamedInternalThreadFactory;
import org.apache.dubbo.common.threadpool.ThreadPool;
import org.apache.dubbo.common.threadpool.support.AbortPolicyWithReport;
import java.util.concurrent.Executor;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.SynchronousQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import static org.apache.dubbo.common.constants.CommonConstants.ALIVE_KEY;
import static org.apache.dubbo.common.constants.CommonConstants.CORE_THREADS_KEY;
import static org.apache.dubbo.common.constants.CommonConstants.DEFAULT_ALIVE;
import static org.apache.dubbo.common.constants.CommonConstants.DEFAULT_CORE_THREADS;
import static org.apache.dubbo.common.constants.CommonConstants.DEFAULT_QUEUES;
import static org.apache.dubbo.common.constants.CommonConstants.DEFAULT_THREAD_NAME;
import static org.apache.dubbo.common.constants.CommonConstants.QUEUES_KEY;
import static org.apache.dubbo.common.constants.CommonConstants.THREADS_KEY;
import static org.apache.dubbo.common.constants.CommonConstants.THREAD_NAME_KEY;
/**
* This thread pool is self-tuned. Thread will be recycled after idle for one minute, and new thread will be created for
* the upcoming request.
*
* @see java.util.concurrent.Executors#newCachedThreadPool()
*/
public class CachedThreadPool implements ThreadPool {
@Override
public Executor getExecutor(URL url) {
//1 获取线程名称前缀 如果没有 默认是Dubbo
String name = url.getParameter(THREAD_NAME_KEY, DEFAULT_THREAD_NAME);
//2. 获取线程池核心线程数大小
int cores = url.getParameter(CORE_THREADS_KEY, DEFAULT_CORE_THREADS);
//3. 获取线程池最大线程数大小，默认整型最大值
int threads = url.getParameter(THREADS_KEY, Integer.MAX_VALUE);
//4. 获取线程池队列大小
int queues = url.getParameter(QUEUES_KEY, DEFAULT_QUEUES);
//5. 获取线程池多长时间被回收 单位毫秒
int alive = url.getParameter(ALIVE_KEY, DEFAULT_ALIVE);
//6. 使用JUC包里的ThreadPoolExecutor创建线程池
return new ThreadPoolExecutor(cores, threads, alive, TimeUnit.MILLISECONDS,
queues == 0 ? new SynchronousQueue<Runnable>() :
(queues < 0 ? new LinkedBlockingQueue<Runnable>()
: new LinkedBlockingQueue<Runnable>(queues)),
new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
}
}Dubbo は基本的に JUC パッケージの ThreadPoolExecutor を使用してスレッド プールを作成していることがわかります。ソース コードは次のとおりです。
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.acc = System.getSecurityManager() == null ?
null :
AccessController.getContext();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}一般的なフローチャートは次のとおりです。
1. スレッド プールが小さい場合corePoolSize、その時点でスレッド プールにアイドル状態のスレッドがあったとしても、新しいタスクは新しいスレッドを作成します。
2. スレッド プールに到達するとcorePoolSize、新しく送信されたタスクはキューに入れられworkQueue、スレッド プール タスクの実行がスケジュールされるのを待ちます。
3.workQueue満杯でmaximumPoolSize>の場合corePoolSize、新しいタスクはタスクを実行するための新しいスレッドを作成します。
4. 提出されたタスクの数が を超えた場合maximumPoolSize、新たに提出されたタスクはRejectedExecutionHandlerによって処理されます。
5. スレッド プールを超過した場合corePoolSize、keepAliveTimeまたはアイドル時間に達した場合、アイドル スレッドを閉じます。
さらに、 を設定するとallowCoreThreadTimeOut(true)、スレッド プール内のcorePoolSizeスレッドのアイドル時間keepAliveTimeも閉じられます。
RejectedExecutionHandler はデフォルトで 4 つの拒否戦略を提供します
1. AbortPolicy 戦略: この戦略は、システムが正常に動作しないように例外を直接スローします。
2. CallerRunsPolicy ポリシー: スレッド プール内のスレッド数が上限に達すると、このポリシーはタスクをタスク キューに入れて呼び出し側スレッドで実行します。
3. DiscardOledestPolicy ポリシー: このポリシーは、タスク キュー内の最も古いタスク、つまり、現在のタスク キューに最初に追加され、実行されようとしているタスクを破棄し、再送信を試みます。
4. DiscardPolicy ポリシー: このポリシーは、何も処理せずに処理できないタスクをサイレントに破棄します。もちろん、この戦略を使用する場合、ビジネス シナリオではタスクの損失を許容する必要があります。
Dubbo の拒否ポリシー AbortPolicyWithReport は実際には ThreadPoolExecutor.AbortPolicy ポリシーを継承し、主にいくつかのキー情報とスタック情報を出力することに注意してください。
3. スレッドプールの設定について
スレッド プールの設定は非常に重要ですが、見落とされがちであり、設定が不合理であったり、スレッド プールの再利用数が少ないと、依然としてアカウントの作成とキャンセルが頻繁に行われます。
コアスレッドの数を合理的に計算するにはどうすればよいですか?
インターフェイスの平均応答時間と、サービスがサポートする必要がある QPS から計算できます。たとえば、インターフェイスの平均 RT が 0.005 秒である場合、1 つのワーカー スレッドは 200 のタスクを処理できます。単一のマシンがサポートする必要がある場合は、 QPS 3W の場合、必要なコア スレッドの数は 150 であると計算できます。
それが公式です: QPS ➗ (1 ➗ 平均 RT) = QPS * RT
見落とされがちな @Async アノテーション
Spring で @Async アノテーションを使用するデフォルトのスレッド プールは SimpleAsyncTaskExecutor です。デフォルトでは、設定がない場合、スレッド プールは毎回新しいスレッドを再作成し再利用されないため、使用されません。
したがって、@Async を使用する場合は、それを構成する必要があることに注意してください。
@EnableAsync
@Configuration
@Slf4j
public class ThreadPoolConfig {
private static final int corePoolSize = 100; // 核心线程数（默认线程数）
private static final int maxPoolSize = 400; // 最大线程数
private static final int keepAliveTime = 60; // 允许线程空闲时间（单位：默认为秒）
private static final int queueCapacity = 0; // 缓冲队列数
private static final String threadNamePrefix = "Async-Service-"; // 线程池名前缀
@Bean("taskExecutor")
public ThreadPoolTaskExecutor getAsyncExecutor(){
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(corePoolSize);
executor.setMaxPoolSize(maxPoolSize);
executor.setQueueCapacity(queueCapacity);
executor.setKeepAliveSeconds(keepAliveTime);
executor.setThreadNamePrefix(threadNamePrefix);
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy());
// 初始化
executor.initialize();
return executor;
}
}4. スレッドプールはどのようにして急増しましたか?
Dubbo サーバーのワーカー スレッドを次のように構成します。
corethreads: 150
threads: 800
threadpool: cached
queues: 10合理的だと思われますか? 少数のキューを設定するのは、ジッターによる短期的なスレッド プールの不足を防ぐためです。以上のことから、日中の業務量を考えるとコアスレッド数は十分に足りている(RT<5ms、QPS<1w)ので問題なさそうです。ただし、オンラインになった後、スレッド プールが急増し、最大しきい値の 800 に達し、アラーム情報は次のようになります。
org.apache.dubbo.remoting.RemotingException("Server side(IP,20880) thread pool is exhausted, detail msg:Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-IP:20880, Pool Size: 800 (active: 4, core: 300, max: 800, largest: 800), Task: 4101304 (completed: 4101301), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://IP:20880!"上記のことから、スレッドの最大数に達すると、アクティブなスレッドの数が非常に少なくなることがわかりますが、これはまったく予想外です。
5.シーンシミュレーション
ソースコードによる
queues == 0 ? new SynchronousQueue<Runnable>() :
(queues < 0 ? new LinkedBlockingQueue<Runnable>()
: new LinkedBlockingQueue<Runnable>(queues))次のことがわかります。
キュー要素が 0 の場合、ブロッキング キューは SynchronousQueue を使用します。キュー要素が 0 未満の場合、無制限のブロッキング キュー LinkedBlockingQueue が使用されます。キュー要素が 0 より大きい場合、制限付きキュー LinkedBlockingQueue が使用されます。
コアスレッド数や最大スレッド数は間違いなく問題ないので、キュー数に問題があるのかどうか推測します。
再現するために、簡単なコードシミュレーションを書きました
package com.bytearch.fast.cloud;
import java.util.concurrent.*;
public class TestThreadPool {
public final static int queueSize = 10;
public static void main(String[] args) {
ExecutorService executorService = getThreadPool(queueSize);
for (int i = 0; i < 100000; i++) {
int finalI = i;
try {
executorService.execute(new Runnable() {
@Override
public void run() {
doSomething(finalI);
}
});
} catch (Exception e) {
System.out.println("emsg:" + e.getMessage());
}
if (i % 20 == 0) {
try {
Thread.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
System.out.println("all done!");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static ExecutorService getThreadPool(int queues) {
int cores = 150;
int threads = 800;
int alive = 60 * 1000;
return new ThreadPoolExecutor(cores, threads, alive, TimeUnit.MILLISECONDS,
queues == 0 ? new SynchronousQueue<Runnable>() :
(queues < 0 ? new LinkedBlockingQueue<Runnable>()
: new LinkedBlockingQueue<Runnable>(queues)));
}
public static void doSomething(final int i) {
try {
Thread.sleep(5);
System.out.println("thread:" + Thread.currentThread().getName() + ", active:" + Thread.activeCount() + ", do:" + i);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}シミュレーション結果：
| queueSize 値 | 現象 |
|---|---|
| 0 | 例外なし |
| 10 | 拒否例外が発生しました |
| 100 | 例外なし |
例外は次のとおりです。
emsg:Task com.bytearch.fast.cloud.TestThreadPool$1@733aa9d8 rejected from java.util.concurrent.ThreadPoolExecutor@6615435c[Running, pool size = 800, active threads = 32, queued tasks = 9, completed tasks = 89755]
all done!明らかに、同時実行性が高く、LinkedBlockingQueue 制限付きキューが使用され、キューの数が比較的少ない場合、スレッド プールに問題が発生します。
キュー構成を 0 に変更してオンラインにすると、通常の状態に戻ります。
より深い理由については、興味のある学生が詳しく分析したり、公式アカウントの背景で私とコミュニケーションしたりすることができます。
6. まとめ
今回は、スレッド プール ThreadPoolExecutor の基本原理、スレッド プール構成の計算方法、見落とされやすい @Async 構成の問題について共有しました。
さらに、スレッド プールを使用するときに遭遇した奇妙な問題、つまりパラメーターの問題が発生し、予期しない結果を引き起こす可能性があります。
上記の共有がお役に立てば幸いです。