[Kotlin Coroutine] Dispatcherの使い分け

Posted at 2025-12-23

はじめに

Kotlin Coroutines には、用途ごとにいくつかの Dispatcher が用意されています。
Coroutines を効果的に活用するには、処理の性質に応じて適切な Dispatcher を選択することが重要です。

本記事では、以下の記事の続編として、各 Dispatcher の特徴と、どのような場面で利用すべきかを整理します。

Dispatcher	主な用途	スレッド数	Blocking 処理	利用シーン	注意点
Dispatchers.Default	CPU バウンド処理	CPU コア数基準	❌ 不向き	計算処理、データ変換	I/O 待ちで使うと性能低下
Dispatchers.IO	Blocking I/O	多め（上限あり）	⭕ 想定用途	JDBC、ファイル I/O	Non-Blocking API では非推奨
Dispatchers.Main	UI 更新	1（UI スレッド）	❌ 不可	Android / Desktop UI	サーバーでは使わない
Dispatchers.Unconfined	特殊用途	状況依存	⚠️ 注意	テスト・検証	実務では基本非推奨

Dispatchers.Default は CPU バウンドな処理向け の Dispatcher です。

withContext(Dispatchers.Default) {
    heavyCalculation()
}

I/O 待ちが発生する処理を実行すると、CPU 用スレッドが無駄に塞がれ、全体の性能低下につながります。

Dispatchers.IO は Blocking API を安全に隔離するための Dispatcher です。

withContext(Dispatchers.IO) {
    jdbcRepository.findAll()
}

R2DBC や WebClient などの Non-Blocking API を利用する場合、
Dispatchers.IO への切り替えは基本的に不要で、むしろ非推奨です。

// ❌ 不要な Dispatcher 切り替え
withContext(Dispatchers.IO) {
    r2dbcRepository.findAll()
}

Non-Blocking API は I/O 待ち中にスレッドを占有しないため、切り替えることでメリットを失ってしまいます。

Dispatchers.Main は UI スレッド専用の Dispatcher です。

withContext(Dispatchers.Main) {
    updateUI()
}

Spring Boot や WebFlux などのサーバーサイドでは
UI スレッドが存在しないため、通常は使用しません。

Dispatchers.Unconfined は 実行スレッドを保証しない Dispatcher です。

launch(Dispatchers.Unconfined) {
    // 実行スレッドは予測しづらい
}

Dispatchers.Unconfined は、Coroutine を開始時は呼び出し元スレッドで実行しますが、
suspend 以降の再開スレッドは保証されません。
親 Coroutine の Dispatcher を維持するわけではないため、利用時は注意がに注意が必要です。

Dispatcher は Coroutine の実行モデルを左右する重要な要素です。
処理が CPU バウンドか、I/O バウンドか、
また Blocking か Non-Blocking かを意識して選択することで、Coroutine のメリットを正しく活かすことができます。

本記事で Dispatcher に対する理解が深まれば幸いです。