在操作系統(tǒng)還沒有虛擬內(nèi)存空間的年代，每個進程都是訪問物理內(nèi)存，進程間通信最為簡單，約定好內(nèi)存地址就行了，比如說進程A，從0x23開始，連續(xù)放100個字節(jié)的數(shù)據(jù)，進程B從物理內(nèi)存中將這份數(shù)據(jù)拷貝走即可。

不過這種操作系統(tǒng)現(xiàn)在我們用不著了，現(xiàn)在每個進程的內(nèi)存空間都是虛擬的，互不相干的。接下來最好理解的就是通過硬盤文件來進行通信。進程A在C盤根目錄產(chǎn)生一個a.txt文件，進程B將文件打開，將內(nèi)容讀取出來即可。

其實，也不是非要一個硬盤中文件，也可以是一個操作系統(tǒng)的文件句柄，傳遞的內(nèi)容不必真的放在硬盤中，比如說windows的內(nèi)存共享機制，unix的通道機制，不過這些機制現(xiàn)在的普通碼農(nóng)可能早就不關心了。

采用文件來傳遞信息，在很多嚴肅的系統(tǒng)間，還是唯一能被雙方接收的方案。A公司和B公司合作，A公司為B公司提供重要數(shù)據(jù)。最靠譜的做法就是A公司啟用一個FTP服務器，將數(shù)據(jù)生成文件，將FTP訪問權限開發(fā)給B公司。B公司定時將文件取走。別看這樣老土，但是仔細想想，這是最容易責任倒查的方式，某種程度上，白紙黑字無可抵賴，誰對誰錯一目了然。

接下來要講的就是通過TCP來跨進程通信，不管什么高大上的Web Service，本質(zhì)上就是通過TCP來通信。兩個進程間建立網(wǎng)絡連接就可以互相發(fā)信息，至于信息格式，如何解析如何組包，這都是細節(jié)層面的東西，本文不想去細說。

到了現(xiàn)在，各種成熟的跨進程通信的方案，基本上都是走網(wǎng)絡連接了。各種方案基本功能都沒有問題，難就難在一些高級特性能否支持，比如說能不能將通信內(nèi)容持久化(保留一段時間，方便定位故障和責任倒查)，對通信內(nèi)容進行可以方便的查詢和過濾，通信的雙方支持透明的集群和冗余等等。