JetBrainsは、2026年8月27日に公開したブログ記事で、IntelliJ IDEAにおけるProject Loomの3つの構成要素、Virtual Threads、Scoped Values、Structured Concurrencyについて実践的に解説しています。基本的な考え方は、個別のAPIを追加することではなく、Javaの並行アプリケーションにおける相互に関連した3つの問題、すなわちスケーラビリティ、タスク間のコンテキスト伝播、スレッドとエラーのライフサイクル管理に対処することです。
この資料では、マルチスレッドコードの記述には、スレッドリーク、例外の握りつぶし、競合状態、キャンセルの遅延が依然として発生しやすいと説明しています。また、従来のスレッドプールやCompletableFutureへの依存では、キャンセルロジックとエラー処理が複数の分岐に分散する可能性があり、新しい並行タスクを追加した際に更新されないリスクが高まります。
仮想スレッドが待機コストを軽減する
仮想スレッドはJEP 444に基づいており、Java 21以降で安定版となっています。オペレーティングシステムのスレッドに結び付いたプラットフォームスレッドとは異なり、仮想スレッドはJVMによって管理され、はるかに低コストで作成できます。JetBrainsによれば、仮想スレッドの作成にはミリ秒ではなくマイクロ秒かかり、データベース、ネットワーク接続、ファイル、同期機構を待機して停止すると、プラットフォームスレッドを解放します。
そのため、特にブロッキング処理に依存するワークロードに適しており、スレッドプールのサイズを事前に調整する必要性が減ります。資料ではさらに、Java 24がJEP 491を通じて、synchronizedメソッドや文の内部でブロックされた仮想スレッドがプラットフォームスレッドを解放し、保持し続けないようにする改善を導入したことにも触れています。
ThreadLocalの問題を伴わない共有コンテキスト
JEP 506に基づきJava 25以降で安定版となったScoped Valuesは、別の問題に対処します。アプリケーションでは、セッションIDやトレースIDなどのデータをリクエストの複数の部分に渡す必要が生じることがよくあります。従来は通常ThreadLocalで行っていましたが、その値は変更可能であり、手動で削除しない限りスレッドの寿命に結び付いたままになるため、メモリリークやセキュリティ上の問題につながる可能性があります。JetBrainsは、開発者が直接使用していない場合でも、Springなどのフレームワークが内部でThreadLocalを使用することがあると指摘しています。
ScopedValueは、特定のスコープ内で値を一度だけバインドし、その内部で実行されるコードから自動的に利用できるようにし、スコープ終了時にクリーンアップするモデルを提供します。スコープ内からバインディングを変更することはできません。また、構造化並行性と併用すると、明示的にコンテキストを渡さなくても、値が子タスクへ伝播します。実際には、並列タスクを実行する際に開発者が追跡する必要のある制御点の数が減ります。
構造化並行性がタスクを明確なライフサイクルに結び付ける
JEP 533に基づくStructured Concurrencyは、並行コードにおける構造上の問題を対象としています。しかし、Java 27ではなお7回目のプレビュー段階であるため、JetBrainsは現時点で本番環境での使用を推奨していません。この概念では、関連するタスク群を、所有者、ライフサイクル、明確な失敗ポリシーを持つ1つの作業単位として扱います。
JetBrainsが示す例では、顧客プロファイルを構築するため、アプリケーションが顧客の注文履歴と商品推薦を並列に取得します。StructuredTaskScopeを使用すると、2秒のタイムアウトを設定し、両方のタスクの成功を必須にし、一方が失敗するかタイムアウトになると、もう一方のタスクを自動的にキャンセルできます。例外処理の分岐でcancel()の呼び出しを繰り返す代わりに、キャンセルポリシーがタスクスコープの一部になります。
この資料では、すべてのタスクの成功を必要としない別のケースについても説明しています。アプリケーションが2つのキャッシュから推薦を取得し、最初に成功した応答だけで十分な場合は、anySuccessfulOrThrow()を使用できます。成功した結果が届くとスコープが閉じられ、もう一方のタスクは自動的にキャンセルされます。一方、両方のタスクが失敗した場合は、失敗の理由を示す例外がスローされます。
IntelliJ IDEA内で何が変わるのか
利点はコードの構文だけにとどまりません。IntelliJ IDEA 2026.1以降、StructuredTaskScope内で作成された仮想スレッドは、そのスコープを表すコンテナにまとめられるため、親タスクと子タスクの関係構造がデバッガーに表示されます。これにより、スレッドダンプは単に共通プールのスレッドを平坦な一覧として表示するのではなく、同じリクエストに属するタスクをより適切に示せるようになります。
これらの機能を試すには、資料によればEarly Access版であるJava 27と、実験的機能を使用するための言語レベルの設定が必要です。IntelliJ IDEAではプロジェクト設定からJDKをダウンロードできるほか、SDKMAN!やasdfなどを使用してJDKバージョンを管理する際には、インラインヒントも表示されます。stsライブテンプレートを使えば、StructuredTaskScopeの基本構造を作成できます。
certi.newsによる編集部の見解
ここで実際に変わるのは、並行性の管理の一部が開発者の手作業による責任から、コードの構造自体がタスクのライフサイクルと失敗ポリシーを表現するモデルへ移行することです。Virtual Threadsはスケーリングのコストに対処し、Scoped Valuesはコンテキストの伝播を整え、Structured Concurrencyはキャンセルとエラーの伝播を予測可能にしようとします。これらの機能を組み合わせることで、複数の待機処理を並列に実行するアプリケーションでは、重複コードを減らせる可能性があります。
しかし、発展段階にあることの限界は明確です。Structured Concurrencyはまだ安定版になっておらず、記事の公開時点でJava 27はEarly Access版でした。そのため、このブログ記事はすべてのアプリケーションが自動的に改善することを証明するものではなく、これらのモデルを使用する際に、利用するライブラリやフレームワークの挙動をテストする必要性もなくなりません。現時点で開発者にとっての価値は、パターンを理解し、安全に試すことにあります。APIが安定し、十分な運用上の知見が得られるまでは、実験的な機能を本番環境の外に置く必要があります。