Java 19搭載予定の新機能「Virtual Thread（仮想スレッド）」 49
ストーリー by nagazou
NEW 部門より
NEW 部門より
あるAnonymous Coward 曰く、
Javaで仮想スレッドなるものが登場。
並行並列プログラミングがやりやすくなるのだろうか。
gihyo.jpに「Java 19の注目新機能Virtual Threadについて」と題する記事が掲載されている。TechFeed Conference 2022のMicrosoftの寺田佳央氏の講演をもとにした内容となっている（gihyo.jp、Java 19 の注目新機能 Virtual Thread について）。
9月にリリース予定のJava 19では「Virtual Thread（仮想スレッド）」という機能が新たに追加され、大量の処理で負荷のかかるようなアプリケーションや並列処理などで効果を発揮するとしている。記事によるとJavaの仮想スレッドを利用することにより、Javaのバーチャルマシンの中でスレッドを作成したり管理できるようになり、ネイティブスレッドに比べて少ないメモリで高速にスレッドを作成することができるとしている。
No more Oracle (スコア:0)
Javaに求めるのは既存プロダクトの維持だけで、新規開発には用いない。
歴史は繰り返す (スコア:0)
なんかリンク先の人の説明がざつだなあ
これまでJavaのスレッドっていわゆるグリーンスレッドとネイティブスレッドのどちらがいいかってずっと言われてて、ネイティブスレッドのスレッド生成コストを見極めつつM:Nスレッドにしようとかいろいろ議論と実装がなされてきたよね
Re: (スコア:0)
FreeBSD版Javaの1.3～1.6あたりだとネイティブスレッドが未実装の場合に使う
互換実装がグリーンスレッドって呼ばれてたような
Re: (スコア:0)
それと何が違うんですかという話だ
Re: (スコア:0)
ネイティブスレッドをサポート出来てるか
サポート出来ずになんちゃってスレッドしかない実行環境なのかって話
ネイティブスレッドと なんちゃってスレッドの比較で
なんちゃってスレッドの方が効率的な場合もあるから
なんちゃってスレッドもサポートしようみたいな話
って感じで微妙にレイヤが違うような……
Re: (スコア:0)
講演なんだから時間制限ある中説明が雑になるのも仕方ないだろ
green thread? (スコア:0)
カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？
タスクスイッチやOS資源的には軽くなるけどマルチコアが活かせないし工夫しないとブロッキングI/Oで全部止まっちゃう古式ゆかしい実装ですが
Re: (スコア:0)
> カーネルスレッドを利用せずOS資源的には1スレッド内で複数のコード/スタックを自前でスケジューリングするとかじゃないですよね？
それじゃないの？
unix系ならsetcontextとか、windowsならfiberとか昔からあるやつ。
言語使用で対応しましたということでは？
Re: (スコア:0)
カーネルスレッドとかネイティブスレッドってキーワードを知ってる老人から見ると、何を今更って話ですね。 んなもん setjump() と longjump() 使えばC言語でも実装できるわ！rubyなんて当初からそうやって実装されてるわ！余計な機能入れるな！などなど言いたいことは沢山あるでしょう。
違うんですよ。
最近はコルーチンとかが流行ってい
Re: (スコア:0)
コルーチンってそれこそC言語しかなかった時代にはもうあった言葉では…
Re: Re: green thread? (スコア:1)
コルーチンは、プアマンズスレッドみたいな扱いされてたことがあるけど、ここ5年か10年くらいで、コルーチンであることが見直されて流行り出してるんですよ。
ラムダとかと一緒。
概念や実装そのものは、80年代とか70年代とかに出てるけど、最近になって見直されてる。
# なんかソフトウェア業界の流行り廃りは間隔が早いって言われるが、言語仕様の流行りだと5年、10年単位だな。
Re: (スコア:0)
更に時代はめぐってselect,pollが流行の最先端に
Re: (スコア:0)
スマホも出てきてしばらくしてから「マルチタスクに対応した！」とか言ってたしな
Re: (スコア:0)
Windowsのストアアプリも出てきてしばらくしてから「マルチウィンドウに対応した!」とか言ってたしな。
Re: (スコア:0)
当初は割に合わなかったものも現代では誤差にしかならんからおk
みたいなのもあるんじゃないかな
Re: (スコア:0)
Cより古い。(1963)
Re: Re: Re: Re: green thread? (スコア:2)
UNIXがコルーチン(ぽいもの)で書かれていた……てなはなしはLions本にも書いてありましたね
Re: (スコア:0)
コルーチンはyieldの前後で実行するスレッドが変わることがあるので、
STAなCOMと一緒に使うとドはまりするので要注意ですね。
Re: (スコア:0)
そんな(マイナーではないけど)一部の実装に限ったことを…
Re: (スコア:0)
Thread Local Storageもな
Re: (スコア:0)
Fiber実装になってないの?
Re: (スコア:0)
fiber的にすることで、あえてスレッドを乗り換えることができる実装がある。
UIスレッドは止めちゃダメなフレームワークなとき、ソース上の区切りのいいところからワーカスレッドにきれいに移れる。
そういう目的・仕組みを理解して使ってねってこと。
Re: (スコア:0)
GILが邪魔なのでスレッドはあんま使いません
Re: (スコア:0)
WindowsのFiber以外で実行するスレッドが変わる実装なんてあるか？
Re: (スコア:0)
昔、コルーチンをsetjump/longjumpで無理矢理実装して、嵌った老人が来ましたよっと。
setjumpは実装によって、全部のレジスタが保存されるとは限らないのよね。
あと、スタックをOSの想定していない場所に配置すると動作がおかしくなったり。。。
Re: green thread? (スコア:1)
// まあアレは返ってこれればおk くらいの実装だからなぁ
Re: (スコア:0)
Linuxカーネルのworkerと何が違うのって思う。
あれも自前でworkqueue用意するとかしない限り、各CPU毎のkworkerで良い感じに処理してくれるしなぁ。
Re: (スコア:0)
記事読むとご指摘の通りのなんちゃってスレッドですね
多分工夫しなくてもI/Oでブロックされないプログラムが作れるものだと思います
デメリットはマルチコア使えないのでCPU負荷が高い場合は向いてないとリンク先の記事に書かれてますね
メリットは使用メモリが少なく済むとかいろいろあるけど
最近のマルチCPUには向いてるかも？
CPUの近くにメモリが配置されるようになったけど、逆に別CPUに繋がってるメモリは遠くなってるので
下手なマルチスレッドで共有メモリ使うものは性能が上がりにくくなった可能性がある
逆に昔ながらのプロセスモデルだと、近くのメモリを使うので性能が上がりやすい
マルチスレッドをグループで管理してなるべく近くのメモリを共有する仕組みがうまく当てはまれば問題ではないんだろうけど
Re: Re:green thread? (スコア:2)
500万コネクションを捌きたいとか。 1999年にC10kって言ってたのが、今はC5Mまで増えてるんですね。
https://github.com/ebarlas/project-loom-c5m
Re: (スコア:0)
WindowsのUser-Mode Schedulingならブロッキングするsyscallした時点で自動で切り替わるよ
と思ったらUMS死んでた
Re: (スコア:0)
え、そうなの？
スレッド単位だとずっと思ってた
Re: (スコア:0)
一般的なOSではスレッド単位でコアに割り当てます。
ただしあなたが言う「OS」がどのOSの事を言っているのかまではわかりませんので、正確にはOS次第としか言えません。
プロセス単位でコアに割り当てるOSがあってももちろんいいはずです。それで性能が出るかどうかはまた別問題ですが。
Re: (スコア:0)
そのスレッドの定義によるかと
ここで議論されてるスレッドはなんちゃってスレッドのことかと
OS側から見ると１つのプロセスと見れるが
プログラムはまるでスレッドのように動くもののことですね
なぜこんなメリットの無さそうなものが存在してるかというと
プログラムの作成が楽になるから
本当のスレッドを安全に作るのは難しいけど
なんちゃってスレッドには簡単に安全に作れるものが多いですからね
Javaって (スコア:0)
まだあったんだ
Re: (スコア:0)
あと未だに10番代っていう進化の遅さ。
Re: (スコア:0)
LTSが重視される業界もあるのですよ
そしてあなたが使っているインフラもきっとJavaで動いてる
なにせ30億のデバイスで走るJavaですからね！
Re: (スコア:0)
むしろそんな頻繁にバージョンが上がる言語とか糞ったれだと思うが。
そもそもバージョン10を超えてる言語ってそんなに無いだろ。
Re: (スコア:0)
アンドロイドアプリ開発で主に使われている言語ですよ！
Re: (スコア:0)
だからモッサリ動作で不安定なんだね^^
Re: (スコア:0)
冗談でもそういうデマを書くのはやめろ
Re: (スコア:0)
アンドロイドで使われてるから、世界で一番使われてる言語なんじゃないか？
当分、安泰な気がする。
まだjava8相当だっけ？
Re: (スコア:0)
今から新規でjavaとかありえないよ。
世間から10年単位で時間が遅れているような環境だとありえるけど。
世間とは (スコア:0)
現実は世間から10年単位で時間が遅れてる世界の規模 >> 世間の規模ですね
いつからだっけ (スコア:0)
グリーンスレッドやめてネイティブスレッドに変えた頃はまさか今頃になってグリーンスレッドが必要になるとは思わなかっただろうな
記事の内容だけだと、スレッドプールでいいやん (スコア:0)
大昔(バージョン1.5)にスレッドプールが導入され、
「ネイティブスレッドの都度生成は止めて使いまわしましょう。Threadではなくタスク(Runnable)を使いましょう。」
で並行処理は組まれているでしょう。なぜ今更仮想スレッドが必要になるのでしょうか？
JEP425によると、従来の方法では待機処理に対して効率が悪いと指摘しています。
Javaでは待機処理はネイティブスレッドそのものを止めてしまい、待っている間に他のタスクを実行することはありません。
そのため、待機処理が1秒あるタスクを従来のスレッド200個で処理する場合は待機処理の制約により最大200件/秒の処理速度しかでません。
スレッドの数を増やせば処理速度は改善しますが、ネイティブスレッドではOSの制約により多く作ることはできません。
一方、仮想スレッドの場合はOSの制約無く大量に作ることができ、10000件のタスクがあれば10000個の仮想スレッドを作成するといった方法でスループットを改善できます。
典型的なアプリケーションサーバーでは待機(たとえば、外部サーバーからのレスポンス待ちとか？)を含む大量の処理を行うため、仮想スレッドによりスループットの改善が見込めます。
# 仮想スレッドの速度自体はネイティブスレッドより速いわけではないので、
# 待機の無い計算負荷の高い処理にたいして、仮想スレッドは助けにならない。
# とJEPには書いてあるけど、どうして記事ではその点を書いてないのだろう？
Re: (スコア:0)
仮想スレッドとネイティブスレッドの速度差について
昔は確かにネイティブの方が速いと言われてたが
今はネイティブのオーバーヘッドが無視できなくなって必ずそうとは限らなくなったということ
特に最近のCPUの進化が変な方向に行っていて
ネイティブスレッドのオーバーヘッドが余計に大きくなった感じある
Re: (スコア:0)
本質的に ExecutorService と変わらんだろ、と言いたいのはわかるけど。
現行の仕様だと実行中にIO入ったら切り変えていい、とはならないのでは。
多分裏ではIOの所で io_uring とかを使う想定で、async/await 構文を導入する布石なんじゃないかな。