一、查看jvm常用命令
jinfo：可以輸出並修改運行時的java 進程的opts。
jps：與unix上的ps類似，用來顯示本地的java進程，可以查看本地運行着幾個java程序，並顯示他們的進程號。
jstat：一個極強的監視VM內存工具。可以用來監視VM內存內的各種堆和非堆的大小及其內存使用量。
jmap：打印出某個java進程（使用pid）內存內的所有'對象'的情況（如：產生那些對象，及其數量）。
jconsole：一個java GUI監視工具，可以以圖表化的形式顯示各種數據。並可通過遠程連接監視遠程的服務器VM。
需要注意：在使用這些工具前，先用JPS命令獲取當前的每個JVM進程號，然后選擇要查看的JVM。
二、jinfo
jinfo可以查看設置的jvm的信息
|
1
2
3
4
5
6
7
|
jinfo -flag MaxHeapSize [pid] 能夠查看最大堆內存
jinfo -flag ThreadStackSize [pid]
jinfo -flags [pid]
jinfo -flag UseConcMarkSweepGC [pid]
jinfo -flag UseG1GC [pid]
jinfo -flag UseParallelGC [pid]
|
三、查看jvm運行時的參數
|
1
2
3
4
5
6
7
8
9
10
11
|
1）java -XX:+PrintFlagsFinal -version
得出的結果，如果是
= 表示默認值
:= 表示被用戶或者jvm修改后的值
2）-XX:+UnlockDiagnosticVMOptions 解鎖診斷參數
-XX:+PrintCommandLineFlags 打印命令行參數
3）jps
jps這個沒什么好說的，在linux里面
ps
是查看進程，jps就是java的
ps
，查看java進程
如果執行
"jps -l"
就能查看整個類名
|
四、jstat
這個指令用來查看jvm統計信息，主要分以下三類：
|
1
2
3
4
5
6
7
8
9
10
|
1）類裝載
jstat -class [pid] 1000 10
這個指令指的是每1秒（1000就是1000ms）查看一次類的裝載信息，一共看十次。后面的1000和10可以不要
2）垃圾收集
-gc、-gcutil、-gccause、-gcnew、-gcold
3）JIT編譯
jstat -compiler [pid]
jstat -printcompilation [pid]
|
五、jmap
jmap是一個很重要的命令，可以查看jvm內存使用情況。可以分為兩點講解：
|
1
2
3
4
5
6
7
8
9
10
11
12
|
1）導出內存映像文件
內存溢出自動導出，設置參數既可：
+XX:HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./
不用多說，設置內存溢出自動導出還有導出的路徑
使用jmap命令手動導出：
jmap -dump:
format
=b,
file
=heap.hprof [pid]
其中
format
=b代表用二進制導出
2）查看內存映像文件：
在這里http:
//www
.eclipse.org
/mat/downloads
.php下載內存分析工具，然后把dump文件導入分析就可以了。
|
六 、jstack
jstack也是一個很重要的命令，可以查看線程使用情況。這里需要知道現場的幾種狀態，參考如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
- NEW狀態： The thread has not yet started.
- RUNNABLE狀態：The thread is executing
in
the JVM.
- BLOCKED狀態：The thread is blocked waiting
for
a monitor lock.
- WAITING狀態：The thread is waiting indefinitely
for
another thread to perform a particular action.
- TIMED_WAITING狀態：The thread is waiting
for
another thread to perform an action
for
up to a specified waiting
time
.
- TERMINATED狀態：The thread has exited.
狀態之間是怎么轉換的呢？參考如下：
jvm里面查看線程使用情況的命令
"jstack [pid]"
，將得到的線程情況輸入一個叫做stack.txt的文件：
這個stack.txt文件能夠查看到jvm里面某個
id
的線程是用來做什么的？如果發生了死鎖，在最后也會列舉出來。
在linux里面怎么知道線程線上執行的情況呢，哪些線程占用了很大的內存呢？
這時可以用這個命令
"top -p [pid] -H"
就能夠看到單個進程里面線程的情況：
通過
printf
"%x"
[pid] 可以將10精致的pid 轉換為16進制，轉換成16進制有什么用？
因為jstack出來的線程是十六進制的，通過剛剛那個值，就能夠在jstack出來的文件里面找到使用內存最多的線程是哪一個線程了。
|
七、jvisualvm
jvisualvm是一個可視化工具，集成了上面指令的幾乎所有功能，但是它更加直觀，所以jvisualvm也很重要。它也在jdk目錄的bin目錄下。監控本地應用很簡單，直接打開jvisualvm就能看到有本地的了。下面着重介紹監控遠程的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
1）監控遠程tomcat
修改tomcat的Catalina.sh
JAVA_OPTS=
'-Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=192.168.1.54'
參數說明：
第一個參數是端口，不用說；
第二個參數是不需要ssl驗證，鏈接的時候不勾那個屬性
第三個參數是不需要驗證
第四個參數是這個tomcat應用的地址，注意不是jvisualvm的地址。
2）監控遠程java應用：
nohup
java
-Dcom.sun.management.jmxremote
-Djava.rmi.server.
hostname
=192.168.1.54
-Dcom.sun.management.jmxremote.port=12344
-Dcom.sun.management.jmxremote.ssl=
false
-
Dcom.sun.management.jmxremote.authenticate=
false
-Djava.net.preferIPv4Stack=
true
-jar
test
.jar
命令是一樣的，但是一定要記住的是這里的192.168.1.54一定是我們的java的應用地址，而不是jvisual的地址！！
記得開放端口, 然后把需要的添加的機器192.168.1.54添加到jvisualvm的
"遠程"
標簽里面，然后在“遠程“標簽里面添加端口在ip后面就可以。
|
這里說一下監控遠程可能會有一點坑，原因如下：
1）首先確保在java應用的機器里面可以使用jvisualvm才可以，也就是在java應用的機器里面調用jvisualvm沒有報錯（可能只是warning），才可以。
2）可能是jdk版本的問題。有可能確認了多少遍端口和應用的問題，但是就是連不上，所以就要看看是不是jdk版本的問題（也許不是，所以就在需要監控的java應用程序的機器上先試下jvisualvm）
JVM性能優化建議
一、JVM堆內存划分
JDK7及以前的版本：一個對象被創建以后首先被放到Nursery內存中的Eden內 存中，如果存活期超兩個Survivor之后就會被轉移到長時內存中(Old Generation)中。永久內存中存放着對象的方法、變量等元數據信息。通過如果永久內存不夠，就會得到如下錯誤：Java.lang.OutOfMemoryError: PermGen
JDK8版本：JDK8中把存放元數據中的永久內存從堆內存中移到了本地內存(native memory)中，這樣永久內存就不再占用堆內存，它可以通過自動增長來避免JDK7以及前期版本中常見的永久內存錯誤(java.lang.OutOfMemoryError: PermGen)。JDK8也提供了一個新的設置Matespace內存大小的參數：
|
1
|
-XX:MaxMetaspaceSize=128m
|
需要注意：如果不設置Matespaces內存大小參數，JVM將會根據一定的策略自動增加本地元內存空間。如果你設置的元內存空間過小，你的應用程序可能得到以下錯誤：java.lang.OutOfMemoryError: Metadata space
二、JVM參數
-XX 參數被稱為不穩定參數，此類參數的設置很容易引起JVM性能上的差異。
1）不穩定參數語法規則
布爾類型
|
1
2
|
-XX:+<option>
'+'
表示啟用該選項
-XX:-<option>
'-'
表示關閉該選項
|
數字類型
|
1
2
|
-XX:<option>=<number>
# 可跟隨單位，例如：'m'或'M'表示兆字節;'k'或'K'千字節;'g'或'G'千兆字節。32K與32768是相同大小的。
|
字符串類型
|
1
2
|
-XX:<option>=<string>
# 通常用於指定一個文件、路徑或一系列命令列表。例如：-XX:HeapDumpPath=./dump.core
|
2）行為選項
| 選項 | 默認值 | 描述 |
| -XX:-AllowUserSignalHandlers | 限於Linux和Solaris默認關閉 | 允許為java進程安裝信號處理器。 |
| -XX:AltStackSize=16384 | 僅適用於Solaris，從5.0中刪除 | 備用信號堆棧大小（以字節為單位） |
| -XX:-DisableExplicitGC | 默認關閉 | 禁止在運行期顯式地調用 System.gc()。注意：你熟悉的代碼里沒調用System.gc()，不代表你依賴的框架工具沒在使用。 |
| -XX:+FailOverToOldVerifier | Java6新引入選項，默認啟用 | 如果新的Class校驗器檢查失敗，則使用老的校驗器。解決兼容性問題。 關聯選項：-XX:+UseSplitVerifier |
| -XX:+HandlePromotionFailure | Java1.5以前默認關閉,Java1.6后默認啟用 | 新生代收集擔保，於年老代預留內存。 |
| -XX:+MaxFDLimit | 限於Solaris,默認啟用 | 設置java進程可用文件描述符為操作系統允許的最大值。 |
| -XX:PreBlockSpin | 默認10 | 控制多線程自旋鎖優化的自旋次數 前置選項： -XX:+UseSpinning |
| -XX:-RelaxAccessControlCheck | 默認關閉,Java1.6引入 | 在Class校驗器中，放松對訪問控制的檢查。作用與reflection里的setAccessible類似。 |
| -XX:+ScavengeBeforeFullGC | 默認啟用 | 在Full GC前觸發一次Minor GC |
| -XX:+UseAltSigs | 限於Solaris 默認啟用 |
為了防止與其他發送信號的應用程序沖突，允許使用候補信號替代 SIGUSR1和SIGUSR2。 |
| -XX:+UseBoundThreads | 限於Solaris 默認啟用 |
綁定所有的用戶線程到內核線程。 減少線程進入飢餓狀態（得不到任何cpu time）的次數。 |
| -XX:-UseConcMarkSweepGC | 默認關閉,Java1.4引入 | 啟用CMS低停頓垃圾收集器。 |
| -XX:+UseGCOverheadLimit | 默認啟用,Java1.6引入 | 限制GC的運行時間。如果GC耗時過長，就拋OutOfMemoryError。 |
| -XX:+UseLWPSynchronization | 限於solaris, 默認啟用, Java1.4引入 | 使用輕量級進程（內核線程）替換線程同步。 |
| -XX:-UseParallelGC | -server時啟用, 其他情況下:默認關閉, Java1.4引入 | 為新生代使用並行清除，年老代使用單線程Mark-Sweep-Compact的垃圾收集器。 |
| -XX:-UseParallelOldGC | 默認關閉, Java1.5引入 | 為老年代和新生代都使用並行清除的垃圾收集器。開啟此選項將自動開啟-XX:+UseParallelGC 選項 |
| -XX:-UseSerialGC | -client時啟用, 默認關閉, Java1.5引入 | 使用串行垃圾收集器。 |
| -XX:-UseSpinning | Java1.4.2和1.5需要手動啟用, Java1.6默認已啟用 | 啟用多線程自旋鎖優化。關聯選項：-XX:PreBlockSpin=10 |
| -XX:+UseTLAB | Java1.4.2以前和使用-client選項時：默認關閉, 其余版本默認啟用 | 啟用線程本地緩存區(Thread Local) |
| -XX:+UseSplitVerifier | Java1.5默認關閉, Java1.6默認啟用 | 使用新的Class類型校驗器 。關聯選項: -XX:+FailOverToOldVerifier |
| -XX:+UseThreadPriorities | 默認啟用 | 使用本地線程的優先級。 |
| -XX:+UseVMInterruptibleIO | 限於solaris, 默認啟用, Java1.6引入 | 在solaris中，允許運行時中斷線程 |
3）性能選項
| 選項 | 默認值 | 描述 |
| -XX:+AggressiveOpts | Java1.5 引入,默認關閉,Java1.6后默認開啟 | 開啟編譯器性能優化。 |
| -XX:CompileThreshold=10000 | 默認值：1000 | 通過JIT編譯器，將方法編譯成機器碼的觸發閥值，可以理解為調用方法的次數，例如調1000次，將方法編譯為機器碼。 [-client: 1,500] |
| -XX:LargePageSizeInBytes=4m | 默認值：4m,amd64位：2m | 設置堆內存的內存最大值。 |
| -XX:MaxHeapFreeRatio=70 | 默認70 | GC后，如果發現空閑堆內存占到整個預估上限值的70%，則收縮預估上限值。 |
| -XX:MaxNewSize=size | 1.3.1 Sparc： 32m,1.3.1 x86： 2.5m | 新生代占整個堆內存的最大值。從Java1.4開始, MaxNewSize成為 NewRatio的一個函數 |
| -XX:MaxPermSize=64m | Java1.5以后:：64 bit VMs會增大預設值的30%,1.4 amd64:：96m,1.3.1 -client: 32m,其他默認 64m | Perm（俗稱方法區）占整個堆內存的最大值。 |
| -XX:MinHeapFreeRatio=40 | 默認值：40 | GC后，如果發現空閑堆內存占到整個預估上限值的40%，則增大上限值。關聯選項：-XX:MaxHeapFreeRatio=70 |
| -XX:NewRatio=2 | Sparc -client: 8,x86 -server: 8 ,x86 -client: 12 -client: 4 (1.3) 8 (1.3.1+) ,x86: 12 ,其他:2 | 新生代和年老代的堆內存占用比例。 例如2表示新生代占年老代的1/2，占整個堆內存的1/3。 |
| -XX:NewSize=2m | 5.0以后: 64 bit Vms 會增大預設值的30%,x86: 1m,x86, 5.0以后: 640k,其他:2.125m | 新生代預估上限的默認值。 |
| -XX:ReservedCodeCacheSize=32m | Solaris 64-bit, amd64, -server x86: 48m ,1.5.0_06之前, Solaris 64-bit ,amd64: 1024m ,其他：32m | 設置代碼緩存的最大值，編譯時用。 |
| -XX:SurvivorRatio=8 | Solaris amd64: 6 ,Sparc in 1.3.1: 25 ,Solaris platforms 5.0以前: 32 ,其他：8 | Eden與Survivor的占用比例。例如8表示，一個survivor區占用 1/8 的Eden內存，即1/10的新生代內存，為什么不是1/9？ 因為我們的新生代有2個survivor，即S1和S22。所以survivor總共是占用新生代內存的 2/10，Eden與新生代的占比則為 8/10。 |
| -XX:TargetSurvivorRatio=50 | 默認值：50 | 實際使用的survivor空間大小占比。默認是47%，最高90%。 |
| -XX:ThreadStackSize=512 | Sparc: 512 ,Solaris x86: 320 (5.0以前 256) ,Sparc 64 bit: 1024 Linux amd64: 1024 (5.0 以前 0) ,其他：512. | 線程堆棧大小, |
| -XX:+UseBiasedLocking | Java1.5 update 6后引入,默認關閉。Java1.6默認啟用。 | 啟用偏向鎖 |
| -XX:+UseFastAccessorMethods | 默認啟用 | 優化原始類型的getter方法性能。 |
| -XX:-UseISM | 默認啟用 | 啟用solaris的ISM |
| -XX:+UseLargePages | Java1.5 update 5后引入,默認關閉,Java1.6默認啟用 | 啟用大內存分頁。關聯選項：-XX:LargePageSizeInBytes=4m |
| -XX:+UseMPSS | Java1.4.1 之前默認關閉,其他版本默認啟用 | 啟用solaris的MPSS，不能與ISM同時使用。 |
| -XX:+UseStringCache | 默認開啟 | 緩存常用字符串。 |
| -XX:AllocatePrefetchLines=1 | 默認值：1 | 在使用JIT生成的預讀取指令分配對象后讀取的緩存行數。如果上次分配的對象是一個實例則默認值是1，如果是一個數組則是3 |
| -XX:AllocatePrefetchStyle=1 | 默認值：1 | 預讀取指令的生成代碼風格,0- 無預讀取指令生成 ,1-在每次分配后執行預讀取命令 ,2-當預讀取指令執行后使用TLAB()分配水印指針來找回入口, |
| -XX:+UseCompressedStrings | Java1.6 update 21引入 | 其中，對於不需要16位字符的字符串，可以使用byte[] 而非char[]。對於許多應用，這可以節省內存，但速度較慢（5％-10％） |
| -XX:+OptimizeStringConcat | Java1.6 update 20引入 | 在可能的情況下優化字符串連接操作。 |
4）調試選項
| 選項 | 默認值 | 描述 |
| -XX:-CITime | 默認啟用 | 打印JIT編譯器編譯耗時。 |
| -XX:ErrorFile=./hs_err_pid.log | Java1.6引入 | 如果JVM crashed，將錯誤日志輸出到指定文件路徑。 |
| -XX:-ExtendedDTraceProbes | Java6引入，限於solaris,默認關閉 | 啟用dtrace診斷 |
| -XX:HeapDumpPath=./java_pid.hprof | 默認是java進程啟動位置 | 堆內存快照的存儲文件路徑。 |
| -XX:-HeapDumpOnOutOfMemoryError | 默認關閉 | 在java.lang.OutOfMemoryError 異常出現時，輸出一個dump.core文件，記錄當時的堆內存快照（見 -XX:HeapDumpPath 的描述） |
| -XX:OnError=”\;\” | Java1.4引入 | 當java每拋出一個ERROR時，運行指定命令行指令集。指令集是與OS環境相關的，在Linux下多數是.sh腳本，windows下是.bat批處理。 |
| -XX:OnOutOfMemoryError=”\;\” | Java1.4.2 update 12和Java6時引入 | 當第一次發生java.lang.OutOfMemoryError 時，運行指定命令行指令集。指令集是與OS環境相關的，在linux下多數是.sh腳本，windows下是.bat批處理。 |
| -XX:-PrintClassHistogram | 默認關閉 | 在Windows下, 按ctrl-break或Linux下是執行kill -3（發送SIGQUIT信號）時，打印class柱狀圖。 jmap -histo pid也實現了相同的功能。 |
| -XX:-PrintConcurrentLocks | 默認關閉 | 在thread dump的同時，打印java.util.concurrent的鎖狀態。jstack -l pid 也同樣實現了同樣的功能。 |
| -XX:-PrintCommandLineFlags | Java1.5 引入，默認關閉 | Java啟動時，往stdout打印當前啟用的非穩態jvm options。 例如：-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:+DoEscapeAnalysis |
| -XX:-PrintCompilation | 默認關閉 | 往stdout打印方法被JIT編譯時的信息。 |
| -XX:-PrintGC | 默認關閉 | 開啟GC日志打印。顯示結果例如： [Full GC 131115K->7482K(1015808K), 0.1633180 secs] ,該選項可通過com.sun.management.HotSpotDiagnosticMXBean API 和 jconsole 動態啟用。 |
| -XX:-PrintGCDetails | Java1.4引入，默認關閉 | 打印GC回收的詳細信息。 顯示結果例如： [Full GC (System) [Tenured: 0K->2394K(466048K), 0.0624140 secs] 30822K->2394K(518464K), [Perm : 10443K->10443K(16384K)], 0.0625410 secs] [Times: user=0.05 sys=0.01, real=0.06 secs] ,該選項可通過com.sun.management.HotSpotDiagnosticMXBean API 和 jconsole 動態啟用。 |
| -XX:-PrintGCTimeStamps | 默認關閉 | 打印GC停頓耗時。 顯示結果例如： 2.744: [Full GC (System) 2.744: [Tenured: 0K->2441K(466048K), 0.0598400 secs] 31754K->2441K(518464K), [Perm : 10717K->10717K(16384K)], 0.0599570 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] ,該選項可通過com.sun.management.HotSpotDiagnosticMXBean API 和 jconsole 動態啟用。 |
| -XX:-PrintTenuringDistribution | 默認關閉 | 打印對象的存活期限信息。 顯示結果例如： [GC Desired survivor size 4653056 bytes, new threshold 32 (max 32) - age 1: 2330640 bytes, 2330640 total - age 2: 9520 bytes, 2340160 total 204009K->21850K(515200K), 0.1563482 secs] ,Age1,2表示在第1和2次GC后存活的對象大小。 |
| -XX:-TraceClassLoading | 默認關閉 | 打印class裝載信息到stdout。記Loaded狀態。 例如： [Loaded java.lang.Object from /opt/taobao/install/jdk1.6.0_07/jre/lib/rt.jar] |
| -XX:-TraceClassLoadingPreorder | 1.4.2引入，默認關閉 | 按class的引用/依賴順序打印類裝載信息到stdout。不同於 TraceClassLoading，本選項只記 Loading狀態。 例如： [Loading java.lang.Object from /home/confsrv/jdk1.6.0_14/jre/lib/rt.jar] |
| -XX:-TraceClassResolution | 1.4.2引入，默認關閉 | 打印所有靜態類，常量的代碼引用位置。用於debug。 例如： RESOLVE java.util.HashMap java.util.HashMapEntryHashMap.java:209<br>說明HashMap類的209行引用了靜態類java.util.HashMapEntryHashMap.java:209<br>說明HashMap類的209行引用了靜態類java.util.HashMapEntry |
| -XX:-TraceClassUnloading | 默認關閉 | 打印class的卸載信息到stdout。記Unloaded狀態。 |
| -XX:-TraceLoaderConstraints | Java1.6 引入，默認關閉 | 打印class的裝載策略變化信息到stdout。裝載策略變化是實現classloader隔離/名稱空間一致性的關鍵技術。 |
| -XX:+PerfSaveDataToFile | 默認啟用 | 當java進程因java.lang.OutOfMemoryError 異常或crashed 被強制終止后，生成一個堆快照文件。 |
| -XX:ParallelGCThreads=n | 默認值：隨JVM運行平台不同而異 | 配置並行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。 |
| -XX:+UseCompressedOops | 32位默認關閉，64位默認啟動 | 使用compressed pointers。這個參數默認在64bit的環境下默認啟動，但是如果JVM的內存達到32G后，這個參數就會默認為不啟動，因為32G內存后，壓縮就沒有多大必要了，要管理那么大的內存指針也需要很大的寬度了 |
| -XX:+AlwaysPreTouch | 默認關閉 | 在JVM 初始化時預先對Java堆進行摸底。 |
| -XX:AllocatePrefetchDistance=n | 默認值取決於當前JVM 設置 | 為對象分配設置預取距離。 |
| -XX:InlineSmallCode=n | 默認值取決於當前JVM 設置 | 當編譯的代碼小於指定的值時,內聯編譯的代碼。 |
| -XX:MaxInlineSize=35 | 默認值：35 | 內聯方法的最大字節數。 |
| -XX:FreqInlineSize=n | 默認值取決於當前JVM 設置 | 內聯頻繁執行的方法的最大字節碼大小。 |
| -XX:LoopUnrollLimit=n | 默認值取決於當前JVM 設置 | 代表節點數目小於給定值時打開循環體。 |
| -XX:InitialTenuringThreshold=7 | 默認值：7 | 設置初始的對象在新生代中最大存活次數。 |
| -XX:MaxTenuringThreshold=n | 默認值：15，最大值：15 | 設置對象在新生代中最大的存活次數，最大值15，並行回收機制默認為15，CMS默認為4。 |
| -Xloggc: | 默認關閉 | 輸出GC 詳細日志信息至指定文件。 |
| -XX:-UseGCLogFileRotation | 默認關閉 | 開啟GC 日志文件切分功能，前置選項 -Xloggc |
| -XX:NumberOfGClogFiles=1 | 必須>=1，默認值：1 | 設置切分GC 日志文件數量，文件命名格式：.0, .1, …, .n-1 |
| -XX:GCLogFileSize=8K | 必須>=8K，默認值：8K | GC日志文件切分大小。 |
三、垃圾收集器
1. 串行回收器
1.1）新生代串行回收器
特點
- 它僅僅使用單線程進行垃圾回收
- 它是獨占式的垃圾回收
- 進行垃圾回收時, Java應用程序中的線程都需要暫停(Stop-The-World)
- 使用復制算法
- 適合CPU等硬件不是很好的場合
設置參數
|
1
|
-XX:+UseSerialGC 指定新生使用新生代串行收集器和老年代串行收集器, 當以client模式運行時, 它是默認的垃圾收集器
|
1.2）老年代串行回收器
特點
- 同新生代串行回收器一樣, 單線程, 獨占式的垃圾回收器
- 通常老年代垃圾回收比新生代回收要更長時間, 所以可能會使應用程序停頓較長時間
設置參數
|
1
2
3
|
-XX:+UseSerialGC 新生代, 老年代都使用串行回收器
-XX:+UseParNewGC 新生代使用ParNew回收器, 老年代使用串行回收器
-XX:+UseParallelGC 新生代使用ParallelGC回收器, 老年代使用串行回收器
|
2. 並行回收器
2.1）新生代ParNew回收器
特點
- 將串行回收多線程化
- 使用復制算法
- 垃圾回收時, 應用程序仍會暫停, 只不過由於是多線程回收, 在多核CPU上，回收效率會高於串行回收器, 反之在單核CPU， 效率會不如串行回收器
設置參數
|
1
2
3
|
-XX:+UseParNewGC 新生代使用ParNew回收器, 老年代使用串行回收器
-XX:+UseConcMarkSweepGC 新生代使用ParNew回收器, 老年代使用CMS回收器
-XX:ParallelGCThreads=n 指回ParNew回收器工作時的線程數量, cpu核數小時8時, 其值等於cpu數量, 高於8時,可以使用公式(3+((5*CPU_count)
/8
))
|
2.2）新生代ParallelGC回收器
特點
- 同ParNew回收器一樣， 不同的地方在於，它非常關注系統的吞吐量(通過參數控制)
- 使用復制算法
- 支持自適應的GC調節策略
設置參數
|
1
2
3
4
5
|
-XX:+UseParallelGC 新生代用ParallelGC回收器, 老年代使用串行回收器
-XX:+UseParallelOldGC 新生代用ParallelGC回收器, 老年代使用ParallelOldGC回收器系統吞吐量的控制:
-XX:MaxGCPauseMillis=n(單位ms) 設置垃圾回收的最大停頓時間,
-XX:GCTimeRatio=n(n在0-100之間) 設置吞吐量的大小, 假設值為n, 那系統將花費不超過1/(n+1)的時間用於垃圾回收
-XX:+UseAdaptiveSizePolicy 打開自適應GC策略, 在這種模式下, 新生代的大小, eden,survivior的比例, 晉升老年代的對象年齡等參數會被自動調整,以達到堆大小, 吞吐量, 停頓時間之間的平衡點
|
2.3）老年代ParallelOldGC回收器
特點
- 同新生代的ParallelGC回收器一樣, 是屬於老年代的關注吞吐量的多線程並發回收器
- 使用標記壓縮算法
設置參數
|
1
2
|
-XX:+UseParallelOldGC 新生代用ParallelGC回收器, 老年代使用ParallelOldGC回收器, 是非常關注系統吞吐量的回收器組合, 適合用於對吞吐量要求較高的系統
-XX:ParallelGCThreads=n 指回ParNew回收器工作時的線程數量, cpu核數小時8時, 其值等於cpu數量, 高於8時, 可以使用公式(3+((5*CPU_count)
/8
))
|
3. CMS回收器（Concurrent Mark Sweep，並發標記清除）
3.1）老年代的並發回收器
特點
- 是並發回收, 非獨占式的回收器, 大部分時候應用程序不會停止運行
- 針對年老代的回收器
- 使用並發標記清除算法, 因此回收后會有內存碎片, 可以使參數設置進行內存碎片的壓縮整理
- 與ParallelGC和ParallelOldGC不同, CMS主要關注系統停頓時間
主要步驟
- 初始標記
- 並發標記
- 預清理
- 重新標記
- 並發清理
- 並發重置
需要注意：初始標記與重新標記是獨占系統資源的，不能與用戶線程一起執行，而其它階段則可以與用戶線程一起執行
設置參數
|
1
2
3
4
5
6
7
8
9
10
11
|
-XX:-CMSPrecleaningEnabled 關閉預清理, 不進行預清理, 默認在並發標記后, 會有一個預清理的操作，可減少停頓時間
-XX:+UseConcMarkSweepGC 老年代使用CMS回收器, 新生代使用ParNew回收器
-XX:ConcGCThreads=n 設置並發線程數量,
-XX:ParallelCMSThreads=n 同上, 設置並發線程數量,
-XX:CMSInitiatingOccupancyFraction=n 指定老年代回收閥值, 即當老年代內存使用率達到這個值時, 會執行一次CMS回收，默認值為68, 設置技巧: (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)
/100
)>=Xmn
-XX:+UseCMSCompactAtFullCollection 開啟內存碎片的整理, 即當CMS垃圾回收完成后, 進行一次內存碎片整理, 要注意內存碎片的整理並不是並發進行的, 因此可能會引起程序停頓
-XX:CMSFullGCsBeforeCompation=n 用於指定進行多少次CMS回收后， 再進行一次內存壓縮
-XX:+CMSParallelRemarkEnabled 在使用UseParNewGC 的情況下, 盡量減少 mark 的時間
-XX:+UseCMSInitiatingOccupancyOnly 表示只有達到閥值時才進行CMS回收
-XX:+CMSConcurrentMTEnabled 當該標志被啟用時，並發的CMS階段將以多線程執行，默認開啟
-XX:+CMSIncrementalMode 在增量模式下，CMS 收集器在並發階段，不會獨占整個周期，而會周期性的暫停，喚醒應用線程。收集器把並發階段工作，划分為片段，安排在次級(minor) 回收之間運行。這對需要低延遲，運行在少量CPU服務器上的應用很有用。
|
3.2）Class的回收(永久區的回收)
設置參數
|
1
2
|
-XX:+CMSClassUnloadingEnabled 開啟回收Perm區的內存, 默認情況下, 是需要觸發一次FullGC
-XX:CMSInitiatingPermOccupancyFraction=n 當永久區占用率達到這個n值時，啟動CMS回收, 需上一個參數開啟的情況下使用
|
4. G1回收器（JDK1.7后全新的回收器, 用於取代CMS)
4.1）概述
特點
- 獨特的垃圾回收策略, 屬於分代垃圾回收器
- 使用分區算法, 不要求eden, 年輕代或老年代的空間都連續
- 並行性：回收期間, 可由多個線程同時工作, 有效利用多核cpu資源
- 並發性：與應用程序可交替執行, 部分工作可以和應用程序同時執行
- 分代GC:：分代收集器, 同時兼顧年輕代和老年代
- 空間整理：回收過程中, 會進行適當對象移動, 減少空間碎片
- 可預見性：G1可選取部分區域進行回收, 可以縮小回收范圍, 減少全局停頓
主要步驟
- 新生代GC
- 並發標記周期
|
1
|
初始標記新生代GC(此時是並行, 應用程序會暫停止) –> 根區域掃描 –> 並發標記 –> 重新標記(此時是並行, 應用程序會暫停止) –> 獨占清理(此時應用程序會暫停止) –> 並發清理
|
- 混合回收
|
1
|
這個階段即會執行正常的年輕代gc, 也會選取一些被標記的老年代區域進行回收, 同時處理新生代和年老輕
|
- 若需要,會進行FullGC
|
1
2
3
|
混合GC時發生空間不足
在新生代GC時, survivor區和老年代無法容納幸存對象時
以上兩者都會導致一次FullGC產生
|
設置參數
|
1
2
3
4
|
-XX:+UseG1GC 打開G1收集器開關，
-XX:MaxGCPauseMillis=n 指定目標的最大停頓時間，任何一次停頓時間超過這個值, G1就會嘗試調整新生代和老年代的比例, 調整堆大小, 調整晉升年齡
-XX:ParallelGCThreads=n 用於設置並行回收時, GC的工作線程數量
-XX:InitiatingHeapOccpancyPercent=n 指定整個堆的使用率達到多少時, 執行一次並發標記周期, 默認45， 過大會導致並發標記周期遲遲不能啟動, 增加FullGC的可能, 過小會導致GC頻繁, 會導致應用程序性能有所下降
|
4.2）參數選項
| 選項 | 默認值 | 描述 |
| -XX:+UseG1GC | 默認關閉 | 使用G1垃圾處理器 |
| -XX:MaxGCPauseMillis=n | 默認值：4294967295 | 設置並行收集最大暫停時間，這是一個理想目標，JVM將盡最大努力來實現它。 |
| -XX:InitiatingHeapOccupancyPercent=n | 默認值：45 | 啟動一個並發垃圾收集周期所需要達到的整堆占用比例。這個比例是指整個堆的占用比例而不是某一個代（例如G1）,如果這個值是0則代表‘持續做GC’。默認值是45 |
| -XX:NewRatio=n | 默認值：2 | 設置年輕代和年老代的比值。例如:值為3，則表示年輕代與年老代比值為1：3，年輕代占整個年輕代年老代和的1/4。 |
| -XX:SurvivorRatio=n | 默認值：8 | 年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示Eden：Survivor=3：2，一個Survivor區占整個年輕代的1/5 |
| -XX:MaxTenuringThreshold=n | 默認值：15 | 設置垃圾最大存活閥值。如果設置為0的話，則年輕代對象不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。 |
| -XX:ParallelGCThreads=n | 默認值：隨JVM運行平台不同而異 | 配置並行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。 |
| -XX:ConcGCThreads=n | 默認值：隨JVM運行平台不同而異 | 並行垃圾收集時，使用的線程數。默認值和JVM運行的平台有關。 |
| -XX:G1ReservePercent=n | 默認值：10 | 設置保留用來做假天花板以減少晉升（新生代對象晉升到老生代）失敗可能性的堆數目。 |
| -XX:G1HeapRegionSize=n | 默認值根據堆大小而定 | 使用G1垃圾回收器，java堆被划分成統一大小的區塊。這個選項設置每個區塊的大小。最小值是1Mb，最大值是32Mb。 |
4.3）其他GC相關的設置
4.3.1）System.gc()
|
1
2
3
4
5
|
1）禁用System.gc()
-XX:+DisableExplicitGC 禁止程序中調用System.gc()， 加了此參數, 程序若有調用, 返回的空函數調用System.gc()的調用, 會使用FullGC的方式回收整個堆而會忽略CMS或G1等相關回收器
2）System.gc()使用並發回收
-XX:+ExplicitGCCinvokesConcurrent 使用並發方式處理顯示的gc, 即開啟后, System.gc()這種顯示GC才會並發的回收, (CMS, G1)
|
4.3.2）並行GC前額外觸發的新生代GC
|
1
2
3
|
1）使用並行回收器 (UseParallelGC或者UseParallelOldGC)時, 會額外先觸發一個新生代GC, 目的是盡可能減少停頓時間
2）若不需要這種特性, 可以使用以下參數去除
-XX:-ScavengeBeforeFullGC 即去除在FullGC之前的那次新生代GC, 原本默認值為
true
|
4.3.3）對象何時進入老年代
|
1
2
3
4
5
6
7
8
9
10
|
1）當對象首次創建時, 會放在新生代的eden區, 若沒有GC的介入，會一直在eden區, GC后，是可能進入survivor區或者年老代
2）當對象年齡達到一定的大小 ,就會離開年輕代， 進入老年代， 對象進入老年代的事件稱為晉升, 而對象的年齡是由GC的次數決定的,
每一次GC，若對象沒有被回收, 則對象的年齡就會加1, 可以使用以下參數來控制新生代對象的最大年齡：
-XX:MaxTenuringThreshold=n 假設值為n ， 則新生代的對象最多經歷n次GC， 就能晉升到老年代, 但這個必不是晉升的必要條件
-XX:TargetSurvivorRatio=n 用於設置Survivor區的目標使用率，即當survivor區GC后使用率超過這個值, 就可能會使用較小的年齡作為晉升年齡
3）除年齡外, 對象體積也會影響對象的晉升的, 若對象體積太大, 新生代無法容納這個對象, 則這個對象可能就會直接晉升至老年代, 可通過以下參
數使用對象直接晉升至老年代的閾值, 單位是byte
-XX:PretenureSizeThreshold 即對象的大小大於此值, 就會繞過新生代, 直接在老年代分配, 此參數只對串行回收器以及ParNew回收有效, 而對ParallelGC回收器無效
|
4.3.4）在TLAB上分配對象（Thread Local Allocation Buffer, 線程本地分配緩存）
|
1
2
3
4
5
6
7
8
|
TLAB是一個線程專用的內存分配區域, 虛擬機為線程分配空間, 針對於體積不大的對象, 會優先使用TLAB, 這個可以加速對象的分配, TLAB是默認開啟的, 若要關閉可以使用以下參數關閉
-XX:-UseTLAB 關閉TLAB
-XX:+UseTLAB 開啟TLAB, 默認也是開啟的
-XX:+PrintTLAB 觀察TALB的使用情況
-XX:TLABRefillWasteFraction=n 設置一個比率n， 而refill_waste的值就是(TLAB_SIZE
/n
), 即TLAB空間較小， 大對象無法分配在TLAB，所以會直接分配到堆上，TLAB較小也很容易裝滿, 因此當TLAB的空間不夠分配一個新對象, 就會考慮廢棄當前TLAB空間還是直接分配到堆上, 就會使用此參數進行判斷, 小於refill_waste就允許廢棄, 而新建TLAB來分配對象，而大於refill_waste就直接在堆上分配, 默認是64
-XX:+ResizeTLAB 開啟TLAB自動調整大小, 默認是開啟的, 若要關閉把+號換成-號即可
-XX:TLABSize=n 設置一個TLAB的大小, 前提先關閉TLAB的自動調整
|
5. 性能調優工具
5.1）jps (Java Virtual Machine Process Status Tool)
主要用來輸出JVM中運行的進程狀態信息。語法格式如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
jps [options] [hostid]
# hostid語法如下：
[protocol:][[
//
]
hostname
][:port][
/servername
]
protocol - 如果protocol及
hostname
都沒有指定，那表示的是與當前環境相關的本地協議，如果指定了
hostname
卻沒有指定protocol，那么protocol的默認就是rmi。
hostname
- 服務器的IP或者名稱，沒有指定則表示本機。
port - 遠程rmi的端口，如果沒有指定則默認為1099。
Servername - 注冊到RMI注冊中心中的jstatd的名稱。
# 如果不指定hostid就默認為當前主機或服務器。
# 命令行參數選項
-q 忽略輸出類名、Jar名和傳入main方法的參數
-m 輸出傳入main方法的參數
-l 輸出main類或Jar的全限名
-
v
輸出傳入JVM的參數
-V 輸出通過標記的文件傳遞給JVM的參數（.hotspotrc文件，或者是通過參數-XX:Flags=<filename>指定的文件）
-J 用於傳遞jvm選項到由javac調用的java加載器中，例如，“-J-Xms48m”將把啟動內存設置為48M，使用-J選項可以非常方便的向基於Java的開發的底層虛擬機應用程序傳遞參數。
|
5.2）stack（Java Stack Trace）
主要用來查看某個Java進程內的線程堆棧信息。語法格式如下:
|
1
2
3
4
5
6
7
8
9
|
jstack [option] pid
jstack [option] executable core
jstack [option] [server-
id
@]remote-
hostname
-or-ip
# 命令行參數選項說明如下：
-l 長列表，會打印出額外的鎖信息，在發生死鎖時可以用jstack -l pid來觀察鎖持有情況
-m mixed mode，不僅會輸出Java堆棧信息，還會輸出C
/C
++堆棧信息（比如Native方法）
-F 當’jstack [-l] pid’沒有相應的時候強制打印棧信息
-h | -help打印幫助信息
|
jstack可以定位到線程堆棧，根據堆棧信息我們可以定位到具體代碼，所以它在JVM性能調優中使用得非常多。
5.3）jmap（Java Memory Map）
jmap用來查看堆內存使用狀況，一般結合jhat使用。jmap語法格式如下：（如果運行在64位JVM上，可能需要指定-J-d64命令選項參數）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
jmap [option] pid
jmap [option] executable core
jmap [option] [server-
id
@]remote-
hostname
-or-ip
# 參數說明
executable 產生core dump的java可執行程序
core 將被打印信息的core dump文件
remote-
hostname
-or-ip 遠程debug服務的主機名或ip
server-
id
唯一
id
,假如一台主機上多個遠程debug服務
pid 需要被打印配相信息的java進程
id
，可以用jps查問
# 基本參數
-dump:[live,]
format
=b,
file
=<filename> 使用hprof二進制形式,輸出jvm的heap內容到文件=. live子選項是可選的，假如指定live選項,那么只輸出活的對象到文件
-finalizerinfo 打印正等候回收的對象的信息
-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情況
-histo[:live] 打印每個class的實例數目,內存占用,類全名信息. VM的內部類名字開頭會加上前綴”*”. 如果live子參數加上后,只統計活的對象數量
-permstat 打印classload和jvm heap長久層的信息. 包含每個classloader的名字,活潑性,地址,父classloader和加載的class數量. 另外,內部String的數量和占用內存數也會打印出來
-F 強迫.在pid沒有相應的時候使用-dump或者-histo參數. 在這個模式下,live子參數無效
-h | -help 打印輔助信息
-J 傳遞參數給jmap啟動的jvm
|
5.4）jhat（Java Heap Analysis Tool）
jhat用於對JAVA heap進行離線分析的工具，它可以對不同虛擬機中導出的heap信息文件進行分析
|
1
2
3
4
5
6
7
|
# jmap -dump:format=b,file=dumpFileName pid
jmap -dump:
format
=b,
file
=
/tmp/dump
.dat 21711
jhat -port 9998
/tmp/dump
.dat
# 注意如果Dump文件太大，可能需要加上-J-Xmx512m這種參數指定最大堆內存
# 在瀏覽器中輸入主機地址:9998查看
|
另外，可以使用Eclipse插件MAT(Memory Analyzer Tool)對dump文件進行分析。
5.5）jstat（Java Virtual Machine Statistics Monitoring Tool）
Jstat用於監控基於HotSpot的JVM，對其堆的使用情況進行實時的命令行的統計，使用jstat我們可以對指定的JVM做如下監控：
類的加載及卸載情況
- 查看新生代、老生代及持久代的容量及使用情況
- 查看新生代、老生代及持久代的垃圾收集情況，包括垃圾回收的次數及垃圾回收所占用的時間
- 查看新生代中Eden區及Survior區中容量及分配情況等
語法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]
generalOption - 單個的常用的命令行選項，如-help, -options, 或 -version。
outputOptions -一個或多個輸出選項，由單個的statOption選項組成，可以和-t, -h, and -J等選項配合使用。
statOption 根據jstat統計的維度不同，可以使用如下表中的選項進行不同維度的統計，不同的操作系統支持的選項可能會不一樣，可以通過-options選項，查看不同操作系統所支持選項
-h n 用於指定每隔幾行就輸出列頭，如果不指定，默認是只在第一行出現列頭。
-J javaOption 用於將給定的javaOption傳給java應用程序加載器，例如，“-J-Xms48m”將把啟動內存設置為48M
-t n 用於在輸出內容的第一列顯示時間戳，這個時間戳代表的時JVM開始啟動到現在的時間
vmid VM的進程號，即當前運行的java進程號
interval 間隔時間，單位可以是秒或者毫秒，通過指定s或ms確定，默認單位為毫秒
count 打印次數，如果缺省則打印無數次
|
===統計維度與輸出===
1）class 用於查看類加載情況的統計
2）compiler 用於查看HotSpot中即時編譯器編譯情況的統計
3）gc 用於查看JVM中堆的垃圾收集情況的統計
4）gccapacity 用於查看新生代、老生代及持久代的存儲容量情況
5）gccause 用於查看垃圾收集的統計情況（這個和-gcutil選項一樣），如果有發生垃圾收集，它還會顯示最后一次及當前正在發生垃圾收集的原因。
6）gcnew 用於查看新生代垃圾收集的情況
7）gcnewcapacity 用於查看新生代的存儲容量情況
8）gcold 用於查看老生代及持久代發生GC的情況
9）gcoldcapacity 用於查看老生代的容量
10）gcpermcapacity 用於查看持久代的容量
11）gcutil 用於查看新生代、老生代及持代垃圾收集的情況
12）printcompilation HotSpot編譯方法的統計
示例
|
1
|
jstat -gc 1618 250 4
|
5.6）jvisualvm（Java Virtual Machine Monitoring, Troubleshooting, and Profiling Tool）
jvisualvm同jconsole都是一個基於圖形化界面的、可以查看本地及遠程的JAVA GUI監控工具，Jvisualvm同jconsole的使用方式一樣，直接在命令行打入Jvisualvm即可啟動，不過Jvisualvm相比，界面更美觀一些，數據更實時。
5.7）jconsole
一個java GUI監視工具，可以以圖表化的形式顯示各種數據。並可通過遠程連接監視遠程的服務器VM。用java寫的GUI程序，用來監控VM，並可監控遠程的VM，非常易用，而且功能非常強。命令行里打 jconsole，選則進程就可以了。
需要注意：在運行jconsole之前，必須要先設置環境變量DISPLAY，否則會報錯誤，Linux下設置環境變量如下：
export DISPLAY=:0.0
5.8）jprofile
JProfiler是一個需要商業授權的全功能的Java剖析工具（profiler），專用於分析J2SE和J2EE應用程序。
它把CPU、執行緒和內存的剖析組合在一個強大的應用中。JProfiler可提供許多IDE整合和應用服務器整合用途。JProfiler直覺式的GUI讓你可以找到效能瓶頸、抓出內存漏失(memory leaks)、並解決執行緒的問題。它讓你得以對heap walker作資源回收器的root analysis，可以輕易找出內存漏失；heap快照（snapshot）模式讓未被參照（reference）的對象、稍微被參照的對象、或在終結（finalization）隊列的對象都會被移除；整合精靈以便剖析瀏覽器的Java外掛功能。
5.9）jca
Java線程分析工具，專業的線程分析工具兼容sun/oracle JDK dump線程堆，圖形化顯示線程概括信息，非常容易的定位問題。
jca是一個類工具 啟動方法
|
1
|
java -jar jca433.jar
|
5.10）jinfo命令 (Java Configuration Info)
jinfo可以輸出並修改運行時的java 進程的opts。用處比較簡單，用於輸出JAVA系統參數及命令行參數。用法是jinfo -opt pid 如：查看2788的MaxPerm大小可以用 jinfo -flag MaxPermSize 2788。
5.11）Jdb命令 (The Java Debugger)
用來對core文件和正在運行的Java進程進行實時地調試，里面包含了豐富的命令幫助您進行調試。
5.12）Jstatd命令 (Java Statistics Monitoring Daemon)
jstatd是一個基於RMI（Remove Method Invocation）的服務程序，它用於監控基於HotSpot的JVM中資源的創建及銷毀，並且提供了一個遠程接口允許遠程的監控工具連接到本地的JVM執行命令。
jstatd是基於RMI的，所以在運行jstatd的服務器上必須存在RMI注冊中心，如果沒有通過選項”-p port”指定要連接的端口，jstatd會嘗試連接RMI注冊中心的默認端口。后面會談到如何連接到一個默認的RMI內部注冊中心，如何禁止默認的RMI內部注冊中心的創建，以及如何啟動一個外部注冊中心。
參數選項
|
1
2
3
4
|
-nr 如果RMI注冊中心沒有找到，不會創建一個內部的RMI注冊中心。
-p port RMI注冊中心的端口號，默認為1099。
-n rminame 默認為JStatRemoteHost；如果同一台主機上同時運行了多個jstatd服務，rminame可以用於唯一確定一個jstatd服務；這里需要注意一下，如果開啟了這個選項，那么監控客戶端遠程連接時，必須同時指定hostid及vmid，才可以唯一確定要連接的服務，這個可以參看jps章節中列出遠程服務器上Java進程的示例。
-J 用於傳遞jvm選項到由javac調用的java加載器中，例如，“-J-Xms48m”將把啟動內存設置為48M，使用-J選項可以非常方便的向基於Java的開發的底層虛擬機應用程序傳遞參數。
|
安全性
jstatd服務只能監視具有適當的本地訪問權限的JVM，因此jstatd進程與被監控的JVM必須運行在相同的用戶權限中。但是有一些特殊的用戶權限，如基於UNIX（TM）為系統的root用戶，它有權限訪問系統中所有JVM的資源，如果jstatd進程運行在這種權限中，那么它可以監視系統中的所有JVM，但是這也帶來了額外的安全問題。
示例
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# 使用內部RMI注冊中心（默認端口是1099），啟動jstatd
jstatd -J-Djava.security.policy=jstatd.all.policy
# 使用外部的RMI注冊中心，啟動jstatd
rmiregistry&jstatd -J-Djava.security.policy=all.policy
# 外部的RMI注冊中心來啟動jstatd，此注冊中心的端口為2020
rmiregistry 2020&jstatd -J-Djava.security.policy=all.policy -p 2020
# 外部的RMI注冊中心來啟動jstatd，此注冊中心的端口為2020，並且綁定到RMI注冊中心的名為AlternateJstatdServerName
rmiregistry 2020&jstatd -J-Djava.security.policy=all.policy -p 2020 -n AlternateJstatdServerName
# 禁止內部RMI注冊中心的創建
jstatd -J-Djava.security.policy=all.policy -nr
# 開啟RMI日記記錄，jstatd運行在開啟了日志記錄功能的RMI注冊中
jstatd -J-Djava.security.policy=all.policy -J-Djava.rmi.server.logCalls=
true
|
5.13）httpwatch
網頁數據分析工具，對客戶端到服務器端的請求，響應數據有效的監控分析。
6. 生產環境示例
6.1）Tomcat7
catalina.sh（只運行一個Tomcat）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
# 8G內存
JAVA_OPTS="
-Dfile.encoding=UTF-8
-server
-Djava.awt.headless=
true
-Xms6144m
-Xmx6144m
-XX:NewSize=1024m
-XX:MaxNewSize=2048m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:MaxTenuringThreshold=15
-XX:NewRatio=2
-XX:+AggressiveOpts
-XX:+UseBiasedLocking
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled
-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+DisableExplicitGC"
# 16G內存（垃圾回收略）
JAVA_OPTS="
-Dfile.encoding=UTF-8
-server
-Xms13312m
-Xmx13312m
-XX:NewSize=3072m
-XX:MaxNewSize=4096m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:MaxTenuringThreshold=10
-XX:NewRatio=2
-XX:+DisableExplicitGC"
# 32G內存（垃圾回收略）
JAVA_OPTS="
-Dfile.encoding=UTF-8
-server
-Xms29696m
-Xmx29696m
-XX:NewSize=6144m
-XX:MaxNewSize=9216m
-XX:PermSize=1024m
-XX:MaxPermSize=1024m
-XX:MaxTenuringThreshold=10
-XX:NewRatio=2
-XX:+DisableExplicitGC"
|
6.2）Hadoop
建議Hadoop進程的GC參數加上如下選項，很多商業版都默認加上了，這對JDK性能提升有很大幫助
|
1
2
3
4
5
6
|
-XX:CMSInitiatingOccupancyFraction=70
-XX:+HeapDumpOnOutOfMemoryError
-XX:+UseConcMarkSweepGC
-XX:-CMSConcurrentMTEnabled
-XX:+CMSIncrementalMode
-Djava.net.preferIPv4Stack=
true
|
7. 參考
JDK8中JVM堆內存划分
JDK8引進的JVM參數變化記錄
JVM 不穩定參數
java 8 JVM性能優化
Java性能優化攻略詳解
Jvm垃圾回收器詳細
JVM性能調優監控工具jps、jstack、jmap、jhat、jstat、hprof使用詳解
jps命令 (Java Virtual Machine Process Status Tool)
Could not create the Java virtual machine
|
1
2
3
4
|
一般原因如下：
1）執行程序里的JAVA路徑不對造成的！通過
"echo $JAVA_HOME"
查找出JAVA路徑，然后更新程序中的JAVA路徑配置即可。
2）JVM參數不對造成（可能是stack size太小）。修改JVM_OPTIONS配置里的JVM參數值即可。
3）jdk版本不兼容導致。調整jdk版本（比如jdk版本過低，調整為高版本的jdk）即可。
|