PIPE和FIFO用來實現程序間相互發送非常短小的、頻率很高的訊息；這兩種方式通常適用於兩個程序間的通訊。共享記憶體用來實現程序間共享的、非常龐大的、讀寫操作頻率很高的資料（配合訊號量使用）；這種方式通常適用於多程序間通訊。其他考慮用socket。這裡的“其他情況”，其實是今天主要會碰到的情況：分散式開發。在多程序、多執行緒、多模組所構成的今天最常見的分散式系統開發中，socket是第一選擇。訊息佇列，現在建議不要使用了 ---- 因為找不到使用它們的理由。在實際中，我個人感覺，PIPE和FIFO可以偶爾使用下，共享記憶體都用的不多了。在效率上說，socket有包裝資料和解包資料的過程，所以理論上來說socket是沒有PIPE/FIFO快，不過現在計算機上真心不計較這麼一點點速度損失的。你費勁糾結半天，不如我把socket設計好了，多插一塊CPU來得更划算。另外，程序間通訊的資料一般來說我們都會存入資料庫的，這樣萬一某個程序突然死掉或者整個伺服器死了，也不至於丟失重要資料、便於回滾到之前的狀態。從這個角度考慮，適用共享記憶體的情況也更少了，所以socket使用得更多。再多說一點關於共享記憶體的：共享記憶體的效率確實高，但它的重點在“共享”二字上。如果的確有好些程序共享一大塊資料（如果把每個程序都看做是類的物件的話，那麼共享資料就是這個類的static資料成員），那麼共享記憶體就是一個不二的選擇了。但是在面向物件的今天，我們更多的時候是多執行緒+鎖+執行緒間共享資料。因此共享程序在今天使用的也越來越少了。不過，在面對一些極度追求效率的需求時，共享記憶體就會成為唯一的選擇，比如高頻交易系統。除此以外，一般是不需要特意使用共享記憶體的。另外，PIPE和共享記憶體是不能跨LAN的（FIFO可以但FIFO只能用於兩個程序通訊）。如果你的分散式系統隨著需求的增加而越來越大所以你想把不同的模組放在不同機器上而你之前開發的時候用了PIPE或者共享記憶體，那麼你將不得不對程式碼進行大幅修改......同時，即使FIFO可以跨越LAN，其程式碼的可讀性、易操作性和可移植性、適應性也遠沒有socket大。這也就是為什麼一開始說socket是第一選擇的原因。最後還有個訊號簡單說一下。請注意，是訊號，不是訊號量。訊號量是用於同步執行緒間的物件的使用的（建議題主看我的答案，自認為比較通俗易懂：semaphore和mutex的區別？ - Linux - 知乎）。訊號也是程序間通訊的一種方式。比如在Linux系統下，一個程序正在執行時，你用鍵盤按Ctrl+c，就是給這個程序傳送了一個訊號。程序在捕捉到這個訊號後會做相應的動作。雖然訊號是可以自定義的，但這並不能改變訊號的侷限性：不能跨LAN、資訊量極其有限。在現代的分散式系統中，通常都是訊息驅動：即程序受到某個訊息後，透過對訊息的內容的分析然後做相應的動作。如果你把你的分散式系統設定成訊號驅動的，這就表示你收到一個訊號就要做一個動作而一個訊號的本質其實就是一個數字而已。這樣系統稍微大一點的話，系統將變得異常難以維護；甚至在很多時候，訊號驅動是無法滿足我們的需求的。因此現在我們一般也不用訊號了。因此，請記住：除非你有非常有說服力的理由，否則請用socket。順便給你推薦個基於socket的輕量級的訊息庫：ZeroMQ。