使用Java Mission Control進行內存分配分析
jdk7u40自帶了一個非常好用的工具，就是 Java Mission Control。 JRockit Misson Control用戶應該會對mission control的很多功能十分熟悉,JRockit也是一款很棒的工具。本篇文章將著重關注如何使用Java Flight Recorder進行內存分配分析。
jvm有著非常棒的小塊內存虛擬化技術，這會讓你產生一種擁有無限內存的錯覺感，其實它的開銷非常大。有時候jvm需要找出此刻堆上數據是如何被使用的，并把剩余的空間擴大——這就是垃圾回收。產生這種情況的原因是，jvm實際獲得的物理內存是有限的，因此需要在不被使用時進行內存回收和復用。在一些時間敏感的應用中，比如交易系統和通信程序，這些暫停是不能容忍的。有很多GC調優方法可以避免這種暫停發生。貌似上面的討論已經跑題了。讓GC變少的方法當然是盡量減少分配內存。
有時候，你希望找出在你的程序中哪些地方導致了內存分配的壓力。引起這種壓力的原因有很多種。最普通的一種情況可能是jvm需要經常GC，并且時間遠超過你認為的合理值。
JFR分配事件
在HotSpot7u40中實現的Java Flight Recorder（JFR）有兩種內存分配事件可以幫助我們找出程序中進行內存分配的地方：TLAB中的內存分配和TLAB外的內存分配事件。
與JDK提供的其它大多數事件相類似，有一系列可在Mission Control中進行定制的分析接口。在進行分析之前，我們要花上幾分鐘來討論下實際的事件。
首先，你需要確保事件已近被記錄了。如果你使用默認的模板選項，你會發現內存分配分析選項默認是關閉的。要么打開它，或者使用分析模板而不要使用默認模板。內存分析選項默認關閉的原因是，它可能會產生太多的事件。并且對于不同的程序它的性能消耗是不確定的，因為不同的程序在內存分配的情況上是差別是很大的。
事件標簽組中的Log標簽是查看每個單獨事件的絕佳地址。我們來看看這里包括了哪些內容：
這里包括已經分配的內存確切大小、導致內存分配的堆棧軌跡、分配內存的類和事件信息。在TLAB內存分配事件中，它們還包括分配的TLAB大小。
需要注意的是，TLAB的內存分配事件中并不是對應每一個地點的內存分配事件，那樣太消耗資源了。取而代之的是，我們只在新的TLAB中第一次分配內存時進行事件上報。這意味著我們只獲得了本地線程的內存分配一些排序后的樣本。
此外，需要注意的是我們在JRockit中使用的TLA事件和在新生代中進行的分配是完全相同的，大對象分配事件和老生代內存分配時相同的。不過這些在HotSpot中有點復雜。TLAB外的內存分配事件既可以和年輕代內存回收分配相同，也可以和后續的Eden區及old區域的直接大對象分配相同。換句話說，如果你在TLAB事件外發現了一些少量的內存分配，你并不需要擔心。正常來說，這種情況是非常的少見的。因此在實際情況中這些區分并不是那么明顯。
使用Allocation標簽頁
Allocation（分配）標簽頁實際上包含三個子標簽頁：
- 通用
- 新TLAB分配
- TLAB外分配
通用標簽頁提供了一個總的視圖和一些可用事件的統計信息，例如對于不同的事件類型分配的總內存。依據你首要目標的不同，對待這些信息的方式也會不同。下面的這個例子十分精簡并且聚焦在內部TLAB分配，因為它更關注于總的內存分配壓力。
新TLAB分配提供了三種以上專供于分析新TLAB分配事件的虛擬化類型：類級、線程級和分析級的分配。分析級分配是對這三種類型的一個簡單的棧追蹤集合。從下面的這個例子可以看出，Integer對象幾乎占到整個系統的所有內存分配。在直方圖中選擇Integer類便會顯示出對Integer對象的所有內存的棧軌跡集合，同時在這個例子中，所有的分配都來自同一個地點，正如下圖展示的那樣。
TLAB外分配的內存標簽頁和新TLAB標簽頁的工作原理相同，僅僅在這個時間點是一致的，當然這些是TLAB外的事件。
限制
因為新TLAB的內存分配事件僅僅只是總的線程本地內存分配的樣本，僅僅只有一個事件是很難說明實際情況的。更多的事件才會有更精確的圖片。此外，如果分配事件的行為在記錄期間變化非常大，那么這樣也很難建立一個十分有說服力本地內存分配視圖。
原文鏈接： hirt 翻譯： ImportNew.com - 潘 凌霄
譯文鏈接： http://www.importnew.com/13346.html