Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JEP 480: Structured Concurrency
Search
Aya Ebata
September 12, 2024
Technology
0
270
JEP 480: Structured Concurrency
2024/09/12 JJUGナイトセミナー Java 23リリース記念イベント
https://jjug.doorkeeper.jp/events/175516
Aya Ebata
September 12, 2024
Tweet
Share
More Decks by Aya Ebata
See All by Aya Ebata
Flutterハンズオン 5
aya_ebata
0
84
Flutterハンズオン 4
aya_ebata
0
150
Flutterハンズオン 3
aya_ebata
0
89
Flutterハンズオン 2
aya_ebata
0
90
Flutterハンズオン 1
aya_ebata
0
130
あたらしい もじれつの かきかた
aya_ebata
0
130
社内勉強会vol.3@ごーふぁー荘
aya_ebata
0
780
社内勉強会vol.2@ごーふぁー荘
aya_ebata
1
790
社内勉強会vol.1@ごーふぁー荘
aya_ebata
0
730
Other Decks in Technology
See All in Technology
めちゃくちゃ開発するQAエンジニアになって感じたメリットとこれからの課題感
ryuhei0000yamamoto
0
110
楽しく学ぼう!ネットワーク入門
shotashiratori
1
460
Postman v12 で変わる API開発ワークフロー (Postman v12 アップデート) / New API development workflow with Postman v12
yokawasa
0
140
DevOpsエージェントで実現する!! AWS Well-Architected(W-A) を実現するシステム設計 / 20260307 Masaki Okuda
shift_evolve
PRO
3
920
AI実装による「レビューボトルネック」を解消する仕様駆動開発(SDD)/ ai-sdd-review-bottleneck
rakus_dev
0
150
銀行の内製開発にて2つのプロダクトを1つのチームでスクラムしてみてる話
koba1210
1
140
頼れる Agentic AI を支える Datadog のオブザーバビリティ / Powering Reliable Agentic AI with Datadog Observability
aoto
PRO
0
200
AI駆動AI普及活動 ~ 社内AI活用の「何から始めれば?」をAIで突破する
oracle4engineer
PRO
1
110
内製AIチャットボットで学んだDatadog LLM Observability活用術
mkdev10
0
120
フロントエンド刷新 4年間の軌跡
yotahada3
0
480
脳内メモリ、思ったより揮発性だった
koutorino
0
370
AlloyDB 奮闘記
hatappi
0
130
Featured
See All Featured
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
240
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
640
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
140
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.4k
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
980
エンジニアに許された特別な時間の終わり
watany
106
240k
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.4k
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
320
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
300
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
380
Embracing the Ebb and Flow
colly
88
5k
Transcript
JEP 480: Structured Concurrency 2024/09/12 JJUGナイトセミナー Java 23リリース記念イベント えばた あや
@aya_122
自己紹介 - 名前: えばた あや - Twitter: @aya_122 - 好き:
ラーメン二郎 / いくら🍣 / ポケモン - お仕事: フリーランス - Go / React / Android - 最近Flutterに入門した🤘
今日話すこと JEP 480: Structured Concurrency (Third Preview) https://openjdk.org/jeps/480
Structured Concurrencyとは - Java 23のJEP 480にてプレビュー機能として提案された - 並行プログラミングを簡素化するために導入
Structured Concurrencyとは - 異なるスレッドで実行される関連するタスクの グループを単一の作業単位として扱い、 エラー処理とキャンセルを合理化する
Structured Concurrencyとは - キャンセルやシャットダウンに起因する一般的なリスクを排除 - スレッドリークやキャンセル遅延など - 並行コードのobservabilityを向上させる - スレッドダンプを取った時、サブタスクのスレッドが何を
しているかが見やすくなる
リリースの歴史 JDK 19 JEP 428: Incubator ↓ JDK 20 JEP 437: Second
Incubator、JEP 429 ↓ JDK 21 JEP 435: Preview ↓ JDK 22 JEP 462: Second Preview ↓ JDK 23 JEP 480: Third Preview(今回の!)
並行処理の利点 - 通常のシングルスレッドでは、サブタスクが順次実行される - サブタスクを同時に実行することで、タスクをより高速に実行できる ようになる - 複数の処理が互いに独立している場合 - 十分なハードウェアリソースがある場合
今までの並行処理の書き方 - ExecutorServiceとFutureを使用することでサブタスクを同時に実行 try (ExecutorService esvc = Executors.newFixedThreadPool(2)) { Future<String>
user = esvc.submit(() -> findUser()); Future<String> order = esvc.submit(() -> fetchOrder()); System.out.println(user.get()); System.out.println(order.get()); }
今までの並行処理の書き方の欠点 - 各サブタスクは独立して成功したり失敗したりする - 失敗すると、スレッドの寿命を理解するのが複雑になる場合がある - あるサブタスクが失敗した場合、別のサブタスクのキャンセルを 自動的に引き起こすことはない -> これがStructured
Concurrencyで改善される -> 次のページで欠点の例を見ていくよ
今までの並行処理の書き方 欠点の例 - findUser()が例外を投げると、user.get()を呼び出すときに例外を スローし、fetchOrder()は自身のスレッドで実行し続けるが、結果は 取得できない try (ExecutorService esvc = Executors.newFixedThreadPool(2))
{ Future<String> user = esvc.submit(() -> findUser()); ⬅ 例外が発生 Future<String> order = esvc.submit(() -> fetchOrder()); ⬅ 実行し続ける System.out.println(user.get()); ⬅ ここで例外がスローされる System.out.println(order.get()); ⬅ すでにエラーで落ちて取得できない }
今までの並行処理の書き方 欠点の例 - findUser()の実行に時間がかかりその間にfetchOrder()が 失敗した場合、findUser()の完了を待った後にorder.get()が例外を スローする try (ExecutorService esvc = Executors.newFixedThreadPool(2))
{ Future<String> user = esvc.submit(() -> findUser()); ⬅ 長い処理 Future<String> order = esvc.submit(() -> fetchOrder()); ⬅ 例外が発生 System.out.println(user.get()); ⬅ findUser()終了後、値が取得できる System.out.println(order.get()); ⬅ 例外がスローされる }
StructuredTaskScopeクラスとは - java.util.concurrentパッケージのStructuredTaskScopeが Structured Concurrency APIの主要なクラス - StructuredTaskScopeを使うと、サブタスクの成功した結果や 例外が集約され、親タスクによって処理される -
サブタスクのライフタイムをレキシカルスコープで限定し、その スコープ内でタスクとサブタスクのすべてのやり取り(フォーク、 結合、キャンセル、エラー処理、結果の合成)が行われる
Structured Concurrencyでの書き方 try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { Supplier<String>
user = scope.fork(() -> findUser()); Supplier<String> order = scope.fork(() -> fetchOrder()); scope.join().throwIfFailed(); System.out.println(user.get()); System.out.println(order.get()); }
Structured Concurrencyでの書き方 1. StructuredTaskScope.ShutdownOnFailure()でスコープを作成する - サブタスクのいずれかが失敗した場合、もう一方のサブタスクが キャンセルされる - try-with-resourcesでスコープが閉じられると、サブタスクの 全てのスレッドは終了する
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { // ... }
Structured Concurrencyでの書き方 2. fork()メソッドを使用して、新しいスレッドを作成する - 型はFutureではなくSupplierになる Supplier<String> user = scope.fork(()
-> findUser()); Supplier<String> order = scope.fork(() -> fetchOrder());
Structured Concurrencyでの書き方 3. join()メソッドですべてのサブタスクを1つの ユニットとして結合し、すべてのサブタスクが 成功するか、キャンセルされるまで待つ - throwIfFailed()メソッドは最初に失敗した サブタスクの例外をスローする scope.join().throwIfFailed();
Structured Concurrencyでの書き方 5. 結合後、get()メソッドでその結果を返す System.out.println(user.get()); System.out.println(order.get());
shutdown()メソッド - スコープのオーナー、スコープ内のサブタスク、ネストされた スコープ内のサブサブタスクは、いつでもshutdown()メソッドを 呼び出してタスクを終了できる - shutdown()メソッドの呼び出し後にフォークされた新しいサブタスク はUNAVAILABLE状態になり実行されない
joinUntil()メソッド - joinUntil()メソッドを使うと指定した期限まで待つことができる - サブタスクが終了するか、shutdown()メソッドが呼び出される前に joinUntil()メソッドの期限が切れると、例外がスローされる
シャットダウンポリシー - StructuredTaskScope.ShutdownOnFailure()はサブタスクが失敗 した時にスコープをシャットダウンするポリシー - StructuredTaskScope.ShutdownOnSuccess()はサブタスクが成功 した時にスコープをシャットダウンするポリシー - 継承してオーバーライドするとカスタマイズ可能
ShutdownOnSuccess()を使う場合 - result()メソッドは最初に成功したサブタスクの結果を返す try (var scope = new StructuredTaskScope.ShutdownOnSuccess<String>()) {
scope.fork(() -> findUser()); scope.fork(() -> fetchOrder()); System.out.println(scope.join().result()); }
まとめ - StructuredTaskScopeクラスを使用してスレッドを立てると - 一般的なリスクを排除できる - 一方のサブタスクが成功/失敗をすると、残りのサブタスクを キャンセルできる - サブタスクが成功した時、失敗した時など、処理がわかりやすくなる