Javaスレッド性能比較と仮想スレッド導入の実用効果

まずはこのステップを実行してみて - 仮想スレッド導入でJava並列処理の効率と安定感を両立

スレッドプールの最大数をCPUコア数×2以下に設定
無駄なリソース消費を防ぎ、全体のレスポンスが約10％向上
I/O中心なら仮想スレッドを同時に100本以上実行
従来の制約を気にせず高負荷時もOutOfMemoryErrorが起きにくい
同期化は必要箇所だけsynchronizedやReentrantLockを使い分け
競合発生率を3割削減、処理待ち時間も短縮
AtomicIntegerやConcurrentHashMapへ置き換えを検討
ロック頻度が減り、スレッド間のデータ競合を自動で抑制できる

プロセス？スレッド？コンピュータの基本を振り返る

Javaのバーチャルスレッドを理解する前に、ああ、その前提としてまず「プロセス」と「スレッド」という2つの基本的なコンピューティング概念について触れておきたい。えっと、まあ、眠いから説明が変だったらごめんね。
「プロセス」って何？と聞かれたら、独立して動くプログラムのインスタンスだよ、と答えるしかないかな。例えばだけど、複数開いたブラウザウィンドウ、それぞれが別々のプロセスになるってこと。で、それぞれには専用のメモリ空間やリソースが割り当てられてる……はず、多分。
うーん、「スレッド」はどう説明しよう。実はそうでもなくて…つまり、プロセス内で動く最小単位が「スレッド」なんだよね。一つのプロセスに複数のスレッドが存在する場合も多い。そして、それら複数のスレッドは同じメモリ空間やリソースを共有している。このへん、ごちゃごちゃしてわかりにくいけど、大事なポイントだから一応書いておきたい。本筋へ戻るけど…意外と奥深い話だと思わない？ま、いいか。

昔ながらのJavaスレッド、OSとの不思議な関係性

マルチスレッド化というやつ、まあ、結局のところプログラムが複数の操作を一度に走らせることを可能にするって話だけど…本当に全てうまくいくかどうかは謎めいている。応答性が良くなったり、たぶんシステムリソースももう少し上手く使えるようになったりする場合もある。それでも、全部が全部そうなるとも言えない。ああ、今更ながら何を書いてるんだろうな、自分で自分に突っ込むけど──とりあえず、本筋へ戻すか。}

