給自己寫的程序條毛病(r12筆記第68天)

   前幾那天寫了一個Java程序模擬生產者消費者，當時寫完還感覺不錯，但是這幾天再看的時候發現還是有很多的不足之處，給別人挑毛病不大好意思，尺度拿捏不好還容易得罪人，男人就對自己狠一點，我就給自己多挑挑程序的毛病，這個可以有，有些細微的毛病就馬上改了，有些有難度的，我也記錄下來，不斷的改進，看起來簡單的程序寫好了才算是一個合格的程序員。

   感興趣的同學可以移步這里，看看之前寫的程序。

http://www.toutiao.com/i6420749007307407873/

   我大體總結了下，從日志中可以看出有這么幾個明顯的小問題。

1. 第一種模式和第二種模式的線程數不同，明顯第二種模式的線程日志有長得多。

2. 第二種模式的消費者申請的消費產品數和規格不符，應該為10的倍數，第二種模式沒有取整，這樣看起來不是很清晰。

3. 第一種和第二種模式，生產者和消費者對應的產品數不能為0，這種場景其實不應該存在的，所以就可以考慮從隨機數或者從對象層級進行校驗，至少規范來看，入參要規范，所以我從隨機數生成邏輯上進行校驗控制。

4. 生產線程和消費線程雖然是動態生成，但是從日志可以看到有明顯的串行執行的痕跡，可以把這個過程做成真正的動態，庫存不足，生產者生產，庫存充足，消費者消費。如果把生產者消費者這個模型看做是一個系統，就好比一個齒輪，一個直接的目標就是讓齒輪轉動的快。

5. 無論第一種模式還是第二種模式，如果碰到條件不滿足的情況就會存在等待的情況，這個等待的頻率可以借鑒一些數據庫層面的經驗，來優化控制一下，比如第一次等待，sleep多少毫秒，第二次sleep多少毫秒，這樣有一個基本的控制范圍，減少中斷的次數。

6. 這個庫存其實就像MySQL面刷臟頁一樣，臟頁數達到多少的時候來觸發生產者生產，能夠盡可能減少生產者等待的頻率，提高消費者消費的頻率。

7. 其實目前的實現，如果細細想來，原本生產者消費者的性能瓶頸現在落到倉庫上，但是目前倉庫應該有幾個門，控制入庫，控制出庫，而不能總是在一個門里，要么把門加寬，要么多加幾個門，入口和出口分開。

8. 為了盡可能提高吞吐量，整個實現過程也可以考慮通過事務的方式來控制，比如放到一個倉庫的表里，對于數據進行實時的變更和查詢，或者使用其他的數據結構。

9. 為了盡可能突破單個倉庫的瓶頸，可以考慮設置多個倉庫，這樣庫存能夠大大大提高，而且是一個線性擴展的方式，當然這就會引進更多的考慮和方案

10. 盡可能提高消費者線程的使用率，比如考慮使用線程池等等方式來實現。

  最后硬湊一個觀點吧，那就是一個牛叉的程序構思好了，能夠在短時間內實現出來，光說不做太虛，能說能做才是真。

  或者說你有更多的建議，也給提提吧，感激不盡。