架構設計：生產者/消費者模式 第1頁：「生產者／消費者模式」介紹

★簡介

    在實際的軟件開發過程當中，常常會碰到以下場景：某個模塊負責產生數據，這些數據由另外一個模塊來負責處理（此處的模塊是廣義的，能夠是類、函數、線程、進程等）。產生數據的模塊，就形象地稱爲生產者；而處理數據的模塊，就稱爲消費者。

    單單抽象出生產者和消費者，還夠不上是生產者／消費者模式。該模式還須要有一個緩衝區處於生產者和消費者之間，做爲一箇中介。生產者把數據放入緩衝區，而消費者從緩衝區取出數據。大概的結構以下圖。

    爲了避免至於太抽象，咱們舉一個寄信的例子（雖然說這年頭寄信已經不時興，但這個例子仍是比較貼切的）。假設你要寄一封平信，大體過程以下：

    一、你把信寫好——至關於生產者製造數據

    二、你把信放入郵筒——至關於生產者把數據放入緩衝區

    三、郵遞員把信從郵筒取出——至關於消費者把數據取出緩衝區

    四、郵遞員把信拿去郵局作相應的處理——至關於消費者處理數據

    ★優勢

    可能有同窗會問了：這個緩衝區有什麼用捏？爲何不讓生產者直接調用消費者的某個函數，直接把數據傳遞過去？搞出這麼一個緩衝區做甚？

    其實這裏面是大有講究的，大概有以下一些好處。

    ◇解耦

    假設生產者和消費者分別是兩個類。若是讓生產者直接調用消費者的某個方法，那麼生產者對於消費者就會產生依賴（也就是耦合）。未來若是消費者的代碼發生變化，可能會影響到生產者。而若是二者都依賴於某個緩衝區，二者之間不直接依賴，耦合也就相應下降了。

    接着上述的例子，若是不使用郵筒（也就是緩衝區），你必須得把信直接交給郵遞員。有同窗會說，直接給郵遞員不是挺簡單的嘛？其實不簡單，你必須得認識誰是 郵遞員，才能把信給他（光憑身上穿的制服，萬一有人假冒，就慘了）。這就產生和你和郵遞員之間的依賴（至關於生產者和消費者的強耦合）。萬一哪天郵遞員換 人了，你還要從新認識一下（至關於消費者變化致使修改生產者代碼）。而郵筒相對來講比較固定，你依賴它的成本就比較低（至關於和緩衝區之間的弱耦合）。

    ◇支持併發（concurrency）

    生產者直接調用消費者的某個方法，還有另外一個弊端。因爲函數調用是同步的（或者叫阻塞的），在消費者的方法沒有返回以前，生產者只好一直等在那邊。萬一消費者處理數據很慢，生產者就會白白糟蹋大好時光。

    使用了生產者／消費者模式以後，生產者和消費者能夠是兩個獨立的併發主體（常見併發類型有進程和線程兩種，後面的帖子會講兩種併發類型下的應用）。生產者把製造出來的數據往緩衝區一丟，就能夠再去生產下一個數據。基本上不用依賴消費者的處理速度。

    其實當初這個模式，主要就是用來處理併發問題的。

    從寄信的例子來看。若是沒有郵筒，你得拿着信傻站在路口等郵遞員過來收（至關於生產者阻塞）；又或者郵遞員得挨家挨戶問，誰要寄信（至關於消費者輪詢）。無論是哪一種方法，都挺土的。

    ◇支持忙閒不均

    緩衝區還有另外一個好處。若是製造數據的速度時快時慢，緩衝區的好處就體現出來了。當數據製造快的時候，消費者來不及處理，未處理的數據能夠暫時存在緩衝區中。等生產者的製造速度慢下來，消費者再慢慢處理掉。

    爲了充分複用，咱們再拿寄信的例子來講事。假設郵遞員一次只能帶走1000封信。萬一某次碰上情人節（也多是聖誕節）送賀卡，須要寄出去的信超過1000封，這時候郵筒這個緩衝區就派上用場了。郵遞員把來不及帶走的信暫存在郵筒中，等下次過來時再拿走。