架構設計：生產者/消費者模式[0]：概述

文章目錄

★簡介
★優點
★本系列的目錄
　　今天打算來介紹一下“生產者／消費者模式”，這玩意兒在很多開發領域都能派上用場。鑑於該模式很重要且相關內容比較豐富，俺打算分幾個帖子逐一介紹。今天先來掃盲一把。如果你對這個模式已經比較瞭解，請跳過本帖子，直接看下一個帖子（關於如何確定資料單元）。
　　看到這裡，可能有同學心中犯嘀咕了：在四人幫（Gang Of Four）的23種模式裡面似乎沒聽說過這種嘛！其實 GOF 那經典的23種模式主要是基於 OO 的（從書名《Design Patterns: Elements of Reusable Object-Oriented Software》就可以看出來）。而 Pattern 實際上即可以是 OO 的 Pattern，也可以是非 OO 的 Pattern 的。

★簡介

　　言歸正傳！在實際的軟體開發過程中，經常會碰到如下場景：某個模組負責產生資料，這些資料由另一個模組來負責處理（此處的模組是廣義的，可以是類、函式、執行緒、程式等）。產生資料的模組，就形象地稱為【生產者】；而處理資料的模組，就稱為【消費者】。
　　單單抽象出生產者和消費者，還夠不上是生產者／消費者模式。該模式還需要有一個緩衝區處於生產者和消費者之間，作為一箇中介。生產者把資料放入緩衝區，而消費者從緩衝區取出資料。大概的結構如下圖。

　　為了不至於太抽象，我們們舉一個寄信的例子（雖說這年頭寄信已經不時興，但這個例子還是比較貼切的）。假設你要寄一封平信，大致過程如下：
1、你把信寫好——相當於生產者製造資料
2、你把信放入郵筒——相當於生產者把資料放入緩衝區
3、郵遞員把信從郵筒取出——相當於消費者把資料取出緩衝區
4、郵遞員把信拿去郵局做相應的處理——相當於消費者處理資料

★優點

　　可能有同學會問了：這個緩衝區有什麼用捏？為什麼不讓生產者直接呼叫消費者的某個函式，直接把資料傳遞過去捏？搞出這麼個緩衝區作甚？
　　其實這裡面是大有講究的，大概有如下一些好處。

◇解耦

　　假設生產者和消費者分別是兩個類。如果讓生產者直接呼叫消費者的某個方法，那麼生產者對於消費者就會產生依賴（也就是耦合）。將來如果消費者的程式碼發生變化，可能會影響到生產者。而如果兩者都依賴於某個緩衝區，兩者之間不直接依賴，耦合也就相應降低了。
　　接著上述的例子，如果不使用郵筒（也就是緩衝區），你必須得把信直接交給郵遞員。有同學會說，直接給郵遞員不是挺簡單的嘛？其實不簡單，你必須得認識誰是郵遞員，才能把信給他（光憑身上穿的制服，萬一有人假冒，就慘了）。這就產生和你和郵遞員之間的依賴（相當於生產者和消費者的【強】耦合）。萬一哪天郵遞員換人了，你還要重新認識一下（相當於消費者變化導致修改生產者程式碼）。而郵筒相對郵遞員來說比較固定，你依賴它的成本也就比較低（相當於和緩衝區之間的【弱】耦合）。

◇支援併發（concurrency）

　　生產者直接呼叫消費者的某個方法，還有另一個弊端。由於函式呼叫是同步的（或者叫阻塞的），在消費者的方法沒有返回之前，生產者只好一直等在那邊。萬一消費者處理資料很慢，生產者就會白白糟蹋大好時光。
　　使用了生產者／消費者模式之後，生產者和消費者可以是兩個獨立的併發主體（常見的併發型別有程式和執行緒兩種，後面的帖子會講兩種併發型別下的應用）。生產者把製造出來的資料往緩衝區一丟，就可以再去生產下一個資料。基本上不用依賴消費者的處理速度。
　　其實當初這個模式，主要就是用來處理併發問題的。
　　從寄信的例子來看。如果沒有郵筒，你得拿著信傻站在路口等郵遞員過來收（相當於生產者阻塞）；又或者郵遞員得挨家挨戶問，誰要寄信（相當於消費者輪詢）。不管是哪種方法，都挺土的。

◇支援忙閒不均

　　緩衝區還有另一個好處。如果製造資料的速度時快時慢，緩衝區的好處就體現出來了。當資料製造快的時候，消費者來不及處理，未處理的資料可以暫時存在緩衝區中。等生產者的製造速度慢下來，消費者再慢慢處理掉。
　　為了充分複用、節省打字，俺再拿寄信的例子來說事兒。假設郵遞員一次只能帶走1000封信。萬一某次碰上情人節（也可能是聖誕節）送賀卡，需要寄出去的信超過1000封，這時候郵筒這個緩衝區就派上用場了。郵遞員把來不及帶走的信暫存在郵筒中，等下次過來時再拿走。
　　費了這麼多口水，希望原先不太瞭解生產者／消費者模式的同學能夠明白它是怎麼一回事。下一個帖子，首先聊一下“如何確定資料單元”。

★本系列的目錄

　　為了方便閱讀，把本系列帖子的目錄整理如下（需翻牆）： 
1. 如何確定資料單元
2. 佇列緩衝區
3. 環形緩衝區
4. 雙緩衝區