對(duì)于還在正常運(yùn)?的系統(tǒng)：

1. 可以使?jmap來查看JVM中各個(gè)區(qū)域的使?情況

2. 可以通過jstack來查看線程的運(yùn)?情況，?如哪些線程阻塞、是否出現(xiàn)了死鎖

3. 可以通過jstat命令來查看垃圾回收的情況，特別是fullgc，如果發(fā)現(xiàn)fullgc?較頻繁，那么就得進(jìn)?調(diào)優(yōu)了

4. 通過各個(gè)命令的結(jié)果，或者jvisualvm等?具來進(jìn)?分析

5. ?先，初步猜測(cè)頻繁發(fā)送fullgc的原因，如果頻繁發(fā)?fullgc但是??直沒有出現(xiàn)內(nèi)存溢出，那么表示fullgc實(shí)際上是回收了很多對(duì)象了，所以這些對(duì)象最好能在younggc過程中就直接回收掉，避免這些對(duì)象進(jìn)?到?年代，對(duì)于這種情況，就要考慮這些存活時(shí)間不?的對(duì)象是不是?較?，導(dǎo)致年輕代放不下，直接進(jìn)?到了?年代，嘗試加?年輕代的??，如果改完之后，fullgc減少，則證明修改有效

6. 同時(shí)，還可以找到占?CPU最多的線程，定位到具體的?法，優(yōu)化這個(gè)?法的執(zhí)?，看是否能避免某些對(duì)象的創(chuàng)建，從?節(jié)省內(nèi)存

對(duì)于已經(jīng)發(fā)?了OOM的系統(tǒng)：

1. ?般?產(chǎn)系統(tǒng)中都會(huì)設(shè)置當(dāng)系統(tǒng)發(fā)?了OOM時(shí)，?成當(dāng)時(shí)的dump?件（-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）

2. 我們可以利?jsisualvm等?具來分析dump?件

3. 根據(jù)dump?件找到異常的實(shí)例對(duì)象，和異常的線程（占?CPU?），定位到具體的代碼

4. 然后再進(jìn)?詳細(xì)的分析和調(diào)試

總之，調(diào)優(yōu)不是?蹴?就的，需要分析、推理、實(shí)踐、總結(jié)、再分析，最終定位到具體的問題