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

   前幾那天寫了一個Java程序模擬生產(chǎn)者消費者，當(dāng)時寫完還感覺不錯，但是這幾天再看的時候發(fā)現(xiàn)還是有很多的不足之處，給別人挑毛病不大好意思，尺度拿捏不好還容易得罪人，男人就對自己狠一點，我就給自己多挑挑程序的毛病，這個可以有，有些細(xì)微的毛病就馬上改了，有些有難度的，我也記錄下來，不斷的改進(jìn)，看起來簡單的程序?qū)懞昧瞬潘闶且粋€合格的程序員。

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

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

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

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

2. 第二種模式的消費者申請的消費產(chǎn)品數(shù)和規(guī)格不符，應(yīng)該為10的倍數(shù)，第二種模式?jīng)]有取整，這樣看起來不是很清晰。

3. 第一種和第二種模式，生產(chǎn)者和消費者對應(yīng)的產(chǎn)品數(shù)不能為0，這種場景其實不應(yīng)該存在的，所以就可以考慮從隨機數(shù)或者從對象層級進(jìn)行校驗，至少規(guī)范來看，入?yún)⒁?guī)范，所以我從隨機數(shù)生成邏輯上進(jìn)行校驗控制。

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

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

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

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

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

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

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

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

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