一．JRockit調優簡介
JRockit是一個自適應的JVM，它能夠自動調整自己去適應底層硬件，因此對它的調優主要集中在一些需要人工干預的參數上，比如說：需要劃分多少RAM給JRockit使用等。JRockit有一組非標准的-X啟動選項，我們可以用它來調節JVM。JRockit有兩組主要的子系統可以被優化--內存管理系統（包括垃圾回收）和線程系統。在內存管理子系統方面，有很多調優的工作可以做。
二．Tuning WebLogic JRockit JVM
1．設置初始堆尺寸
可以通過-Xms:<size>m來設置初始堆大小，如果-Xmx的值小於128MB，則-Xms缺省取值為16MB；如果-Xmx設置大於128MB，則-Xms缺省值為物理內存的25%，最大不超過64M。例子：
-Xgc:gencon -xms:64m -Xmx:64m myClass
2．設置最大堆尺寸
可以通過-Xmx:<size>m來設置最大堆尺寸。在IA32構架下，由於操作系統給每個進程的最大內存尋址空間為1.8G，因此最大堆尺寸不能超過1.8G。在IA64構架下，就沒有1.8G的限制。
如果你的JAVA應用程序在運行時出現了Out of memory的錯誤，你就需要調大最大堆尺寸。如果沒有設置最大堆尺寸，則缺省值為：
1．如果設置了-Xgc:gencopy，由最大堆尺寸是min{400, 物理內存*75%}；
2．如果沒有設置-Xgc:gencopy，由最大堆尺寸是min{1536, 物理內存*75%}；
最好手工把最大堆尺寸設置為物理內存（1024M）的75%：
-Xgc:gencon -xms:64m -Xmx:768m myClass
3．設置Nursery的尺寸
可以使用-Xns:<size>來設置Nursery的尺寸，我們要在保證垃圾回收停頓時間（garbage collection-pause）盡可能短的同時，盡量加大Nursery的尺寸，這在創建了大量的臨時對象時尤其重要。缺省值為：
1．對於-Xgc:gencopy，缺省的Nursery大小為320KB/CPU，對於10個CPU的系統來說，Nursery大小為3200KB（3.2M）
2．對於-Xgc:gencon，缺省的Nursery大小為10M/CPU，對於10個CPU的系統來說，Nursery大小為100M
4．定義內存空間的清理時機
可以使用-Xcleartype:<gc|local|alloc>來定義已經被垃圾回收的內存空間在什麼時候可以被清理，支持以下三種方式：
1．gc，在垃圾回收的同時清理內存；
2．local，在分配了一塊thread-local區域時清理內存，僅在把參數-Xallocationtype設置成local時才有用；
3．alloc，在這塊內存被分配給其它對象時清理。在IA64上目前還不支持。
缺省值為：
1．IA32上缺省值為alloc
2．IA64上缺省值為gc
5．定義線程分配的類型
可以使用-Xallocationtype:<global|local>來定義線程分配的類型。
1．global，在最大堆尺寸比較小時（小於128M）或者應用程序大量使用了線程時使用。
2．local，在最大堆尺寸比較大時（大於128M）或者應用程序少量使用了線程時使用。
缺省值：
1．如果設置了-Xgc:gencopy，缺省值為global
2．如果設置了-Xgc:siglecon，-Xgc:gencon和-Xgc:parallel，缺省值為local
6．定義線程棧尺寸
可以使用-Xss<size>[k|K][m|M]來定義線程棧大小。最小線程尺寸定義如下：
1．thin threads：最小線程棧尺寸為8K，缺省為64K；
2．native threads：最小線程棧尺寸為16K
如果-Xss設置小於最小值，則自動使用最小值。
缺省值：
1．IA32系統，WIN32：64K，LINUX32：128K
2．IA64系統，WIN64：320K，LINUX64：1M
二．Basic Tuning Tips and Techniques
盡管JRockit提供了一組缺省的OOTB配置選項，但最好根據實際應用情況來對JRockit作一些調整。
1．決定你要在哪方面調優
要考慮的因素有：
1．要為JRockit分配多少內存空間；
2．你要調優的目的是什麼，是要得到更好的響應性還是更好的性能；
2．設置堆尺寸
對於堆尺寸來說，當然是越大越好了。如果設得不夠大，就會造成Out-of-memory和內存分頁錯。如果同時運行了多個應用程序，建議把最小和最大堆尺寸設置成一樣大。
3．在高響應性方面的調優
要得到更好的響應性能，應該設置
1．使用並發垃圾回收器。-Xgc:gencon
2．設置初始和最大堆大小。-Xms512m，-Xmx768m，由於使用了並發垃圾回收器，所以堆大小不會造成長時間的等待。
3．設置nursery尺寸。如果用到了大量的臨時對象，則需要適當的調大nursery尺寸。調大nursery尺寸會導致垃圾回收的停頓時間加長，因此要注意，確保垃圾回收的停頓時間在可忍受的范圍內，這個停頓時間可以通過設置-Xgcpause來查看。
4．在高性能方面的調優
如果要得到更好的性能，你應該：
1．選用並行垃圾回收器，由於並行垃圾回收器不使用nursery，因此你不必再設置-Xns，方法是加上-Xgc:parallel
2．把初始和最大堆尺寸設置調到盡可能的大。方法是-Xms512m, -Xmx768m。
5．分析垃圾回收和停頓時間
1．使用-Xgcreport生成報表，顯示垃圾回收的統計信息，從中可以看出你是不是最有效地使用了垃圾回收器。
2．使用-Xverbose:memory來顯示在運行期間每一次垃圾回收的停頓時間。本選項僅用於調試，會產生大量的控制台輸出。
6．調整線程選項
當大量地使用了線程時（超過100個），需要調整線程選項：
1．使用thin線程選項。-Xthinthreads。瘦線程模式在LINUX下非常有效。注意：瘦線程在JRockit中只是一個試驗選項，不推薦廣泛使用；
2．關閉本地分配線程的選項。-Xallocationtype:global。每個本地線程區都要消耗大約2K的內存，如果大量地使用了線程，本地線程不但會造成內存空間浪費，而且還會造成堆碎片。使用全局線程機制會減少堆碎片，但在內存分配方面速度要慢一些。
7．分析並改善應用程序設計
找出瓶頸方法：
1．使用Intel VTune工具；
2．使用-Xjvmpi:allocs=off,monitors=off,entryexit=off選項。
三．Command Line Options by Name
啟動JRockit時，可以帶一些-X選項，這些選項是非JVM標准的，專門用於配置JRockit的性能。
選項 描述 -X 顯示擴展Java選項 -Xallotype
-Xallocationtype
可取值global和local，定義使用本地線程還是全局線程。 -Xbootclasspath 指定類搜索路徑，可以是ZIP和JAR文件，以；或：分隔 -Xcleartype 定義內存清理時機，可取值gc, local, alloc。gc表示在垃圾回收時清理內存；local表示時分配一塊local線程區時清理；alloc表示內存區要被分配給其它對象時清理 -Xgc 選擇要使用的垃圾回收器的類型，可取值：
gencopy：generational copying
singlecon：single spaced concurrent，單空間並發
gencon：generational concurrent
parallel：parallel
如果-Xmx小於128M，缺省使用gencopy，否則使用gencon
-Xgcpause 打印由垃圾回收器造成的停頓時間 -Xgcreport 打印垃圾回收報表 -Xjvmpi 是否允許JVMPI事件，這些事件有：
entryexit（缺省ON）
allocs（缺省ON）
monitors（缺省ON）
arenasdelete（缺省OFF）
-Xmanagement 激活JVM中的管理服務器，在JVM的管理控制台能連接到它之前，必須先激活。 -Xms 設置初始堆大小，單位有K、M、G -Xmx 設置最大堆大小，單位有K、M、G -Xnativethreads 使用本地線程系統，這是缺省選項 -Xnoclassgc 禁止對類作垃圾回收 -Xnohup 告訴JRockit，忽略CTRL_LOGOFF_EVENT和SIGHUP事件 -Xns 設置nursery尺寸，單位有K、M、G -Xss 設置線程棧尺寸，單位有K、M、G -Xthinthreads 使用JRockit的高性能線程系統，在IA64上不可用。 -Xverbose 讓JRockit打印更多的信息，可選的參數有：
codegen、cpuinfo、gc、load、memory、Opt
-Xverify 作完整的bytecode一級的校驗
四．用JRockit8.1中的Method Profiler調優WebLogic
1．關於Method Profiler工具
BEA WebLogic JRockit 8.1提供了一個Profiling工具：Method Profiler來調優WebLogic應用。
2．利用Method Profiler調優WebLogic應用
JRockit 8.1所帶的Method Profiler工具能夠將所有在JRockit Java虛擬機上執行的成員方法的調用次數、執行的總時間和每次調用的執行時間都統計出來，如圖1所示。這樣的功能一來可以讓我們對跑在WebLogic上的應用進行tuning（代碼級的），二來也大大方便了我們確定系統瓶頸在何處。這也可以說是JRockit JVM相對於其他JVM在功能上的一大優勢。
在一次對WebLogic Server 8.1的壓力測試中，對一組包含了CMP特性的樣本進行壓力測試時，就利用JRockit的Method Profiler診斷出了系統的瓶頸所在，現介紹如下。CMP這組樣本中原先對CMP Entity Bean的操作除了用ejbCreate插入一條記錄之外，緊跟著用setName方法設置其name屬性，即UPDATE其對應數據庫記錄中name域的值，代碼如下：
public void ejbCreate() //Stateful4CMPBean中的方法
throws CreateException
{
try
{
Context ctx = new InitialContext();
SheepHome home = (SheepHome)ctx.lookup("Sheep");
Sheep sheep = null;
int x = getNextId(); // getNextId()也包含對數據庫的操作
sheep = home.create(x);
if(sheep != null)
{
sheep.setName("sheep1".concat(String.valueOf(String.valueOf(x))));
m_strMsg = "create sheep".concat(String.valueOf(String.valueOf(x)));
} else
{
m_strMsg = "The sheep name is not created.";
}
}
catch(Exception e)
{
m_strMsg =
"*** some exception occured! (CMP) ".concat(String.valueOf(String.valueOf(e.getMessage())));
}
}
此時測出來的數據，TPS平均值非常低，且測試時Response Time總是隨著時間的增長幾乎呈線性攀升。於是用Method Profiler進行診斷：
（1）在JRockit的啟動參數中加入-Xmanagement，以便啟動JRockit的時候同時啟動其Management Server。
（2）啟動JRockit Management Console，並且將其連接到啟動了的Management Server上。（在做壓力測試時用JRockit Management Console進行觀察對性能的損耗可以忽略不計）
（3）在JRockit Management Console中，將ToolsàPreferences菜單中的Mode of operation屬性設為developer。
（4）在Method Profiler屬性頁中添加你所需要觀察的類的成員方法。
（5）按Start按鈕讓Method Profiler開始進行統計。
Time/Inv(ns)指標的顯示結果表明Stateful4CMPBean.ejbCreate()代碼所含邏輯成為了系統的瓶頸。結果又顯示getNextId()和home.create()操作消耗的時間只占Stateful4CMPBean.ejbCreate()的一小部分，而sheep.setName()操作消耗的時間卻占了Stateful4CMPBean.ejbCreate()的剩下的（指除去getNextId()和home.create()操作消耗的時間）絕大部分。
於是又用Method Profiler作了一系列實驗，結果如下：用1個用戶做壓力測試，sheep.setName()操作消耗的時間為X，getNextId()操作消耗的時間為Y，home.create()操作消耗的時間為Z；用2個用戶做壓力測試，sheep.setName()操作消耗的時間約為2X，getNextId()操作消耗的時間約為Y，home.create()操作消耗的時間約為Z；用3個用戶做壓力測試，sheep.setName()操作消耗的時間約為3X，getNextId()操作消耗的時間約為Y，home.create()操作消耗的時間約為Z。可以比較肯定地判斷，sheep.setName()執行的是一個串行化的邏輯。檢查Oralce中UPDATE的ISOLATION-LEVEL，果然為SERIALIZABLE。
將sheep.setName("sheep1".concat(String.valueOf(String.valueOf(x)))); 這句代碼刪掉。
重新測試，TPS平均值有很大幅度的提高，Response Time在壓力測試開始一段時間後也趨於平穩，幾乎呈水平線走勢。
