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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
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
81
Flutterハンズオン 4
aya_ebata
0
150
Flutterハンズオン 3
aya_ebata
0
87
Flutterハンズオン 2
aya_ebata
0
88
Flutterハンズオン 1
aya_ebata
0
120
あたらしい もじれつの かきかた
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
Snowflake Night #2 LT
taromatsui_cccmkhd
0
310
三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル / Enterprise AI_Driven Development at MUFG Bank: The Real Story
muit
10
20k
AIエンジニア Devin と歩む、自律型運用プロセスの構築
a2ito
0
560
サンタコンペ2025完全攻略 ~お前らの焼きなましは遅すぎる~
terryu16
1
570
【PyCon mini Shizuoka 2026】生成AI時代に画像処理やオーディオ処理のノードエディターを作る理由
kazuhitotakahashi
0
240
パネルディスカッション資料 (at Tableau Now! - 2026-02-26)
yoshitakaarakawa
0
1k
作るべきものと向き合う - ecspresso 8年間の開発史から学ぶ技術選定 / 技術選定con findy 2026
fujiwara3
6
1.7k
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
14k
What's new in Go 1.26?
ciarana
2
280
Digitization部 紹介資料
sansan33
PRO
1
7k
ソフトウェアアーキテクトのための意思決定術: Create Decision Readiness—The Real Skill Behind Architectural Decision
snoozer05
PRO
27
8.2k
Datadog Cloud Cost Management で実現するFinOps
taiponrock
PRO
0
100
Featured
See All Featured
sira's awesome portfolio website redesign presentation
elsirapls
0
170
Prompt Engineering for Job Search
mfonobong
0
180
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
260
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
ラッコキーワード サービス紹介資料
rakko
1
2.5M
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
110
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
How to Think Like a Performance Engineer
csswizardry
28
2.5k
Product Roadmaps are Hard
iamctodd
PRO
55
12k
New Earth Scene 8
popppiees
1
1.7k
Exploring anti-patterns in Rails
aemeredith
2
280
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クラスを使用してスレッドを立てると - 一般的なリスクを排除できる - 一方のサブタスクが成功/失敗をすると、残りのサブタスクを キャンセルできる - サブタスクが成功した時、失敗した時など、処理がわかりやすくなる