傳統並行架構的隱憂與結構化並行的誕生背景
在現代伺服器端應用程式中，高並發任務的處理一直是 Java 開發的核心領域。然而，傳統的多執行緒程式設計模型長期面臨結構鬆散的架構難題。過去開發人員依賴 ExecutorService 與 Future 管道來派發多個非同步子任務，這種機制在執行緒生命週期管理上缺乏強制性的階層邊界。當一個父層呼叫方法觸發多個背景執行緒時，即便父層方法已經返回，子任務仍然可能在系統背景持續運作，造成非預期的執行緒洩漏與資源浪費。更棘手的是，若其中一個子任務在執行期間拋出異常，錯誤往往無法即時反饋給其他正在進行的子任務，非得等到呼叫端明確執行 Future.get 方法時才能捕獲。這種鬆散的執行緒關聯大幅增加了系統的除錯難度與狀態不一致的風險。
為了徹底解決這個架構痛點，Project Loom 提出了結構化並行概念，其宗旨在於將在不同執行緒中運行的相關子任務群組視為單一工作單元。在結構化並行模型下，若其中一個子任務遭遇失敗，系統會自動取消其餘相關聯的子任務；同時，父層範圍在所有子執行緒徹底終止之前絕對無法退出。這項功能歷經了 Java 生態系統中最為漫長的試驗期，自 JEP 428 在 JDK 19 與 JEP 437 在 JDK 20 以孵化器 API 亮相後，隨後在 JDK 21 至 JDK 27 期間接連歷經了 JEP 453、JEP 462、JEP 480、JEP 499、JEP 505、JEP 525 及 JEP 533 共計七次預覽版本。如今，根據外媒 InfoQ 的最新報導，JEP 543 已經正式整合進 JDK 28，標誌著結構化並行 API 終於正式定案，結束長達數年的預覽歷程。
核心架構剖析：StructuredTaskScope 與虛擬執行緒的緊密結合
JEP 543 所定案的核心架構位於 java.util.concurrent 套件下的 StructuredTaskScope 密封介面。開發團隊捨棄了公共建構子的設計，改採靜態工廠方法 open 來建立作用範圍。在預設情況下，呼叫一次 fork 方法就會自動啟動一個虛擬執行緒來執行子任務，這使得系統能夠以極低的資源成本建立大量並行作業。所有的子任務調度與結果等待都被收斂在結構清晰的 try-with-resources 語法區塊中，使得整個並行區塊的開始與結束擁有如同傳統單執行緒控制流程般的清晰邊界。
在運作流程中，fork 方法負責分派子任務，join 方法則是擁有者執行緒等待所有並行結果的唯一同步節點，而由 try-with-resources 所觸發的 close 方法，則會在區塊結束時確保任何尚未完成的子任務均被取消，並等待這些執行緒全部終止。這種嚴格的邊界控制確保了資源不會在區塊之外游離。子任務的完成策略由 Joiner 介面負責定義，提供了高度彈性的組合能力。除了預設在第一個失敗發生時取消其餘子任務並拋出例外狀況的策略外，API 還內建了專門用於同質子任務並直接在 join 回傳結果列表的 Joiner.allSuccessfulOrThrow、在取得第一個成功結果後立即取消其餘子任務的 Joiner.anySuccessfulOrThrow，以及當符合特定斷言條件時立即取消範圍的 Joiner.allUntil 等多種實用策略。
從預覽走向定案：API 演進、Joiner 策略與類型安全
在 JDK 27 的第七次預覽版 JEP 533 中，結構化並行 API 確立了其最終形態，而 JDK 28 的 JEP 543 則完全承襲該設計，未引入任何 API 層級的破壞性變更。在早期的預覽版本中，join 方法通常會拋出特定於預覽機制的 FailedException，但這在工程實踐上造成了不便。因此，在 JEP 533 中引入了第三個型別參數 R_X，讓 Joiner 能夠精準宣告 join 方法所拋出的受檢例外類型。針對內建的例外拋出型 Joiner，API 統一回歸了 Java 開發者長期熟悉的 ExecutionException，延續了過去使用 Future.get 時的例外處理直覺。
這項型別系統的改良在自訂策略中展現了巨大價值。例如在實作分散式系統中常見的法定人數讀取策略時，開發人員可以定義一個繼承 Joiner 的 QuorumJoiner，並將其第三個型別參數直接宣告為自訂的 QuorumException。當讀取結果未達到設定的法定門檻時，result 方法或逾時處理方法便能直接拋出包含失敗原因的 QuorumException，使得呼叫端的例外捕獲無需再經歷多層的包裝與拆箱。此外，相較於 JDK 26，最終版本全面移除了舊有的 StructuredTaskScope.TimeoutException，改將逾時狀況透過 CancelledByTimeoutException 記錄在例外的成因中；同時也移除了 Joiner.awaitAll，並將原本的 onTimeout 回呼替換為抽象的 timeout 方法，進一步強化了程式碼結構的嚴謹性。
嚴格結構約束與邊界行為的工程考量
除了靈活的任務調度，結構化並行對程式碼的結構正確性有著毫不妥協的要求。這項機制強制落實單一執行緒約束：只有開啟特定 StructuredTaskScope 的執行緒，才有權限呼叫其對應的 fork 與 join 方法；子任務的執行結果也嚴格限定只有在 join 成功返回後，才能透過 Subtask.get 進行讀取。如果開發人員在程式邏輯中發生結構性誤用，例如以錯誤的順序關閉不同層級的作用範圍，系統將會立即拋出 StructureViolationException 進行快速失敗，而不是任由執行緒在未知狀態下洩漏。
在系統可觀察性與環境傳遞方面，子任務會自動繼承呼叫端透過 ScopedValue（JEP 506）所綁定的上下文環境變數，並且在系統產生 JSON 格式的執行緒傾印時，子執行緒會被清晰地歸類在父層任務之下，極大化提升了分散式跟蹤與除錯的便利度。值得注意的一項實務細節是，在多個子任務同時遭遇失敗的邊界情境下，API 刻意未定義 join 方法必須優先回報哪一個子任務的錯誤。在早期的程式碼審查階段，Viktor Klang 曾提出此問題，隨後 Oracle 該 JEP 的主導者 Alan Bateman 更新了 Javadoc 規範，明確宣示 API 僅保證拋出的例外來自於失敗的子任務之一，而不保證其具體順序，這為未來的執行時期效能最佳化預留了彈性空間。
生態系影響與未來的升級路徑
隨著 JEP 543 在 JDK 28 的定案，對於已經在 JDK 27 啟用第七次預覽版的專案團隊而言，移轉至正式版的成本極低。由於正式版僅移除了預覽標記而未調整方法簽章，開發團隊只需要在編譯工具、測試執行環境以及啟動腳本中移除 --enable-preview 參數，並使用包含該變更的 JDK 28 建置版本重新編譯即可。JDK 28 預計將於 2027 年 3 月正式推向全面公開發布。
這項特性的正式定案對 Java 函式庫與框架維護者而言意義更為重大。以往因為需要強制使用者開啟預覽參數，許多基礎框架對整合結構化並行抱持觀望態度；定案後，框架社群終於能夠在不影響使用者建置設定的前提下，放心地將結構化並行引入其核心非同步架構中。針對仍停留在舊版 Java 的企業，目前社群中的 velo/structured-concurrency 等專案已經將 JEP 543 的 API 逆向回移植至 JDK 25，並提供平滑的移轉指引，協助開發者提早享受結構化並行帶來的強健性與清晰度。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。