J2ME 網絡通訊架構設計：HttpConnection 與 SocketConnection 選型與異步實現

J2ME 提供 HttpConnection（應用層 HTTP 協議支持）與 SocketConnection（傳輸層原始 Socket 流）兩種網絡 API。對上層業務邏輯而言，協議選擇應透明化；框架層需提供統一介面、連接復用、超時控制與異步非阻塞能力。

協議選型對比

Socket 雙工通訊設計要點

實現全雙工需應用層協議配合：

1. 請求編碼：每個請求分配唯一序列號
2. 響應匹配：接收線程根據序列號將響應分發至對應回調
3. 線程模型：發送線程 + 接收線程分離，通過隊列解耦

異步請求框架核心需求

• 支持 HTTP GET/POST 與文件下載
• 可選 Socket 或 HTTP 傳輸通道
• 同步/異步統一介面，內置超時機制
• 清晰異常體系（連接超時、協議錯誤、服務器異常等）
• 連接池管理（J2ME 環境下通常輕量級或省略）

同步轉異步模式實現（阻塞 API 線程化）

public void sendRequestAsync(final NetworkRequest req, final long timeout) {
    new Thread(() -> {
        synchronized (req) { // 關鍵：同步塊必須包含發送與等待
            Thread sender = new Thread(() -> {
                try { sendRequest(req); } 
                catch (Exception e) { req.setError(e); }
                finally { synchronized(req) { req.notifyAll(); } }
            });
            sender.start();

            try { req.wait(timeout); } 
            catch (InterruptedException ignored) {}

            if (req.isDelayed()) { // 超時處理
                requestQueue.remove(req);
                timeoutQueue.add(req);
            }
        }
    }).start();
}

關鍵同步陷阱與修正

初版代碼將 synchronized(req) 放在子線程啟動之後，導致竝態條件：發送線程可能在主線程進入 wait() 前已調用 notifyAll()，造成主線程永久等待超時。修正為同步塊包裹線程啟動與等待，確保內存可見性與原子性。

超時後的延遲響應處理

採用雙隊列機制：

• 活躍隊列：正在等待響應的請求
• 超時隊列：已超時但網絡層可能仍在傳輸的請求

延遲響應到達時，活躍隊列無對象則丟棄；超時隊列中對象可觸發降級邏輯（如緩存更新）。

工程化建議

• 統一異常碼：ERR_TIMEOUT, ERR_CONN_REFUSED, ERR_PROTOCOL, ERR_IO
• 引入攔截器鏈：日誌、重試、熔斷、壓縮
• 連接參數化：超時、緩衝區大小、Keep-Alive 策略外部化配置
• 單元測試覆蓋：弱網模擬（丟包、延遲、斷連）、並發壓測

成熟的網絡層框架能屏蔽底層協議差異，讓業務代碼專注於領域邏輯，是 J2ME 應用穩定性的基石。