JVM調優(yōu)總結：調優(yōu)方法
JVM調優(yōu)工具
Jconsole，jProfile，VisualVM
Jconsole：jdk自帶，功能簡單，但是可以在系統(tǒng)有一定負荷的情況下使用。對垃圾回收算法有很詳細的跟蹤。詳細說明參考這里
JProfiler：商業(yè)軟件，需要付費。功能強大。詳細說明參考這里
VisualVM：JDK自帶，功能強大，與JProfiler類似。推薦。
如何調優(yōu)
觀察內存釋放情況、集合類檢查、對象樹
上面這些調優(yōu)工具都提供了強大的功能，但是總的來說一般分為以下幾類功能
堆信息查看
可查看堆空間大小分配（年輕代、年老代、持久代分配） 提供即時的垃圾回收功能 垃圾監(jiān)控（長時間監(jiān)控回收情況）
查看堆內類、對象信息查看：數(shù)量、類型等
對象引用情況查看
有了堆信息查看方面的功能，我們一般可以順利解決以下問題：
--年老代年輕代大小劃分是否合理
--內存泄漏
--垃圾回收算法設置是否合理
線程監(jiān)控
線程信息監(jiān)控：系統(tǒng)線程數(shù)量 線程狀態(tài)監(jiān)控：各個線程都處在什么樣的狀態(tài)下
Dump線程詳細信息：查看線程內部運行情況 死鎖檢查
熱點分析
CPU熱點：檢查系統(tǒng)哪些方法占用的大量CPU時間
內存熱點：檢查哪些對象在系統(tǒng)中數(shù)量***（一定時間內存活對象和銷毀對象一起統(tǒng)計）
這兩個東西對于系統(tǒng)優(yōu)化很有幫助。我們可以根據(jù)找到的熱點，有針對性的進行系統(tǒng)的瓶頸查找和進行系統(tǒng)優(yōu)化，而不是漫無目的的進行所有代碼的優(yōu)化。
快 照
快照是系統(tǒng)運行到某一時刻的一個定格。在我們進行調優(yōu)的時候，不可能用眼睛去跟蹤所有系統(tǒng)變化，依賴快照功能，我們就可以進行系統(tǒng)兩個不同運行時刻，對象（或類、線程等）的不同，以便快速找到問題
舉例說，我要檢查系統(tǒng)進行垃圾回收以后，是否還有該收回的對象被遺漏下來的了。那么，我可以在進行垃圾回收前后，分別進行一次堆情況的快照，然后對比兩次快照的對象情況。
內存泄漏檢查
內存泄漏是比較常見的問題，而且解決方法也比較通用，這里可以重點說一下，而線程、熱點方面的問題則是具體問題具體分析了。
內存泄漏一般可以理解為系統(tǒng)資源（各方面的資源，堆、棧、線程等）在錯誤使用的情況下，導致使用完畢的資源無法回收（或沒有回收），從而導致新的資源分配請求無法完成，引起系統(tǒng)錯誤。
內存泄漏對系統(tǒng)危害比較大，因為他可以直接導致系統(tǒng)的崩潰。
需要區(qū)別一下，內存泄漏和系統(tǒng)超負荷兩者是有區(qū)別的，雖然可能導致的最終結果是一樣的。內存泄漏是用完的資源沒有回收引起錯誤，而系統(tǒng)超負荷則是系統(tǒng)確實沒有那么多資源可以分配了（其他的資源都在使用）。
年老代堆空間被占滿
異常：java.lang.OutOfMemoryError: Java heap space
說明：
這是最典型的內存泄漏方式，簡單說就是所有堆空間都被無法回收的垃圾對象占滿，虛擬機無法再在分配新空間。
如上圖所示，這是非常典型的內存泄漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點，所有谷底部分表示是一次垃圾回收后剩余的內存。連接所有谷底的點，可以發(fā)現(xiàn)一條由底到高的線，這說明，隨時間的推移，系統(tǒng)的堆空間被不斷占滿，最終會占滿整個堆空間。因此可以初步認為系統(tǒng)內部可能有內存泄漏。（上面的圖僅供示例，在實際情況下收集數(shù)據(jù)的時間需要更長，比如幾個小時或者幾天）
解 決：
這種方式解決起來也比較容易，一般就是根據(jù)垃圾回收前后情況對比，同時根據(jù)對象引用情況（常見的集合對象引用）分析，基本都可以找到泄漏點。
持久代被占滿
異常：java.lang.OutOfMemoryError: PermGen space
說明：
Perm空間被占滿。無法為新的class分配存儲空間而引發(fā)的異常。這個異常以前是沒有的，但是在Java反射大量使用的今天這個異常比較常見了。主要原因就是大量動態(tài)反射生成的類不斷被加載，最終導致Perm區(qū)被占滿。
更可怕的是，不同的classLoader即便使用了相同的類，但是都會對其進行加載，相當于同一個東西，如果有N個classLoader那么他將會被加載N次。因此，某些情況下，這個問題基本視為無解。當然，存在大量classLoader和大量反射類的情況其實也不多。
解 決：
1. -XX:MaxPermSize=16m
2. 換用JDK。比如JRocket。
堆棧溢出
異常：java.lang.StackOverflowError
說明：這個就不多說了，一般就是遞歸沒返回，或者循環(huán)調用造成
線程堆棧滿
異常：Fatal: Stack size too small
說明：java中一個線程的空間大小是有限制的。JDK5.0以后這個值是1M。與這個線程相關的數(shù)據(jù)將會保存在其中。但是當線程空間滿了以后，將會出現(xiàn)上面異常。
解決：增加線程棧大小。-Xss2m。但這個配置無法解決根本問題，還要看代碼部分是否有造成泄漏的部分。
系統(tǒng)內存被占滿
異常：java.lang.OutOfMemoryError: unable to create new native thread
說明：
這個異常是由于操作系統(tǒng)沒有足夠的資源來產(chǎn)生這個線程造成的。系統(tǒng)創(chuàng)建線程時，除了要在Java堆中分配內存外，操作系統(tǒng)本身也需要分配資源來創(chuàng)建線程。因此，當線程數(shù)量大到一定程度以后，堆中或許還有空間，但是操作系統(tǒng)分配不出資源來了，就出現(xiàn)這個異常了。
分配給Java虛擬機的內存愈多，系統(tǒng)剩余的資源就越少，因此，當系統(tǒng)內存固定時，分配給Java虛擬機的內存越多，那么，系統(tǒng)總共能夠產(chǎn)生的線程也就越少，兩者成反比的關系。同時，可以通過修改-Xss來減少分配給單個線程的空間，也可以增加系統(tǒng)總共內生產(chǎn)的線程數(shù)。
解 決：
1. 重新設計系統(tǒng)減少線程數(shù)量。
2. 線程數(shù)量不能減少的情況下，通過-Xss減小單個線程大小。以便能生產(chǎn)更多的線程。
原文鏈接：http://pengjiaheng.iteye.com/blog/552456
【編輯推薦】
