【ITニュース解説】Why Does Concurrency Have to Be So Hard in Java After 20 Years?

Javaは誕生から長い年月が経ち、その初期から並行処理の機能を提供してきた。現在では、より高機能な非同期処理の仕組みも導入されているにもかかわらず、正しく並行処理を実装することは依然として非常に難しいと感じる開発者が多い。本稿では、なぜJavaでの並行処理がこれほどまでに困難なのか、その理由を過去の機能から最新の技術まで順に見ていく。

まず、最も基本的な並行処理の単位であるスレッドは、1995年のJava登場時から利用できた。複数の処理を同時に実行するために直接スレッドを作成する方法だ。しかし、この方法は多くの問題を含んでいる。たとえば、スレッドの開始、実行、終了といったライフサイクルの管理はすべて開発者が手動で行う必要があり、非常に複雑である。また、並行して実行中のスレッドが途中でエラーを起こした場合、そのエラーを親の処理に伝える仕組みが不十分で、エラーハンドリングが困難だった。さらに、一度開始したスレッドを途中で安全に停止させる「キャンセル」の概念もほとんどなく、プログラムの信頼性を保つのが難しかった。複数のスレッドが同時にデータにアクセスする際の競合状態を防ぐための同期処理も手動で行う必要があり、バグの温床となることも多かった。

次に、2004年に導入されたExecutorServiceは、スレッドの管理をより効率的に行うための仕組みだ。スレッドをプールし、タスクをキューに入れて順次実行することで、スレッドの生成や破棄のオーバーヘッドを減らし、リソースの再利用を促進した。これにより、スレッドのライフサイクル管理の複雑さはある程度軽減された。しかし、ExecutorServiceを使っても、すべての問題が解決したわけではない。複数のAPIからデータを並行で取得し、それぞれの結果を処理し、エラーを適切にハンドリングし、さらには全体の処理にタイムアウトを設定するといった少し複雑な要件になると、依然として多くのコードを手動で記述する必要があり、冗長でエラーを起こしやすいコードになりがちだ。また、実行中のタスクを途中でキャンセルする処理や、ExecutorService自体の終了処理も手動で確実に行わなければならず、適切なリソース管理を怠ると問題が発生する可能性があった。

2014年には、非同期処理をより柔軟に、かつ簡潔に記述するためのCompletableFutureが登場した。これは、未来の計算結果を表すオブジェクトであり、複数の非同期処理をチェーンのように連結したり、複数の処理がすべて完了するのを待ったりする機能を提供した。これにより、従来のコールバック地獄に陥ることなく、比較的読みやすい非同期コードを書けるようになった。しかし、CompletableFutureにも限界がある。「構造化された並行処理」という概念が不足しているため、親となる非同期処理がタイムアウトした場合に、その子となる処理（例えばAPI呼び出し）を自動的にキャンセルする仕組みがない。個々の処理に対するタイムアウト設定は可能だが、全体としてのタイムアウトを管理し、関連するすべての処理を停止させるのは依然として難しい。エラーハンドリングも特定のパターンに限定されており、複雑なエラーシナリオにおいて一貫性のある処理を記述するのは困難だった。また、実行中の処理をキャンセルする際も、期待通りに動作しないケースや、不器用なコードを書かざるを得ないことがあった。

そして2023年には、Java 21で仮想スレッド（Project Loom）が正式に導入された。これは、従来の物理的なスレッドよりもはるかに軽量なスレッドであり、開発者は大量のスレッドを生成してもシステムリソースの消費を抑え、より多くの並行処理を効率的に実行できるようになった。これにより、多数のI/O処理（例えばネットワーク通信）を待機するようなアプリケーションのパフォーマンスは大きく向上することが期待されている。しかし、仮想スレッドはパフォーマンスの向上をもたらすが、これまでの並行処理が抱えていた根本的な問題、すなわち自動キャンセル、明確なエラー伝播の境界、タイムアウトの自動化といった課題を直接解決するものではない。開発者は依然として、これらの問題を自力で、かつ手動で管理する必要がある。

これらの歴史と現状から、Javaの並行処理にはいくつかの根本的な欠点が浮き彫りになる。一つは「構造化された並行処理」の欠如だ。親となる処理が、そこから派生した子となる並行処理のライフサイクルを明確に管理する仕組みがないため、親が終了しても子が意図せず実行され続け、リソースリークにつながることがある。二つ目は「信頼性の高いキャンセル」が難しいことだ。実行中の処理を安全かつ一貫した方法で停止させるメカニズムが不完全であるため、処理の途中停止が困難で、プログラムの堅牢性を損ねる。三つ目は「一貫したエラーハンドリング」の不足だ。並行処理中に発生したエラーが、親の処理に適切に伝播せず、エラーが見過ごされたり、複雑なtry-catchブロックで対処する必要があったりする。四つ目は「リソース管理の安全性」の問題だ。ExecutorServiceのようなリソースは、使用後に必ず手動で閉じなければならず、閉じ忘れが原因でシステム全体に悪影響を及ぼす可能性がある。最後に、「コンテキスト」の不在も挙げられる。キャンセルトークン（キャンセル要求の伝達）、タイムアウト情報、ログの追跡情報など、並行処理全体にわたって共通の情報を一貫して伝達する標準的な方法がないため、これらを個別に管理する必要がある。

Go言語のcontext.WithTimeout、Kotlinのコルーチン、C#のTasksとCancellationTokenなど、他のプログラミング言語ではこれらの課題をより洗練された抽象化によって解決している。これらの言語では、親となる処理が子の処理のライフサイクルを管理し、親がキャンセルされれば子も自動的にキャンセルされ、エラーも自然に親に伝播するといった理想的な並行処理の形が実現されている。開発者が本当に求めているのは、まるでエレベーターのボタンを押すように、シンプルで安全に、そして信頼性高く並行処理を実行できる仕組みである。

このような課題意識から、JCoroutinesという新しいライブラリが開発された。JCoroutinesは、Java 21で導入された仮想スレッドの上に構築され、デフォルトで「構造化された並行処理」を提供する。これにより、親と子の関係が明確になり、処理のライフサイクル管理が自動化される。また、キャンセルやタイムアウト、スケジューラといった「コンテキスト」情報を明示的に並行処理に渡すことができるため、より制御された信頼性の高い並行処理を実現する。特別なコンパイラの魔法を用いることなく、既存のJava APIの上でクリーンな方法でこれらの機能を提供し、開発者が直面する並行処理の困難さを軽減することを目指している。

Java自体も、JEP 428という提案を通じて「構造化された並行処理」の導入を進めており、将来的には言語レベルでこれらの問題が解決される方向に向かっている。しかし、それが安定して広く利用できるようになるまでにはまだ数年かかる見込みだ。その間、JCoroutinesは、Java 21以降の仮想スレッドを最大限に活用し、今日からでもこれらの先進的な並行処理パターンを開発者が利用できるようにする実用的な解決策を提供している。