Java EE 平台設計初衷服務於傳統 B2B/B2C 電子商務，假設：交易短促、資源本地、線程池固定、延遲可控。但 Web 2.0 應用特徵——高延遲服務聚合、用戶生成內容(C2C)、持久連接、海量併發、不可預測流量峰值——徹底打破這些假設。傳統同步阻塞 API 在高延遲場景下會耗盡線程池，導致嚴重效能退化。
| 假設 | Web 2.0 現實 | 後果 |
|---|---|---|
| 同步 API 足夠 | 高延遲外部呼叫 | 線程長期阻塞，吞吐量暴跌 |
| 固定線程池 | 海量長連接 | 線程耗盡，新請求排隊/拒絕 |
| 連接池有限 | 需並行存取多外部資源 | 連接等待，資源利用率低 |
| 資源固定已知 | 動態發現微服務端點 | JNDI/DI 無法適應動態拓撲 |
核心思想：等待不佔用線程。請求到達 → 註冊回調/事件監聽 → 釋放線程 → 外部事件完成 → 線程池執行後續邏輯 → 返回響應。
場景：解析請求(2) → 本地 DB 事務(8) → 準備遠程調用(2) → Web Service 呼叫(16) → 組裝響應(4) = 32 時間單位
資源限制：DB 連接池=2，同步 Servlet 線程池=3，異步單線程
| 指標 | 同步 | 異步 |
|---|---|---|
| 總處理時間 | 75% | 57% |
| 首尾請求差異 | 225% | 57% |
| 末請求完成時間 | 基準 | 提早 40% |
結論：異步架構隨硬體升級線性擴展，同步架構受限於線程模型無法充分利用資源。
| 方案 | 特點 | 適用場景 | 局限 |
|---|---|---|---|
| NIO + java.util.concurrent | JDK 原生，底層控制力強 | 自定義協議、高效能網關 | API 低階，開發難度高，模組組合困難 |
| SEDA (Staged Event-Driven Architecture) | 階段式管道，自適應線程池 | 高併發伺服器框架 | 粗粒度階段，死鎖風險，同步代碼隔離困難 |
| E 語言 / Promise 模型 | vat/promise/when 語法原生支援異步 | 複雜並發原型、分散式系統 | 動態語言，生產環境成熟度待驗證 |
| AsyncObjects 框架 | 純 Java 實現 Promise/Vat，整合同步 API | 漸進式遷移既有同步代碼 | 生態系匱乏，僅實現網路 I/O |
| Servlet 容器專有 API | Jetty Continuation, Tomcat Comet, JBoss Web | Comet/長輪詢、HTTP 流式傳輸 | 鎖定容器，無法統一業務邏輯異步化 |
| JAX-WS 2.0 / Axis2 非阻塞客戶端 | Web Service 異步調用，回調/輪詢/Future | 聚合多外部 SOAP/REST 服務 | 僅解決客戶端調用，伺服端仍同步 |
| JSR 203 (NIO.2) | 非同步 Channel、CompletionHandler、IoFuture | 檔案/網路 I/O 現代化 | 低階 API，缺乏高階元件抽象 |
Java 平台正處於「同步阻塞」向「異步非阻塞」過渡期。Servlet 3.0 (JSR 315) 引入 AsyncContext、ServletRequest.startAsync() 等標準 API，標誌著 Java EE 正式擁抱異步。結合 NIO.2、JAX-RS 2.0 非阻塞客戶端、JMS 2.0 異步消息，新一代 Java 異步生態系統正在形成。架構師應提前佈局，將核心業務邏輯解耦為事件驅動模式，為全面異步化鋪路。
