隨心所欲

弄了一段時間的tokyocabinet btree結構數據庫。
存儲的時候發現，tokyocabinet sync同步時，先讓數據存放在內存，然后對比同步文件和內存的數據，使數據達到一直。
sync()這個tc方法易用，但不好控制。
稍有不慎就會使持久化文件容量以幾何級數遞增。

之前自己用mina框架做了一個btree的網絡鏈接端口，起初內存一直飆升。弄了很久都不明白。
開始以為是mina造成的，而且cpu占用率居高不下。

后來拆分測試。發現單獨mina的數據傳輸，內存并不高，非常低。
但是tc的單獨測試發現，寫文件的cpu占用率特高，多線程寫入的情況下，會有明顯阻塞。
初步了解了jvm gc的算法，如果cpu占用率搞，gc回收內存的能力會明顯下降。
為了解決這一點，修改了一下網絡端口的框架結構。

把數據接受端跟數據處理端分開：
1.接受端可以接受多個socket多線程傳輸，而數據處理端鎖定只接受從接收端的一個或不超過5個scoket傳輸數據。
對tc的操作，單線程寫入，感覺上比多線程處理流暢，特別在同步優化文件那一刻。
優化文件，需要的cpu和內存都比較厲害。
2.tc接受數據以后，不要馬上寫文本。等接受一批（100-10000）數據后，再使用同步方法。
3.參照第2條，定期優化文件，這樣不至于文件過大。但是數據量增大，文件雖然優化了，寫入速度不會怎么改變。
4.優化同步文件后，特別在數據量在不斷增大的情況下。不要以為沒有回收內存，其實gc已經很努力回收(長時間觀察jprofiler的統計數據證明了這一點)當你向tc取數據的時候，你會發現，內存會逐級遞減。


經過一番調整，用jprofiler測試，自己搭建的網絡框架，內存鎖定在250m左右。
可能到實際運行的時候，內存占用量會增加，但是只會達到一個相當的穩定值。
現用于公司的隊列系統，內存總量不超過600m，偶爾超過是由于同步文件造成的，等數據穩定后，內存會回到穩定值。以后再作優化，希望能把內存壓制200m左右。

初學nio，以此為記。