JVM調(diào)優(yōu)工具

Jconsole，jProfile，VisualVM

?

Jconsole : ? jdk自帶，功能簡(jiǎn)單，但是可以在系統(tǒng)有一定負(fù)荷的情況下使用。對(duì)垃圾回收算法有很詳細(xì)的跟蹤。詳細(xì)說明參考 這里

?

JProfiler ? ：商業(yè)軟件，需要付費(fèi)。功能強(qiáng)大。詳細(xì)說明參考 這里

?

VisualVM ? ：JDK自帶，功能強(qiáng)大，與JProfiler類似。推薦。

?

如何調(diào)優(yōu)

觀察內(nèi)存釋放情況、集合類檢查、對(duì)象樹

上面這些調(diào)優(yōu)工具都提供了強(qiáng)大的功能，但是總的來說一般分為以下幾類功能

?

堆信息查看

? ?

可查看堆空間大小分配（年輕代、年老代、持久代分配）

提供即時(shí)的垃圾回收功能

垃圾監(jiān)控（長(zhǎng)時(shí)間監(jiān)控回收情況）

?

? ?

查看堆內(nèi)類、對(duì)象信息查看：數(shù)量、類型等

?

? ?

對(duì)象引用情況查看

?

有了堆信息查看方面的功能，我們一般可以順利解決以下問題：

? --年老代年輕代大小劃分是否合理

? --內(nèi)存泄漏

? --垃圾回收算法設(shè)置是否合理

?

線程監(jiān)控

? ?

線程信息監(jiān)控：系統(tǒng)線程數(shù)量。

線程狀態(tài)監(jiān)控：各個(gè)線程都處在什么樣的狀態(tài)下

?

? ?

Dump線程詳細(xì)信息：查看線程內(nèi)部運(yùn)行情況

死鎖檢查

?

熱點(diǎn)分析

? ?

?

?

??? CPU熱點(diǎn) ? ：檢查系統(tǒng)哪些方法占用的大量CPU時(shí)間

??? 內(nèi)存熱點(diǎn) ? ：檢查哪些對(duì)象在系統(tǒng)中數(shù)量最大（一定時(shí)間內(nèi)存活對(duì)象和銷毀對(duì)象一起統(tǒng)計(jì)）

?

??? 這兩個(gè)東西對(duì)于系統(tǒng)優(yōu)化很有幫助。我們可以根據(jù)找到的熱點(diǎn)，有針對(duì)性的進(jìn)行系統(tǒng)的瓶頸查找和進(jìn)行系統(tǒng)優(yōu)化，而不是漫無目的的進(jìn)行所有代碼的優(yōu)化。

?

?

快照

??? 快照是系統(tǒng)運(yùn)行到某一時(shí)刻的一個(gè)定格。在我們進(jìn)行調(diào)優(yōu)的時(shí)候，不可能用眼睛去跟蹤所有系統(tǒng)變化，依賴快照功能，我們就可以進(jìn)行系統(tǒng)兩個(gè)不同運(yùn)行時(shí)刻，對(duì)象（或類、線程等）的不同，以便快速找到問題

??? 舉例說，我要檢查系統(tǒng)進(jìn)行垃圾回收以后，是否還有該收回的對(duì)象被遺漏下來的了。那么，我可以在進(jìn)行垃圾回收前后，分別進(jìn)行一次堆情況的快照，然后對(duì)比兩次快照的對(duì)象情況。

?

內(nèi)存泄漏檢查

??? 內(nèi)存泄漏是比較常見的問題，而且解決方法也比較通用，這里可以重點(diǎn)說一下，而線程、熱點(diǎn)方面的問題則是具體問題具體分析了。

??? 內(nèi)存泄漏一般可以理解為系統(tǒng)資源（各方面的資源，堆、棧、線程等）在錯(cuò)誤使用的情況下，導(dǎo)致使用完畢的資源無法回收（或沒有回收），從而導(dǎo)致新的資源分配請(qǐng)求無法完成，引起系統(tǒng)錯(cuò)誤。

??? 內(nèi)存泄漏對(duì)系統(tǒng)危害比較大，因?yàn)樗梢灾苯訉?dǎo)致系統(tǒng)的崩潰。

??? 需要區(qū)別一下，內(nèi)存泄漏和系統(tǒng)超負(fù)荷兩者是有區(qū)別的，雖然可能導(dǎo)致的最終結(jié)果是一樣的。內(nèi)存泄漏是用完的資源沒有回收引起錯(cuò)誤，而系統(tǒng)超負(fù)荷則是系統(tǒng)確實(shí)沒有那么多資源可以分配了（其他的資源都在使用）。

