從 Unix 早期到現代 Linux，IPC 機制隨著硬體能力、應用複雜度、效能需求演進。沒有「最好」的 IPC，只有「最適合」的 IPC。 選型取決於：資料量、同步需求、進程關係、效能要求、可移植性。
| 方隊 | 類比 | 核心特徵 | 優勢 | 劣勢 | 適用場景 |
|---|---|---|---|---|---|
| 信號 | 號角/旗語 | 異步通知，攜帶極少資訊 (僅信號編號) | 簡單、開銷極小、內核支援完善 | 不可攜帶資料、不可靠(可能丟失)、處理複雜 | 進程終止通知、定時器、異常處理、簡單事件觸發 |
| 無名管道 | 父子專用水管 | 半雙工、僅限有親緣關係進程、資料流 | 簡單、自動同步、無需命名 | 單向、僅限父子/兄弟進程、無名稱無法獨立開啟 | Shell 管道、父子進程簡單資料傳遞 |
| 命名管道 (FIFO) | 社區公共水管 | 有名稱、任意進程可開啟、半雙工、資料流 | 突破親緣限制、檔案系統可見、支援非阻塞 | 單向、資料流無邊界、效能受限於檔案系統 | 無關進程間通信、日誌收集、簡單客戶端-伺服器 |
| 訊息隊列 | 郵政信箱系統 | 訊息為單位、帶類型/優先級、雙向、核心持久化 | 訊息邊界明確、支援優先級、斷開連線資料不丟失 | 複製開銷大、系統限制(訊息大小/隊列數)、非即時 | 任務分發、異步通知、跨進程命令傳遞 |
| 共享記憶體 | 共享白板 | 多進程映射同一物理頁面、最快、無內核複製 | 效能最高、雙向、資料結構任意 | 需自行同步(信號量/鎖)、無保護機制、程式設計複雜 | 大量資料高頻交換、影像/音訊緩衝、高效能運算 |
| 信號量 | 交通號誌指揮官 | 計數器原語、解決同步互斥、非資料傳輸 | 原子操作、系統級同步、支援撤銷機制 | 不傳輸資料、API 複雜、易死鎖 | 保護共享記憶體、協調多進程存取、資源計數 |
需要傳輸資料嗎？
├── 否 → 只需同步/互斥 → 信號量
└── 是 → 進程有親緣關係？
├── 是 → 資料量小、單向 → 無名管道
│ 資料量大、雙向 → 共享記憶體 + 信號量
└── 否 → 需要訊息邊界/優先級？
├── 是 → 訊息隊列
└── 否 → 需要最高效能？
├── 是 → 共享記憶體 + 信號量
└── 否 → 命名管道 / UNIX Domain Socket「IPC 選型的鐵律：先正確，再快速，最後才是優雅。」
