感冒了，在家里休息，打開電腦隨便看看，想起前兩天有人問的一個事情：“內存溢出怎么分析和處理？”方案有很多了，基本上的思路就是獲取系統狀態，內存變化方向，內存對象等之類的，profile，debug，jmx，dump等等。

我更想說的是，為什么會內存溢出呢？

在我看來，干活有兩種方式：

• 沒想清楚了，貿貿然開干，然后各處救火各種解決問題
• 想清楚了再開干，無驚無險，安然做完

一般來說，我都是后者，所以真的很少碰到各種莫名其妙的問題，比如自己實現排序算法、在內存中處理有100000個值的列表、不用第三個變量來交換兩個變量的值等等。

怎么避免內存溢出

吐槽完畢，來說說對于內存溢出這種事情是要怎么避免，我所謂的“想清楚了再開干”到底是怎么想清楚的。

首先內存溢出的本質是什么？“內存使用超出了預期”。 
那么要怎么避免呢？“預期內存怎么使用，將其控制在內存使用范圍呢”。

如何預期內存的使用

Java程序中，內存是被怎么占用的？被數據和對象占用的，數據和對象怎么來的?

• 應用的輸入和輸出
• 第三方系統的輸入和輸出
• 應用本身產生的數據

如何控制內存的使用

應用輸入和輸出怎么控制

• 控制允許輸入的線程數，比如允許同時多少個線程提供服務
• 控制輸入的請求對象的大小和內容，比如輸入時的所允許的緩沖區大小
• 輸出的線程數是和輸入的線程對應的，如果是主動輸出的，那么就控制一下
• 輸出的服務對象的大小和內容，比如你是文件服務器，那么設置一個輸出緩存，每10K就Flush一下。

第三方系統的輸入和輸出怎么控制

思路和應用輸入和輸出怎么控制所說的是一樣的，控制線程數，使用緩存控制。

應用本身產生的數據怎么控制

思路也是一樣的，線程數，緩存，再加上生存時間，對象池等等。

還有？

使用上述技巧和思路你就能控制好你應用中的內存了，但是所有的設計都是在風險和滿足需求之間的平衡，如果再退一步，那么你需要考慮一下Java虛擬機中內存各個區的使用了。你需要區分好哪些是常駐對象，哪些是臨時對象，新生代，舊生代，怎么安排你的虛擬機中各個內存區的大小。希望你不需要用到，如果需要的話，可以看看《深入理解Java虛擬機》這本書。

來個例子

有這么一個應用，它獲取客戶端的請求，驗證請求的合法性，然后對于合法的請求，從第三方系統獲取文件內容，并把文件內容寫回給客戶端。 
下面是一大片的空白，再滾動下去之前看我的設計之前，讀者可以就這個需求想想你會怎么處理。 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|

應用本身的的輸入和輸出的控制

• 同時服務數設置為可配置的屬性，來控制并行的服務數
• 請求只允許Get請求，請求內容只有Header和URL，設置一個輸入Buffer
• 輸出，設置輸出緩存區的大小，可配置的，默認情況下，每20K Flush一下。

第三方系統的輸入和輸出

第三方系統有兩個，一個是合法性驗證的，一個是文件內容的。 
合法性驗證的請求和輸出的內容都比較小。但是考慮到其服務器的性能，把合法性驗證的交互過程放到一個線程池中控制。這樣能避免合法性驗證服務不過來的情況。

文件內容第三方系統的輸入和輸出的控制

• 和合法性驗證一樣，文件內容第三方系統的輸入和輸出能力有限，將其訪問用線程池控制起來。
• 文件內容第三方系統的請求訪問對象較小，不予控制
• 整個系統的最重點來了！文件內容第三方系統的返回文件大小不可控制。所以使用緩存機制，每次讀入20K（可配置），然后寫給系統的客戶端，然后再讀20K，然后再寫，讓文件內容從這個系統中像水一樣流過去。流不動了（第三方系統連接或者客戶端連接失?。┚妥尡敬畏帐　＿@個流過去就是重點了，不管這個文件多大，每次請求只占用20K。

應用本身產生的數據

最原始的需求中還有一個把文件內容緩存在本地，然后可以多次寫給客戶端的這么一個想法，減少網絡等待。這個想法被我否決了，原因如下：

• 首先可以通過HTTP 304狀態碼來減少同一客戶端對同樣內容的多次讀取。
• 如果不對這個文件內容進行管理，將導致硬盤空間溢出。如果對其管理，會添加很多的開發、運維和設計的工作，得不償失。

總結

想清楚了再開干就是這個意思，花點時間系統的想想，想清楚了，前面多寫點代碼，多寫點單元測試，后面少點麻煩，不用救火，也不用加班。 
吃飯去了。

再多啰嗦一句，《JUnit收費課程》的第二節的材料已經準備好了，昨晚擔心自己的塞著鼻子，大家聽著難受，沒有錄。今天好多了，晚上錄一下，明天上午編輯審核，明天下午或者晚上大家應該就能看到了。