?

?

年老代堆空間被占滿

異常： ? java.lang.OutOfMemoryError: Java heap space

說明：

?

??? 這是最典型的內(nèi)存泄漏方式，簡(jiǎn)單說就是所有堆空間都被無法回收的垃圾對(duì)象占滿，虛擬機(jī)無法再在分配新空間。

??? 如上圖所示，這是非常典型的內(nèi)存泄漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點(diǎn)，所有谷底部分表示是一次垃圾回收后剩余的內(nèi)存。連接所有谷底的 點(diǎn)，可以發(fā)現(xiàn)一條由底到高的線，這說明，隨時(shí)間的推移，系統(tǒng)的堆空間被不斷占滿，最終會(huì)占滿整個(gè)堆空間。因此可以初步認(rèn)為系統(tǒng)內(nèi)部可能有內(nèi)存泄漏。（上面 的圖僅供示例，在實(shí)際情況下收集數(shù)據(jù)的時(shí)間需要更長(zhǎng)，比如幾個(gè)小時(shí)或者幾天）

?

解決：

??? 這種方式解決起來也比較容易，一般就是根據(jù)垃圾回收前后情況對(duì)比，同時(shí)根據(jù)對(duì)象引用情況（常見的集合對(duì)象引用）分析，基本都可以找到泄漏點(diǎn)。

?

?

持久代被占滿

異常： ? java.lang.OutOfMemoryError: PermGen space

說明：

??? Perm空間被占滿。無法為新的class分配存儲(chǔ)空間而引發(fā)的異常。這個(gè)異常以前是沒有的，但是在Java反射大量使用的今天這個(gè)異常比較常見了。主要原因就是大量動(dòng)態(tài)反射生成的類不斷被加載，最終導(dǎo)致Perm區(qū)被占滿。

??? 更可怕的是，不同的classLoader即便使用了相同的類，但是都會(huì)對(duì)其進(jìn)行加載，相當(dāng)于同一個(gè)東西，如果有N個(gè)classLoader那么他將會(huì)被 加載N次。因此，某些情況下，這個(gè)問題基本視為無解。當(dāng)然，存在大量classLoader和大量反射類的情況其實(shí)也不多。

解決：

??? 1. -XX:MaxPermSize=16m

??? 2. 換用JDK。比如JRocket。

?

?

堆棧溢出

異常： ? java.lang.StackOverflowError

說明： ? 這個(gè)就不多說了，一般就是遞歸沒返回，或者循環(huán)調(diào)用造成

?

?

線程堆棧滿

異常 ? ：Fatal: Stack size too small

說明 ? ：java中一個(gè)線程的空間大小是有限制的。JDK5.0以后這個(gè)值是1M。與這個(gè)線程相關(guān)的數(shù)據(jù)將會(huì)保存在其中。但是當(dāng)線程空間滿了以后，將會(huì)出現(xiàn)上面異常。

解決 ? ：增加線程棧大小。-Xss2m。但這個(gè)配置無法解決根本問題，還要看代碼部分是否有造成泄漏的部分。

?

系統(tǒng)內(nèi)存被占滿

異常 ? ：java.lang.OutOfMemoryError: unable to create new native thread

說明 ? ：

??? 這個(gè)異常是由于操作系統(tǒng)沒有足夠的資源來產(chǎn)生這個(gè)線程造成的。系統(tǒng)創(chuàng)建線程時(shí)，除了要在Java堆中分配內(nèi)存外，操作系統(tǒng)本身也需要分配資源來創(chuàng)建線程。因此，當(dāng)線程數(shù)量大到一定程度以后，堆中或許還有空間，但是操作系統(tǒng)分配不出資源來了，就出現(xiàn)這個(gè)異常了。

分配給Java虛擬機(jī)的內(nèi)存愈多，系統(tǒng)剩余的資源就越少，因此，當(dāng)系統(tǒng)內(nèi)存固定時(shí)，分配給Java虛擬機(jī)的內(nèi)存越多，那么，系統(tǒng)總共能夠產(chǎn)生的線程也就越少，兩者成反比的關(guān)系。同時(shí)，可以通過修改-Xss來減少分配給單個(gè)線程的空間，也可以增加系統(tǒng)總共內(nèi)生產(chǎn)的線程數(shù)。

解決：

??? 1. 重新設(shè)計(jì)系統(tǒng)減少線程數(shù)量。

??? 2. 線程數(shù)量不能減少的情況下，通過-Xss減小單個(gè)線程大小。以便能生產(chǎn)更多的線程。