7.調(diào)優(yōu)方法
7.1.JVM調(diào)優(yōu)工具
Jconsole，jProfile，VisualVM
Jconsole :jdk自帶，功能簡單，但是可以在系統(tǒng)有一定負(fù)荷的情況下使用。對垃圾回收算法有很詳細(xì)的跟蹤。詳細(xì)說明參考這里
JProfiler：商業(yè)軟件，需要付費(fèi)。功能強(qiáng)大。詳細(xì)說明參考這里
VisualVM：JDK自帶，功能強(qiáng)大，與JProfiler類似。推薦。
7.2.如何調(diào)優(yōu)
觀察內(nèi)存釋放情況、集合類檢查、對象樹
上面這些調(diào)優(yōu)工具都提供了強(qiáng)大的功能，但是總的來說一般分為以下幾類功能
堆信息查看
可查看堆空間大小分配（年輕代、年老代、持久代分配）
提供即時(shí)的垃圾回收功能
垃圾監(jiān)控（長時(shí)間監(jiān)控回收情況）
查看堆內(nèi)類、對象信息查看：數(shù)量、類型等
對象引用情況查看
有了堆信息查看方面的功能，我們一般可以順利解決以下問題：
--年老代年輕代大小劃分是否合理
--內(nèi)存泄漏
--垃圾回收算法設(shè)置是否合理
7.3.線程監(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)：檢查哪些對象在系統(tǒng)中數(shù)量最大（一定時(shí)間內(nèi)存活對象和銷毀對象一起統(tǒng)計(jì)）
這兩個(gè)東西對于系統(tǒng)優(yōu)化很有幫助。我們可以根據(jù)找到的熱點(diǎn)，有針對性的進(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í)刻，對象（或類、線程等）的不同，以便快速找到問題
舉例說，我要檢查系統(tǒng)進(jìn)行垃圾回收以后，是否還有該收回的對象被遺漏下來的了。那么，我可以在進(jìn)行垃圾回收前后，分別進(jìn)行一次堆情況的快照，然后對比兩次快照的對象情況。
7.4.內(nèi)存泄漏檢查
內(nèi)存泄漏是比較常見的問題，而且解決方法也比較通用，這里可以重點(diǎn)說一下，而線程、熱點(diǎn)方面的問題則是具體問題具體分析了。
內(nèi)存泄漏一般可以理解為系統(tǒng)資源（各方面的資源，堆、棧、線程等）在錯(cuò)誤使用的情況下，導(dǎo)致使用完畢的資源無法回收（或沒有回收），從而導(dǎo)致新的資源分配請求無法完成，引起系統(tǒng)錯(cuò)誤。
內(nèi)存泄漏對系統(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)存泄漏方式，簡單說就是所有堆空間都被無法回收的垃圾對象占滿，虛擬機(jī)無法再在分配新空間。
如上圖所示，這是非常典型的內(nèi)存泄漏的垃圾回收情況圖。所有峰值部分都是一次垃圾回收點(diǎn)，所有谷底部分表示是一次垃圾回收后剩余的內(nèi)存。連接所有谷底的點(diǎn)，可以發(fā)現(xiàn)一條由底到高的線，這說明，隨時(shí)間的推移，系統(tǒng)的堆空間被不斷占滿，最終會占滿整個(gè)堆空間。因此可以初步認(rèn)為系統(tǒng)內(nèi)部可能有內(nèi)存泄漏。（上面的圖僅供示例，在實(shí)際情況下收集數(shù)據(jù)的時(shí)間需要更長，比如幾個(gè)小時(shí)或者幾天）
解決：
這種方式解決起來也比較容易，一般就是根據(jù)垃圾回收前后情況對比，同時(shí)根據(jù)對象引用情況（常見的集合對象引用）分析，基本都可以找到泄漏點(diǎn)。
持久代被占滿
異常：java.lang.OutOfMemoryError: PermGen space
說明：
Perm空間被占滿。無法為新的class分配存儲空間而引發(fā)的異常。這個(gè)異常以前是沒有的，但是在Java反射大量使用的今天這個(gè)異常比較常見了。主要原因就是大量動態(tài)反射生成的類不斷被加載，最終導(dǎo)致Perm區(qū)被占滿。
更可怕的是，不同的classLoader即便使用了相同的類，但是都會對其進(jìn)行加載，相當(dāng)于同一個(gè)東西，如果有N個(gè)classLoader那么他將會被加載N次。因此，某些情況下，這個(gè)問題基本視為無解。當(dāng)然，存在大量classLoader和大量反射類的情況其實(shí)也不多。
解決：
-XX:MaxPermSize=16m
換用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ù)將會保存在其中。但是當(dāng)線程空間滿了以后，將會出現(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ù)。
解決：
重新設(shè)計(jì)系統(tǒng)減少線程數(shù)量。
線程數(shù)量不能減少的情況下，通過-Xss減小單個(gè)線程大小。以便能生產(chǎn)更多的線程。
8.反思
8.1.垃圾回收的悖論
所謂“成也蕭何敗蕭何”。Java的垃圾回收確實(shí)帶來了很多好處，為開發(fā)帶來了便利。但是在一些高性能、高并發(fā)的情況下，垃圾回收確成為了制約Java應(yīng)用的瓶頸。目前JDK的垃圾回收算法，始終無法解決垃圾回收時(shí)的暫停問題，因?yàn)檫@個(gè)暫停嚴(yán)重影響了程序的相應(yīng)時(shí)間，造成擁塞或堆積。這也是后續(xù)JDK增加G1算法的一個(gè)重要原因。
當(dāng)然，上面是從技術(shù)角度出發(fā)解決垃圾回收帶來的問題，但是從系統(tǒng)設(shè)計(jì)方面我們就需要問一下了：
我們需要分配如此大的內(nèi)存空間給應(yīng)用嗎？
我們是否能夠通過有效使用內(nèi)存而不是通過擴(kuò)大內(nèi)存的方式來設(shè)計(jì)我們的系統(tǒng)呢？
8.2.我們的內(nèi)存中都放了什么
內(nèi)存中需要放什么呢？個(gè)人認(rèn)為，內(nèi)存中需要放的是你的應(yīng)用需要在不久的將來再次用到到的東西。想想看，如果你在將來不用這些東西，何必放內(nèi)存呢？放文件、數(shù)據(jù)庫不是更好？這些東西一般包括：
系統(tǒng)運(yùn)行時(shí)業(yè)務(wù)相關(guān)的數(shù)據(jù)。比如web應(yīng)用中的session、即時(shí)消息的session等。這些數(shù)據(jù)一般在一個(gè)用戶訪問周期或者一個(gè)使用過程中都需要存在。
緩存。緩存就比較多了，你所要快速訪問的都可以放這里面。其實(shí)上面的業(yè)務(wù)數(shù)據(jù)也可以理解為一種緩存。
線程。
因此，我們是不是可以這么認(rèn)為，如果我們不把業(yè)務(wù)數(shù)據(jù)和緩存放在JVM中，或者把他們獨(dú)立出來，那么Java應(yīng)用使用時(shí)所需的內(nèi)存將會大大減少，同時(shí)垃圾回收時(shí)間也會相應(yīng)減少。
我認(rèn)為這是可能的。
8.3.解決之道
數(shù)據(jù)庫、文件系統(tǒng)
把所有數(shù)據(jù)都放入數(shù)據(jù)庫或者文件系統(tǒng)，這是一種最為簡單的方式。在這種方式下，Java應(yīng)用的內(nèi)存基本上等于處理一次峰值并發(fā)請求所需的內(nèi)存。數(shù)據(jù)的獲取都在每次請求時(shí)從數(shù)據(jù)庫和文件系統(tǒng)中獲取。也可以理解為，一次業(yè)務(wù)訪問以后，所有對象都可以進(jìn)行回收了。
這是一種內(nèi)存使用最有效的方式，但是從應(yīng)用角度來說，這種方式很低效。
內(nèi)存-硬盤映射
上面的問題是因?yàn)槲覀兪褂昧宋募到y(tǒng)帶來了低效。但是如果我們不是讀寫硬盤，而是寫內(nèi)存的話效率將會提高很多。
數(shù)據(jù)庫和文件系統(tǒng)都是實(shí)實(shí)在在進(jìn)行了持久化，但是當(dāng)我們并不需要這樣持久化的時(shí)候，我們可以做一些變通——把內(nèi)存當(dāng)硬盤使。
內(nèi)存-硬盤映射很好很強(qiáng)大，既用了緩存又對Java應(yīng)用的內(nèi)存使用又沒有影響。Java應(yīng)用還是Java應(yīng)用，他只知道讀寫的還是文件，但是實(shí)際上是內(nèi)存。
這種方式兼得的Java應(yīng)用與緩存兩方面的好處。memcached的廣泛使用也正是這一類的代表。
同一機(jī)器部署多個(gè)JVM
這也是一種很好的方式，可以分為縱拆和橫拆?？v拆可以理解為把Java應(yīng)用劃分為不同模塊，各個(gè)模塊使用一個(gè)獨(dú)立的Java進(jìn)程。而橫拆則是同樣功能的應(yīng)用部署多個(gè)JVM。
通過部署多個(gè)JVM，可以把每個(gè)JVM的內(nèi)存控制一個(gè)垃圾回收可以忍受的范圍內(nèi)即可。但是這相當(dāng)于進(jìn)行了分布式的處理，其額外帶來的復(fù)雜性也是需要評估的。另外，也有支持分布式的這種JVM可以考慮，不要要錢哦：）
程序控制的對象生命周期
這種方式是理想當(dāng)中的方式，目前的虛擬機(jī)還沒有，純屬假設(shè)。即：考慮由編程方式配置哪些對象在垃圾收集過程中可以直接跳過，減少垃圾回收線程遍歷標(biāo)記的時(shí)間。
這種方式相當(dāng)于在編程的時(shí)候告訴虛擬機(jī)某些對象你可以在*時(shí)間后在進(jìn)行收集或者由代碼標(biāo)識可以收集了（類似C、C++），在這之前你即便去遍歷他也是沒有效果的，他肯定是還在被引用的。
這種方式如果JVM可以實(shí)現(xiàn)，個(gè)人認(rèn)為將是一個(gè)飛躍，Java即有了垃圾回收的優(yōu)勢，又有了C、C++對內(nèi)存的可控性。
線程分配
Java的阻塞式的線程模型基本上可以拋棄了，目前成熟的NIO框架也比較多了。阻塞式IO帶來的問題是線程數(shù)量的線性增長，而NIO則可以轉(zhuǎn)換成為常數(shù)線程。因此，對于服務(wù)端的應(yīng)用而言，NIO還是唯一選擇。不過，JDK7中為我們帶來的AIO是否能讓人眼前一亮呢？我們拭目以待。
其他的JDK
本文說的都是Sun的JDK，目前常見的JDK還有JRocket和IBM的JDK。其中JRocket在IO方面比Sun的高很多，不過Sun JDK6.0以后提高也很大。而且JRocket在垃圾回收方面，也具有優(yōu)勢，其可設(shè)置垃圾回收的最大暫停時(shí)間也是很吸引人的。不過，系統(tǒng)Sun的G1實(shí)現(xiàn)以后，在這方面會有一個(gè)質(zhì)的飛躍。