{## 従来のアプローチ：JavaプラットフォームスレッドとOSとの関係
長年の間、Java開発者が並行処理――つまり複数の仕事を同時進行したい場面では、とにかく _**java. lang. Thread**_ クラスってやつを使うしかなかった（まあ、それ以外にも選択肢はあるようで実はそんなに無かった気もする）。最近じゃ「プラットフォームスレッド」なんて呼ばれているけれど、このThreadクラスからスレッド作成するとJVM側は普通ならOSさんに「ネイティブなOSスレッド作って」と頼みにいくらしい。その後、そのスレッド自体は完全にOSのスケジューラ任せになるわけだ。この1対1対応――つまりプラットフォームスレッドとOS側との紐づきには特有の影響とか制約が存在しているんだよね。正直そこまで深く掘るべきなのか悩み始めてしまうけど……いや、大事なので戻ろう。

重たいOSスレッド問題とOutOfMemoryError地獄

OSスレッドの新規作成って、まあ…重たい処理なんだよね。やっぱりスタックとかカーネル側で使われるデータ構造に、かなりメモリが割かれてしまう。ああ、それだけじゃない。アプリケーションが同時に面倒見られるプラットフォームスレッドの数も結局OSまかせでさ、そこの限界はRAMとかCPUコアみたいなシステムリソース次第、たぶん。いや、ごめん、ちょっと話逸れた。でもこれ、本筋。

public class PlatformThreadDemo {
public static void main(String[] args) {
System.out.println("Main thread started: " + Thread.currentThread().getName());

for (int i = 1; i {
System.out.println("Platform thread " + Thread.currentThread().getName() + " is running.");
try {
Thread.sleep(2000); // Simulate some work
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
System.out.println("Platform thread " + Thread.currentThread().getName() + " finished.");
}, "Platform-Thread-" + i);
platformThread.start();
}

System.out.println("Main thread finished.");
}
}

## ボトルネックと変化：プラットフォームスレッドの課題とバーチャルスレッドへの期待

プラットフォームスレッド、長いこと主流だったけど――最近は高並行性が求められるアプリケーションだと、「え、本当にこれで大丈夫なの？」みたいな声も多くなってきた気がする。いや、知らんけど。

- **スケーラビリティの制約:** プラットフォームスレッドを何百・何千と生成し始めると、どうしたってシステムリソースがぐんぐん減っていく。脇道→例えばコンテキスト切り替えが多発するとその分オーバーヘッドも跳ね上がるし→あ、ごめん本題戻すね。それで結果的にパフォーマンスは下落していくし、各Threadごとの事前メモリ確保もうまくいかず _**OutOfMemoryError**_ が出たりする。

- **ブロッキング呼び出し時の非効率性:** プラットフォームスレッドでブロッキング操作（ネットワークI/OやDBクエリ待機など）を走らせる場合、その背後のOSスレッドもひたすらアイドル状態になるしかなくて、有意義な進捗ないままリソース食いつぶす感じ？「1リクエスト＝1スレッド」式はI/O中心系アプリには正直向いてないと思う。

そんな事情から最近よく聞くようになったのが――バーチャルスレッド。その期待値は…まだ未知数だけど、多分現状打破への鍵になる…かもしれない。うーん、この辺でもう疲れてきた…。

コード例：プラットフォームスレッドで遊んでみる

**Virtual Threads**はさ、あれだよね…2023年リリースの**Java 21 (安定版として導入)**でついに正式機能になった。いや、本当にやっと、って感じ。JavaスレッドとOSスレッドが今までガチガチに結びついていたのが、“切り離された”というか、まあ…分離されたんだよな。たぶんそこが肝要かも。

バーチャルスレッドは、とにかく軽量なんだよね。他の重たいものと違う。JVMによって直接管理されてるから、うーん、普通の感覚ではちょっと掴みにくい部分も正直ある。でも、それこそ停止や再開みたいな操作をしてもさ、OSスレッド自体がブロックされない仕組みで動くという…。ふしぎだけど便利かもしれない。実際に使ってみるまでピンと来なかったけど。

えっと…こういうイメージで想像してほしい気持ちになる：うるさいレストラン（OSスレッド）を思い浮かべてさ、プラットフォームスレッドだと一人ひとりのお客さん（タスク）ごとに専属ウェイター（OSスレッド）が必要だったわけよ。それなのに、お客さんが料理待ってダラダラしてる時すらウェイターは拘束され続けていた。本筋から逸れるけど、自分なら途中でトイレ行っちゃうと思う。でも現実にはそうはいかなくて…。

でもバーチャルスレッドの場合はどうなんだろうね？少数のウェイター（キャリアースレッド）が大量のお客さんを捌くことができるようになった――そんな比喩を聞いたことがあるし、多分それで合ってる気もする。ただ本当に現場でその効率性を実感できるかどうかは、まだこれから試行錯誤かなぁ、と少し不安にもなる。ま、いいか。

仮想スレッドって何？革命の入り口に立つ話

お客様の料理が調理中（ブロッキングI/O）のとき、ウエイターは他のお客様にサービスを提供できて、最初のお客様の注文が出来上がった瞬間にさっと戻ってくることもできる。まあ、うまくやればの話だけど。なんだろう、この例え話…正直、誰もそこまで気にしてないかもしれないけど、自分で書いていて変な感じになってきたので、一旦本題に戻す。

public class VirtualThreadDemo {
public static void main(String[] args) throws InterruptedException {
System.out.println("Main thread started: " + Thread.currentThread().getName());

for (int i = 1; i <= 100; i++) { // Creating many more threads!
Thread.startVirtualThread(() -> {
System.out.println("Virtual thread " + Thread.currentThread().getName() + " is running.");
try {
Thread.sleep(2000); // Simulate blocking I/O
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
System.out.println("Virtual thread " + Thread.currentThread().getName() + " finished.");
});
}

// Give some time for virtual threads to run
Thread.sleep(3000);
System.out.println("Main thread finished.");
}
}

## 仮想スレッドの仕組み

仮想スレッドは**ユーザーモードのスレッド**として動作しているわけで、オペレーティングシステム(OS)じゃなくてJavaバーチャルマシン(JVM)によって全部管理されているんだよね。いや、本当にそんな区別必要？と思いつつも…。でもこの違いは結構重要らしいし、一応押さえておいた方がいいかも。ブロッキング操作を実行した場合には、その時点で発生する処理について以下の通りになる：

ウエイターが足りない？飲食店メタファーで理解する仮想スレッド

えっと、仮想スレッドがブロッキングコールにぶつかる瞬間があるんだよね。ああ、なんで毎回こうなるのか自分でもよくわからないけど……まあ、それはさておき、とにかくJVMはその事態をちゃんと察知するんだ。察知した後どうなるの？ってちょっと考えてしまったけど、実はね、そのタイミングで仮想スレッドはキャリア（OS）スレッドからそっと「アンマウント」される仕組みになっているらしい。このアンマウントという表現、正直まだ慣れなくて混乱しそうだけど、今のところそう呼ばれてるみたい。

で、そのまま話が終わりそうな気もするけど…いや違うな。そのOSスレッド自体はどうなるんだろう？と一瞬思った。でも心配はいらなくて（たぶん）、結局ほかの仮想スレッドを処理できるようになるみたいだよ。不思議とこの流れには妙な納得感があるような無いような。眠い時ほどこういう挙動が頭からすっぽ抜けたりしてさ……ま、とりあえず大丈夫。

コード例：100個でも平気なバーチャルスレッド体験記

ブロッキング操作が終わるとね、まあ…仮想スレッドはまたマウントされて処理を再開する。ああ、今どこまで話したっけ？うん、とにかくそういう仕組みのおかげで、大量のOSスレッド管理って、それだけでも胃が痛くなりそうなのに、リソース負荷が過剰にならずに済むし、高い並行性も「たぶん」得られる可能性があるって言われてる。ま、いつも完璧とは限らないけど。

## 仮想スレッドが活躍する場面

仮想スレッド…なんだろう、その特有の条件下では結構メリット見込めたりするんだよね。でも他にもいろいろ考えちゃうな、何書こうとしてたっけ——あ、特徴的なアプリケーションの場合だった。

まず一つ目はI/Oバウンド系のアプリケーションかな。実際、多数同時リクエストを捌くWebサーバーとか、外部サービス呼び出しまくるマイクロサービス群、それからデータベースやAPIとひっきりなしに会話してるアプリなんかでは――これ本当に顕著な効果ある場合多い。「そんな都合よく？」って思うでしょ。でも現場感覚として分かる人には分かると思う。

それから、高並行性ワークロード。これはもう…膨大な同時タスクやユーザーセッションを束ねて管理しないと回らないシステムでさ、昔ながらのプラットフォームスレッドだけじゃ絶対無理ゲーだったような規模にも仮想スレッドなら対応できたり、「いや本当？」と疑いつつも期待せずにはいられない部分もある。途中ちょっと脱線したけど、一応ここまでが主題だよ。

JVM内の魔法、マウント・アンマウントの裏側を覗く

非同期プログラミングを簡単にしたいと思うとき、仮想スレッドが意外と役立つことがある。まあ、全部がそうじゃないけど。えっと…仮想スレッドを使えば、非同期処理でも流れがわかりやすく見える時もあって、「なんでこんなにシンプル？」って不思議になる瞬間もあるんだよね。I/Oバウンドの場面で並行処理を扱うときなんかは、とにかくコールバック地獄とかリアクティブフレームワークみたいなのに埋もれるよりは――いや待て、自分でもたまにどっちがいいのかわからなくなる。でもやっぱり仮想スレッドの「待てる」性質を活かせば、直感的なコードを書けたりする。資源にもそこまで負担かけずに済む可能性…いや、これ絶対とは言えないけど。

でもさ、仮想スレッドって何でも解決できる魔法じゃないんだよね。特にCPUバウンドなタスク――つまり計算だけしてCPUずっと独占しちゃうようなヤツの場合、本当はキャリアスレッド（基礎になってる実体スレッド）の数で制限されるっていう現実がある。ああ、この辺ちょっと説明雑かな？いやまあいいや、とにかく仮想スレッド導入したからといってCPU集約型コードが急激には速くならない。それだったらプラットフォームの普通のスレッド使ってサイズ決めた固定プール作った方が管理もしやすいし、そっちの方が良かったりする場合も普通にあるんだよね。

I/O多めなら無敵！どんなアプリがバーチャル向きか考える

【スレッドローカル状態に大きく依存するタスク】バーチャルスレッドは確かにスレッドローカル変数を持てる。だけどさ、ものすごい数のバーチャルスレッドが、それぞれ大量のスレッドローカルデータをズラッと抱え込んだら…うん、どう考えてもメモリのオーバーヘッドは避けられない場面もある。あれ、この前何かで似たような話を聞いた気がするけど、えっと…まあいいや、とりあえずデータ共有戦略についてはよーく考える必要がありそう。なんとなくだけど、それなりに厄介よね。

3. 【パフォーマンス重視・低遅延システムでブロッキングが最小限の場合】極限まで調整されたシステム――例えばほとんどブロッキングしない構成で、本当にミクロ秒単位の微差まで性能を詰めている時には、バーチャルスレッドのコンテキストスイッチ管理による、ごくごくわずかなオーバーヘッドすら無視できなくなることがある。ま、ふつうそこまで神経質にならなくても良い場合が多いとは思う。でも実際、並行性向上による恩恵の方が大きいってケースも頻繁に観測されているみたいだし…ああ、話逸れてしまったけど、ともかく状況次第かな。

## 結論：バーチャルスレッドへの取り組み

Java バーチャルスレッドは正直言って並行処理へのアプローチとして一歩先へ進んだなという印象だ。OS スレッドから切り離された実行モデルだから、大規模同時処理や資源効率化にも道筋が見えてきた感じ。特に I/O が主役になるアプリケーションでは、その効果――つまり恩恵？――を期待してしまう自分がいる。本当はそれだけじゃない気もするけど…。

CPUガチ勢やThreadLocal天国ではどうなるか…そして未来への一歩

Javaエコシステムがこの技術を、えっと…まあ少しずつ受け入れているって話だけど、それが進んでいけば、たぶん今後は今よりもっと頑丈でスケールもできるアプリケーション――うーん、言い方変かも――そういうのが現れる可能性はあるよね。いや、実際どうなんだろう、と自分でも疑問に思う瞬間ある。ま、とにかく軽めな手法を考えてみる時期なのかもしれないし、自分のJavaプロジェクトにも仮想スレッド…使ってみようかな？とか思わない日もない。でも油断すると古いやり方に戻っちゃいそうで怖いし、この流れがいつまで続くのか、正直わからないなあ。