java gc的工作原理、如何優化GC的性能、如何和GC進行有效的交互
一個優秀的Java 程序員必須了解GC 的工作原理、如何優化GC的性能、如何和GC進行有效的交互，因為有一些應用程序對性能要求較高，例如嵌入式系統、實時系統等。只有全面提升內存的管理效 率，才能提高整個應用程序的性能。 本篇文章首先簡單介紹GC的工作原理，然后再對GC的幾個關鍵問題進行深入探討，最后提出一些Java程序設計建議，從GC角度提高Java程序的性能。
GC的基本原理
Java 的內存管理實際上就是對象的管理，其中包括對象的分配和釋放，對於程序員來說，分配對象使用new關鍵字；釋放對象時，只要將對象所有引用賦值為null，讓程序不能夠再訪問到這個對象，我們稱該對象為"不可達的".GC將負責回收所有"不可達"對象的內存空間。
對於GC來說，當程序員創建對象時，GC就開始監控這個對象的地址、大小以及使用情況。通常，GC采用有向圖的方式記錄和管理堆(heap)中的所有對 象，通過這種方式確定哪些對象是"可達的"，哪些對象是"不可達的"。當GC確定一些對象為"不可達"時，GC就有責任回收這些內存空間。但是，為了保證 GC能夠區別平台實現的問題，Java規范標准對GC的很多行為都沒有進行嚴格的規定。例如，對於采用什么類型的回收算法、什么時候進行回收等重要問題都 沒有明確的規定。因此，不同的JVM的實現者往往有不同的實現算法。這也給Java程序員的開發帶來很多不確定性。本文研究了幾個和GC工作相關的問題， 努力減少這種不確定性給Java程序帶來的負面影響。
@@增量式GC( Incremental GC )
GC在JVM中通常由一個或一組進程來實現，它本身也和用戶程序一樣占用heap空間，運行時也占用CPU，當GC進程運行時，應用程序停止運行。因此， 當GC運行時間較長時，用戶能夠感到Java程序的停頓，另一方面，如果GC運行時間太短，可能對象回收率太低，這意味着還有很多應該回收的對象沒有被回 收，仍然占用大量內存。因此，在設計GC的時候，就必須在停頓時間和回收率之間進行權衡。
一個好的GC實現允許用戶定義自己所需要的設置，例如內存有限的設備，對內存的使用量非常敏感，希望GC能夠准確的回收內存，它並不在意程序速度的放慢， 另外一些實時網絡游戲，就不能夠允許程序有長時間的中斷。 增量式GC就是通過一定的回收算法，把一個長時間的中斷，划分為很多個小的中斷，通過這種方式減少GC對用戶程序的影響。雖然，增量式GC在整體性能上可 能不如普通GC的效率高，但是它能夠減少程序的最長停頓時間。
Sun JDK提供的HotSpot JVM就能支持增量式GC。HotSpot JVM缺省GC方式為不使用增量GC，為了啟動增量GC，我們必須在運行Java程序時增加-Xincgc的參數。HotSpot JVM增量式GC，實現是采用Train GC算法，它的基本想法：將堆中的所有對象按照創建和使用情況進行分組(分層)，將使用頻繁和具有相關性的對象放在一隊中，隨着程序的運行，不斷對組進行 調整，當GC運行時，它總是先回收最老的(最近很少訪問的)對象，如果整組都為可回收對象，GC將整組回收，這樣，每次GC運行只回收一定比例的不可達對 象，保證程序的順暢運行。
finalize（）函數
finalize是位於Object類的一個思路方法，該思路方法的訪問修飾符為protected，由於所有類為Object的子類，因此用戶類很容易 訪問到這個思路方法。由於，finalize函數沒有自動實現鏈式調用，我們必須手動實現，因此finalize函數的最后一個語句通常是 super.finalize()。通過這種方式，我們可以實現從下到上實現finalize的調用，即先釋放自己的資源，然后再釋放父類的資源。
根據Java語言規范標准，JVM保證調用finalize函數之前，這個對象是不可達的，但是，JVM不保證這個函數一定會被調用。另外，規范標准還保證finalize函數最多運行一次。
很多Java初學者會認為這個思路方法類似和C++中的析構函數，將很多對象、資源的釋放都放在這一函數里面。其實，這不是一種很好的方式，原因如下：其 一，GC為了能夠支持finalize函數，要對覆蓋這個函數的對象作很多附加的工作；其二，在finalize運行完成之后，該對象可能變成可達 的，GC還要再檢查一次該對象是否是可達的，因此，使用finalize會降低GC的運行性能；其三，由於GC調用finalize的時間是不確定的，因 此通過這種方式釋放資源也是不確定的。
通常，finalize用於一些不容易控制，並且非常重要資源的釋放，例如一些I/O操作、數據連接等，這些資源的釋放對整個應用程序是非常關鍵的。在這 種情況下，程序員應該以通過程序本身管理(包括釋放)這些資源為主，以finalize函數釋放資源方式為輔，形成一種雙保險的管理機制，而不應該僅僅依 靠finalize來釋放資源。
程序如何和GC進行交互（不懂．．．）
Java2增強了內存管理功能，增加了一個java.lang.ref包，其中定義了3種引用類。這3種引用類分別為SoftReference、 WeakReference和PhantomReference.通過使用這些引用類，程序員可以在一定程度和GC進行交互，以便改善GC的工作效率。這 些引用類的引用強度介於可達對象和不可達對象之間。
一些Java編碼的建議
根據GC的工作原理，我們可以通過一些竅門技巧和方式，讓GC運行更加有效率，更加符合應用程序的要求。以下就是一些程序設計的幾點建議：
1、最基本的建議就是盡早釋放無用對象的引用。大多數程序員在使用臨時變量的時候，都是讓引用變量在退出活動域(scope)后自動設置為null。我們 在使用這種方式時候，必須特別注意一些復雜的對象圖，例如數組、隊列、樹、圖等，這些對象之間有相互引用，關系較為復雜。對於這類對象，GC回收它們一般 效率較低。如果程序允許，盡早將不用的引用對象賦為null。這樣可以加速GC的工作。
2、盡量少用finalize函數。Finalize函數是Java提供給程序員一個釋放對象或資源的機會，但是，它會加大GC的工作量，因此盡量少采用finalize方式回收資源。
3、注意集合數據類型，包括數組、樹、圖、鏈表等數據結構，這些數據結構對GC來說回收更為復雜。另外，注意一些全局的變量，以及靜態變量，這些變量往往容易引起懸掛對象(dangling reference)，造成內存浪費。
4、當程序有一定的等待時間，程序員可以手動執行System.gc()，通知GC運行，但是Java語言規范標准並不保證GC一定會執行，此時使用增量式GC可以縮短Java程序的暫停時間。
java 當GC進程運行時，應用程序停止運行嗎？？
對於創建大量對象的大型應用程序，JVM 花在垃圾收集（GC）上的時間會非常多。默認情況下，進行 GC 時，整個應用程序都必須等待它完成，這可能要有幾秒鍾甚至更長的時間（Java 應用程序啟動器的命令行選項 -verbose:gc 將導致向控制台報告每一次 GC 事件）。要將這些由 GC 引起的暫停（這可能會影響快速任務的執行）降至最少，應該將應用程序創建的對象的數目降至最低。同樣，在單獨的 JVM 中運行計划代碼是有幫助的。同時，可以試用幾個微調選項以盡可能地減少 GC 暫停。例如，增量 GC 會盡量將主收集的代價分散到幾個小的收集上。當然這會降低 GC 的效率，但是這可能是時間計划的一個可接受的代價
資料引用:http://www.knowsky.com/362375.html
Java虛擬機優化選項,GC說明
引用 http://blog.sina.com.cn/s/blog_6d003f3f0100lmkn.html
有許多 JVM 選項會影響基准測試。比較重要的選項包括：
* 確保有足夠的內存可用（-Xmx）。
* 使用的垃圾收集器類型（高級的 JVM 提供許多調優選項,但是要小心使用）。
* 是否允許類垃圾收集（-Xnoclassgc）。默認設置是允許類 GC；使用 -Xnoclassgc 可能會損害性能。
* 是否執行 escape 分析（-XX:+DoEscapeAnalysis）。
* 是否支持大頁面堆（-XX:+UseLargePages）。
* 是否改變了線程堆棧大小（例如,-Xss128k）。
* 使用 JIT 編譯的方式：總是使用（-Xcomp）、從不使用（-Xint）或只對熱點使用（-Xmixed；這是默認選項,產生的性能最好）。
* 在執行 JIT 編譯之前（-XX:CompileThreshold）、后台 JIT 編譯期間（-Xbatch）或分級的 JIT 編譯期間（-XX:+TieredCompilation）收集的剖析數據量。
* 是否執行偏向鎖（biased locking,-XX:+UseBiasedLocking）；注意,JDK 1.6 及更高版本會自動執行這個特性。
* 是否激活最近的試驗性性能調整（-XX:+AggressiveOpts）。
* 啟用還是禁用斷言（-enableassertions 和 -enablesystemassertions）。
* 啟用還是禁用嚴格的本機調用檢查（-Xcheck:jni）。
* 為 NUMA 多 CPU 系統啟用內存位置優化（-XX:+UseNUMA）。
Class Data Sharing類共享.
java5引入了類共享機制,指在java程序第一次啟動時, 優化一些最常用的基礎類到一個共享文件中,暫只支持Client VM和serialGC.存放在client/classes.jsa中, 這就是為什么程序在第一次執行較慢的原因. 開啟參數-Xshare.
J2SE 6(代號：Mustang野馬)主要設計原則之一就是提升J2SE的性能和擴展能力,主要通過最大程度提升運行效率,更好的垃圾收集和一些客戶端性能來達到。
1、偏向鎖（Biased locking）
Java 6以前加鎖操作都會導致一次原子CAS（Compare-And-Set）操作,CAS操作是比較耗時的,即使這個鎖上實際上沒有沖突,只被一個線程擁 有,也會帶來較大開銷。為解決這一問題,Java 6中引入偏向鎖技術,即一個鎖偏向於第一個加鎖的線程,該線程后續加鎖操作不需要同步。大概的實現如下：一個鎖最初為NEUTRAL狀態,當第一個線程加 鎖時,將該鎖的狀態修改為BIASED,並記錄線程ID,當這一線程進行后續加鎖操作時,若發現狀態是BIASED並且線程ID是當前線程ID,則只設置 一下加鎖標志,不需要進行CAS操作。其它線程若要加這個鎖,需要使用CAS操作將狀態替換為REVOKE,並等待加鎖標志清零,以后該鎖的狀態就變成 DEFAULT,常用舊的算法處理。這一功能可用-XX:-UseBiasedLocking命令禁止。
2、鎖粗化（Lock coarsening）
如果一段代碼經常性的加鎖和解鎖,在解鎖與下次加鎖之間又沒干什么事情,則可以將多次加加鎖解鎖操作合並成一對。這一功能可用-XX:-EliminateLocks禁止。
3、自適應自旋（Adaptive spinning）
一般在多CPU的機器上加鎖實現都會包含一個短期的自旋過程。自旋的次數不太好決定,自旋少了會導致線程被掛起和上下文切換增加,自旋多了耗CPU。為此Java 6中引入自適應自旋技術,即根據一個鎖最近自旋加鎖成功概率動態調整自旋次數。
4、常用大內存分布的堆（large page heap）
在大內分頁是x86/amd64架構上用來減小TLB（虛擬地址到物理地址翻譯緩存）大小的TLB失配率。Java 6中的內存堆可以使用這一技術。
5、提高數組拷貝性能
對每種類型大小寫一個定制的匯編數組拷貝程序。
6、后台進行代碼優化
Background Compilation in HotSpot™ Client Compiler: 后台進行代碼優化
7、線性掃描寄存器分配算法（Linear Scan Register Allocation）:
一種新的寄存器分配策略,基於SSA（static single assignment）,性能提高10%左右。常用的寄存器分配算法將寄存器分配看作圖着色問題,時間復雜度是O(n^4),不適用於Java的JIT編譯。原來的JVM里是根據一些本地啟發式規則來分配寄存器,效果不太好,Java 6中使用的線性掃描寄存器算法能夠達到與圖顏色算法相似的效果,並且時間復雜度是線性的。
8、並行縮並垃圾收集器（Parallel Compaction Collector）
進行Full GC時使用並行垃圾收集（JDK 5里原來非Full GC是並行的但Full GC是串行的）,使用-XX:+UseParallelOldGC開啟這一功能
9、並行低停頓垃圾收集器（Concurrent Low Pause Collector）
顯式調用gc（如System.gc）時也可以並行進行標記-清掃式垃圾收集,使用-XX:+ExplicitGCInvokesConcurrent開啟。
10、Ergonomics in the 6.0 Java Virtual Machine
自動調整垃圾收集策略、堆大小等配置,這一功能在JDK 5中加入,JDK 6中得到顯著增強,SPECjbb2005性能提高70%。
11、boot類裝載器的優化
jre中增加一個描述package所在jar文件的元索引文件,加快classloader加載類性能,提高桌面Java應用啟動速度（+15%）。內存占用也減少了10%
12、圖形程序優化
在jvm啟動之前顯示splash。
OutOfMemoryError是內存溢出, 有多種情況會出現內存溢出.
1.java堆溢出java.lang.OutOfMemoryError: Java heap space.
2.java永久堆溢出,通常是反射,代理用的較多導致類生成過多,java.lang.OutOfMemoryError: PermGen space.
3.本地堆溢出,這可能是由於操作系統無法分配足夠的內存,可能是系統已無內存,還可能是java進程內存空間耗盡,這里有點意思,一般32位系統進程只 有4G地址空間,而又因為java實現使用本地堆或內存映射區作為java堆的存儲空間,再去除內核映射區,java使用的堆一般只有2G以內,而如果 java堆xmx占的過大,導致jni的本地堆過小,也會生成內存溢出.本地堆可以是jni用new, malloc,也可能是DirectBuffer等實例.
java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?
這時候,如果java堆足夠用的話, 減少xmx的值,反而會解決這種問題.
4.jni方法的溢出.而前者是由jvm檢測的本地溢出,而此是在jni方法調用時,無法分配內存.
java.lang.OutOfMemoryError: <reason> <stack trace> (Native method)
JDK7性能優化.
1.(Zero Based )Compressed OOPS
在64位CPU中, JVM的OOP(Ordinary object pointer)為64位, 簡單的講,OOP可以被認為為對象的引用,雖然java中基本類型位數是固定的, 但引用類型(簡化的C語言指針)用於指向堆中的地址很自然的會被擴展成機器的字長. 32位系統最大可訪問內存為4G,為了突破這個限制64位系統已經很常見,但是單單引用從32位轉為64位,堆空間占用大概會增加一半,雖然內存已經很便宜, 但是內存帶寬,CPU緩存代價是很昂貴的.
Compressed OOPS壓縮可管理的引用到32位以降低堆的占用空間,在JVM執行時加入編/解碼指令,類似於8086的段管理,其使用
<narrow-oop-base(64bits)> + (<narrow-oop(32bits)> << 3) + <field-offset>公式確定內存地址.
JVM在將對象存入堆時編碼,在堆中讀取對象時解碼.
而Zero based compressed oops則進一步將基地址置為0(並不一定是內存空間地址為0, 只是JVM相對的邏輯地址為0,如可用CPU的寄存器相對尋址) 這樣轉換公式變為:
(<narrow-oop << 3) + <field-offset>
從而進一步提高了性能.不過這需要OS的支持.
如果java堆<4G,oops使用低虛擬地址空間,而並不需要編/解碼而直接使用.
Zero based compressed oops針對不同的堆大小使用多種策略.
1.堆小於4G,無需編/解碼操作.
2.小於32G而大於4G,使用Zero based compressed oops
3.大於32G, 不使用compressed oops.
Escape Analysis Improvements
當變量（或者對象）在方法中分配后,其指針有可能被返回或者被全局引用,這樣就會被其他過程或者線程所引用,這種現象稱作指針（或者引用）的逃逸 (Escape),也就是說變量不僅僅在本方法內使用. Java對象一般被認為總是在堆中分配的, 這使得任何對象都需要進行垃圾回收.而大多數情況下,方法內的對象僅在本方法中使用,完全可以使用棧來存儲,棧內變量釋放是最自然,性能最好的,C中的 struct即在分配在棧中.如果實現引用逃逸分析,便可以把沒有引用逃逸的對象分配在棧中,而且不必在語言上加入新的定義方法,引用逃逸分析是自動 了.JDK7已經開始缺省支持的逃逸分析了.另此還可以消除同步,如果其分析得知對象為非引用逃逸,則所有該對象的同步操作都可以被取消(當然這本是程序 員的任務,比如StringBuffer),另可優化對象的部分甚至全部都保存在CPU寄存器內.
NUMA Collector Enhancements
NUMA(Non Uniform Memory Access),NUMA在多種計算機系統中都得到實現,簡而言之,就是將內存分段訪問,類似於硬盤的RAID,Oracle中的分簇,JVM只不過對此加以應用而矣.
以上三個特性也能在有些JDK6中打開,具體需要看各版本的changenotes. java6中加入了諸如以下的性能優化手段:
輕量鎖 使用cas機制減少鎖的性能消耗.
偏向鎖（biased locking）
鎖粗化（lock coarsening）
由逸出（escape）分析產生的鎖省略 逸出分析還能夠分配內存在棧中,以減少內存回收的壓力.
自適應自旋鎖（adaptive spinning） 自旋鎖只有在物理多CPU中才會效果.
鎖消除(lock elimination)
在多核CPU中,鎖的獲取比單核系統耗費資源相對大的多, 因為在多核系統中,鎖的獲取需要CPU阻塞數據總線,高速緩存寫回.
這樣有時候, 我們在單核系統中,經常會得到StringBuffer與StringBuilder性能差不多的用例, 而且由於有了鎖消除等技術, 有些情況在多核CPU中也會得到性能相差不多的情況.
據信Java7還將缺省支持OpenGL的加速功能.
在JDK1.5中加入了Class Data Sharing, 也就是把部分常用的java基本類,緩存在文件或共享內存中, 以供所有java進程使用.
從JRE1.5中,java程序啟動時,如非使用-client|server指令顯示指定,虛擬機會自動選擇對應的VM,如在64位系統中,只實現了serverVM,所有的虛擬機都會使用server VM. 32位的系統則windows缺省使用clientVM,而Linux,solaris則根據CPU個數和內存來確定是否使用serverVM,如jre6以2CPU,2GB物理內存為界.
GC
衡量GC效率的參數主要有兩個,一個是吞吐量(即效率),一個是停頓時間,另外還有footprint,就是占用的堆大小.
GC算法.
1.拷貝,將所有仍然生存的對象搬到另外一塊內存后,整塊內存就可回收。這種方法有效率,但需要有一定的空閑內存,拷貝也有開銷.
2.跟蹤收集器,跟蹤收集成追蹤從根節點開始的對象引用圖。基本的追蹤算法叫作“標記並清除”,也就是垃圾收集的兩個階段。標記階段,垃圾收集器遍歷引用 數,標記每一個遇到的對象。清除階段,未被標記的對象被釋放。可能在對象本身設置標記,要么就是用一個獨立的位圖來設置標記。 壓縮(可選),垃圾收集同 時要應對碎片整理的任務。標記和清除通常使用兩種策略來消除堆碎片：壓縮和拷貝,這兩種方法都是快速移動對象來減小碎片, 加在一起叫做mark-sweep-compact.
3.還有一種引用計數收集器,這種方法時堆中的每個對象都有一個引用計數,在引用賦值時加1,置空或作為基本類型的引用超出生命期(如方法退出而棧回收)時減1,其對多個對象的循環引用無能為力,但引用計數都不為0 ,還有引用數的增減帶來額外開銷,故已不再使用.
分代收集器
根據程序的統計, 大多數對象生命周期都很短,都很快被釋放掉.但也有部分對象生命周期較長, 甚至永久有效. 對於拷貝算法來說,每次收集時,所有的活動對象都要移動來移動去。對於短生命的對象還好說,經常可以就地解決掉,可是對於長生命周期的對象就純粹是個體力 勞動了,把它挪來挪去除消耗大量的時間,沒有產生任何效益。分代收集能直接讓長生命周期的對象長時間的呆在一個地方按兵不動。GC 的精力可以更多的花在收集短命對象上。
這種方法里,堆被分成兩個或更多的子堆,每一個堆為一“代”對象服務。最年幼的那一代進行最頻繁的垃圾收集。因為多數對象是短命的,只有很小部分的年 幼對象可以在經歷第一次收集后還存活。如果一個最年幼的對象經歷了好幾次垃圾收集后仍是活着的,那這個對象就成為壽命更高的一代,它被轉移到另外一個子堆 中去。年齡更高一代的收集沒有年輕一代來得頻繁。每當對象在所屬的年齡代中變得成熟（多次垃圾收集后仍幸存）之后,就可以轉移到更高年齡的一代中去。
分代收集一般在年輕堆中應用於拷貝算法,年老代應用於標記清除算法。不管在哪種情況下,把堆按照對象年齡分組可以提高最基本的垃圾收集的性能。
一般java中分代收集器將堆分為年輕代, 年老代和永久代. 年輕代的收回稱為minorGC,因為在此期內,對象生命周期很較,故效率較高, 年老代稱為FullGC,對應的效率較低,用時較長,應盡量減少FullGC的次數.
VM,
Client VM 適合桌面程序,啟動快, 運行時間短, 故其不會預先裝入太多的類,對類進行過多優化.
Server VM 適合服務程序,啟動時間不重要,運行時間較長, 會預先裝入大多基礎類,對類進行優化.
GC種類.
Serial 串行回收器(缺省)
在GC運行時, 應用邏輯全部暫停,利用單線程通過"拷貝"進行年輕代的垃圾收集,單線程使用"標記-清除-壓縮"進行年老代(tenured)垃圾回收. 吞吐率較高.適合單CPU硬件.
Parallel 並行回收器
針對年輕代使用多個GC線程進行"拷貝"垃圾收集,針對年輕代的GC運行時,程序暫停, 年老代依然是單線程使用"標記-清除-壓縮"進行年老代垃圾回收,GC運行時, 應用同樣暫停.在大內存,多處理器的機器上,可以考慮使用此Parallel GC（使用參數-XX:+UseParallelGC指定）,這種GC在對YoungGen進行GC時,可以對多處理器加以利用,從而相對降低了停頓時間,但重點是提高了吞吐量,但是,在其對OldGen進行GC時,依然使用了和Serial GC同樣的算法。所以在Jdk5U6中,又引入了Parallel Compacting Collector（使用參數-XX:+UseParallelOldGC指定）,這種GC對OldGen的GC也可以受益於多處理器。由於對OldGen的GC遠比YoungGen更耗時間,所以理論上這種Garbage Collector可以提供更優的性能,而且,值得注意的是,Parallel Compacting GC最終會取代Parallel GC。
Concurrent mark-sweep 並發回收器.
對於年輕代使用和多GC線程"拷貝"回收,此GC也需要暫停應用,但由於minorGC效率較高,故不會產生大的停頓,對於年老代使用與應用程序同時運行 的並發方式標記-回收機制,其將步驟再次分細,部分階段(初始標記,重新標記)也會完全導致應用暫停,但時間較短,大部分時間都是應用程序與單GC線程並 發,降低了應用程序暫停的時間。這種GC使用了和Parallel GC一致的YoungGen的收集算法,而在對OldGen進行GC時,它采用了較為復雜的算法,提供了極短的停頓時間。但是,復雜的算法也造成了更大的 開銷,而且這種 Parallel GC是non-compacting的,所以它使用一個空閑塊鏈表來管理OldGen Heap,分配空間的開銷也加大了.在某些場景中,較短的停頓時間比較大的吞吐量更加重要,這時可以考慮使用此GC,即所謂的CMS GC。
增量收集器(Train算法)已逐漸被棄用,-XincGC 在1.5中會選中並發GC.
在SUN J2SE 5.0中,引入了所謂Behavior-based Parallel Collector Tuning,這種調優方式基於三個Goal：
Maximum Pause Time Goal： 使用參數-XX:MaxGCPauseMillis=n指定,默認值為空。這個參數被指定后,三個內存區的GC停頓時間都會盡力的保持在n毫秒以內,如果無法滿足,則相應的內存區會縮小,以縮短GC的停頓時間；
Throughput Goal： 使用參數-XX:GCTimeRatio=n指定,默認值為99,即GC時間占總的應用運行時間為1%。如果無法滿足,相應的內存區會擴大,以提高應用在兩次GC間的運行時間；
Footprint Goal： 由於眼下內存泛濫,所以這個Goal一般就不值得關注了；
這三個Goal的優先級為從上到下,即首先滿足Maximum Pause Time Goal,再滿足Throughput Goal,最后再滿足Footprint Goal。
使用參數-Xloggc:file和-XX:+PrintGCDetails打印gclog,然后使用gcviewer對gclog進行查看,它的優勢在於可以生成統計數據,吞吐量,最大的和最小的停頓時間,Full GC時間占整個GC時間的百分比等,都可以使用這個工具查看,但目前只支持到1.5。
JConsole是允許您監測各種各樣的VM資源運行時使用情況的Java監視和管理控制台。實際在java5中, 需要加一個參數, 在java6中由於支持了attach API,jconsole會自動加載JVM內部的JMX代理.
jstat命令打印各種各樣的VM統計數據,包括內存使用、垃圾回收時間、類加載和及時編譯器統計。 jmap 命令允許您獲得運行時的堆直方圖和堆轉儲。jhat命令允許您分析堆轉儲。jstack命令允許您獲得線程堆棧跟蹤。這些診斷工具可以附加到任何應用程序,不需要以特別方式啟動。