JVM:JVM讀後筆記（一）jvm調優

如下的整理是我我的的理解，並用本身的話進行整理，若有錯誤，歡迎各位指出完善

1、高性能硬件程序部署策略

當對服務器的硬件需求過大的時，有兩種解決方案：1）使用64位jdk增大內存；2）使用若干個32位虛擬機創建集羣利用資源

可能的緣由與結果：建議使用第二種方案，第一種方案易產生大對象，並佔用老年代的空間，gc回收時易產生長時間的停頓

2、集羣間同步致使內存溢出

在集羣間設置一個全局緩存，用於同步各個服務器之間的信息，如：登陸信息等等，容易致使內存溢出

可能的緣由與結果：服務器頻繁出現同步信息，致使大量同步信息堆積內存，應避免大量頻繁的寫操做

3、堆外內存致使的溢出錯誤

服務器出現OOM的報錯，查看服務器，gc不頻繁，Eden區、Survivor區、老年代和永久代內存都正常

可能的緣由與結果：Java堆和永久代分配的內存夠用，但剩下的內存不足，內存滿了，而老年代的內存不足以回收，致使堆外內存沒有辦法回收，從而致使堆外內存OOM。除了Java堆和永久代內存，還要注意的內存限制有：Direct Memory，線程堆棧，Socket緩存區，JNI代碼，虛擬機和GC

4、外部命令致使系統緩慢

代碼中使用Java調用shell腳本，服務器的cpu和內存消耗很高

可能的緣由與結果：Java調用shell腳本，即便shell腳本的速度很快，但頻繁的調用會致使cpu和內存負擔增長。應使用Java自帶的API獲取信息

5、服務器JVM進程崩潰

兩臺機器之間進行交互是出現hs_err_pid###.log，並留下SocketException：Connect reset的錯誤

可能的緣由與結果：當一臺服務器向另外一臺服務器進行頻繁的請求時，服務器沒法迅速響應，致使大量請求堆積從而致使的請求超時。建議使用生產者/消費者模式的消息隊列，減輕接受請求的服務器的壓力

6、不恰當數據結構致使內存佔用過大

服務器內存足夠使用，沒隔一段時間加載一個大文件數據進入內存，在內存中造成大量的HashMap<Long, Long> Entry， Minor GC會形成停頓

可能的緣由與結果：大量數據進入內存，佔用新生代，致使內存飽滿，解決方法：是數據進入內存時就當即進入老年代，但這種方法治標不治本，不能採用，實際中仍是要避免使用大量的HashMap。

ps：直接進入老年代的方法，設置jvm參數：-XX:MaxTenuringThreshold=0或者-XX:+AlwaysTenure

7、由windows虛擬內存致使的長時間停頓

使用windows的GUI時，界面最小化/恢復時會出現長時間的停頓

可能的緣由與結果：界面最小化時，將工做內存交換到磁盤上，在回覆頁面時致使停頓，

解決方法：加入參數：-Dsun.awt.keepWorkingSetOnMinimize=true，能夠保證快速相應最小化時的恢復