★簡介 生產者消費者模式並不是GOF提出的23種設計模式之一，23種設計模式都是建立在面向對象的基礎之上的，但其實面向過程的編程中也有很多高效的編程模式，生產者消費者模式便是其中之一，它是我們編程過程中最常用的一種設計模式。 在實際的軟體開發過程中，經常會碰到如下場景：某個模塊負責產生數據，這些數據 ...
★簡介
生產者消費者模式並不是GOF提出的23種設計模式之一，23種設計模式都是建立在面向對象的基礎之上的，但其實面向過程的編程中也有很多高效的編程模式，生產者消費者模式便是其中之一，它是我們編程過程中最常用的一種設計模式。
在實際的軟體開發過程中，經常會碰到如下場景：某個模塊負責產生數據，這些數據由另一個模塊來負責處理（此處的模塊是廣義的，可以是類、函數、線程、進程等）。產生數據的模塊，就形象地稱為生產者；而處理數據的模塊，就稱為消費者。
單單抽象出生產者和消費者，還夠不上是生產者／消費者模式。該模式還需要有一個緩衝區處於生產者和消費者之間，作為一個中介。生產者把數據放入緩衝區，而消費者從緩衝區取出數據。大概的結構如下圖。
1、你把信寫好——相當於生產者製造數據
2、你把信放入郵筒——相當於生產者把數據放入緩衝區
3、郵遞員把信從郵筒取出——相當於消費者把數據取出緩衝區
4、郵遞員把信拿去郵局做相應的處理——相當於消費者處理數據
★優點
可能有同學會問了：這個緩衝區有什麼用捏？為什麼不讓生產者直接調用消費者的某個函數，直接把數據傳遞過去？搞出這麼一個緩衝區作甚？
其實這裡面是大有講究的，大概有如下一些好處。
◇解耦
假設生產者和消費者分別是兩個類。如果讓生產者直接調用消費者的某個方法，那麼生產者對於消費者就會產生依賴（也就是耦合）。將來如果消費者的代碼發生變化，可能會影響到生產者。而如果兩者都依賴於某個緩衝區，兩者之間不直接依賴，耦合也就相應降低了。
接著上述的例子，如果不使用郵筒（也就是緩衝區），你必須得把信直接交給郵遞員。有同學會說，直接給郵遞員不是挺簡單的嘛？其實不簡單，你必須得認識誰是郵遞員，才能把信給他（光憑身上穿的制服，萬一有人假冒，就慘了）。這就產生和你和郵遞員之間的依賴（相當於生產者和消費者的強耦合）。萬一哪天郵遞員換人了，你還要重新認識一下（相當於消費者變化導致修改生產者代碼）。而郵筒相對來說比較固定，你依賴它的成本就比較低（相當於和緩衝區之間的弱耦合）。
◇支持併發（concurrency）
生產者直接調用消費者的某個方法，還有另一個弊端。由於函數調用是同步的（或者叫阻塞的），在消費者的方法沒有返回之前，生產者只好一直等在那邊。萬一消費者處理數據很慢，生產者就會白白糟蹋大好時光。
使用了生產者／消費者模式之後，生產者和消費者可以是兩個獨立的併發主體（常見併發類型有進程和線程兩種，後面的帖子會講兩種併發類型下的應用）。生產者把製造出來的數據往緩衝區一丟，就可以再去生產下一個數據。基本上不用依賴消費者的處理速度。
其實當初這個模式，主要就是用來處理併發問題的。
從寄信的例子來看。如果沒有郵筒，你得拿著信傻站在路口等郵遞員過來收（相當於生產者阻塞）；又或者郵遞員得挨家挨戶問，誰要寄信（相當於消費者輪詢）。不管是哪種方法，都挺土的。
◇支持忙閑不均
緩衝區還有另一個好處。如果製造數據的速度時快時慢，緩衝區的好處就體現出來了。當數據製造快的時候，消費者來不及處理，未處理的數據可以暫時存在緩衝區中。等生產者的製造速度慢下來，消費者再慢慢處理掉。
為了充分復用，我們再拿寄信的例子來說事。假設郵遞員一次只能帶走1000封信。萬一某次碰上情人節（也可能是聖誕節）送賀卡，需要寄出去的信超過1000封，這時候郵筒這個緩衝區就派上用場了。郵遞員把來不及帶走的信暫存在郵筒中，等下次過來時再拿走。
費了這麼多口水，希望原先不太瞭解生產者／消費者模式的同學能夠明白它是怎麼一回事。接下來說說數據單元。
