核心觀點#

作者透過幾個具體實作場景，深入探討導入平行化（Concurrency）設計時的考量點。
平行化雖強大，但若不理解底層運作原理與邊界條件，易引入難察覺的錯誤。

主要探討三個面向：效能瓶頸的判斷、執行路徑的複雜度，以及如何處理相依方法的鎖定策略。

案例一：客戶端／伺服器應用程式 (Client/Server)#

效能瓶頸的診斷#

假設有個伺服器監聽 Socket 請求。如果系統無法在規定時間內（例如 10 秒）處理完，
我們須先判斷瓶頸在哪，才能決定是否引入平行化。

2. 單一職責原則 (SRP) 的應用#

引入平行化後，原本單純的伺服器類別可能會變臃腫。它可能同時負責：

1. Socket 連線管理
2. 客戶端請求的處理邏輯
3. 執行緒的調度策略
4. 伺服器關閉策略

設計建議：
為降低日後管理與修改難度，應將「平行化相關的程式碼」
（如執行緒管理）從「業務邏輯」中剝離，拆分到獨立的少量類別中。

案例二：執行路徑的複雜度#

看似簡單的程式碼#

考慮以下簡單的 ID 產生器：

public class IdGenerator {
    int lastIdUsed;

    public int incrementValue() {
        return ++lastIdUsed;
    }
}

驚人的路徑組合#

++lastIdUsed 看似只有一個動作，但在 Bytecode 層級，它包含了讀取、修改、寫入等多個指令。

• 單執行緒： 只有 1 種執行路徑，結果確定

• 多執行緒 (T 個)： 假設該行程式碼轉換為 8 個 Bytecode 指令。
  當有 T 個執行緒同時執行時，可能的執行順序高達 (8T)! / ( 8!)^T 種。這是個天文數字

• 加上 Synchronized：

  public synchronized void incrementValue() {
      ++lastIdUsed;
  }

路徑數量大幅收斂為 T! 種，確保了原子性（Atomicity）。

單行程式碼編譯後可能變成多行指令。
沒有適當保護的情況下，多個執行緒會在這些指令「間隙」中穿插執行，導致資料不一致。

設計時必須考量：

1. 哪裡有共用物件？
2. 哪些操作會導致讀取/更新衝突？
3. 如何防止？

案例三：相依方法的鎖定策略#

1. 了解你的工具#

不要盲目使用多執行緒，應了解現有框架提供的解案：

2. 處理方法相依性 (Method Dependencies)#

當類別中的方法間存在相依性（例如：先檢查 hasNext() 再呼叫 next()），平行化可能會破壞邏輯。
以下是三種應對策略：