java性能分析命令_如何優化java虛擬機提高性能

⑴ 如何利用 JConsole觀察分析java程序的運行，進行排錯調優

⑵ JDK命令介紹

命令jps用於列出java進程，直接運行jps不加任何參數，可以列出Java程序的進程ID以及Main函數等名稱。
參數-q指定jps只輸出進程ID，而不輸出類的短名稱
參數-m用於輸出傳遞給Java進程（主函數）的參數
參數 -l用於輸出主函數的完整路徑
參數 -v可以顯示傳遞給JVM的參數

jstat是一個可以用於觀察Java應用程序運行時信息的工具。它的功能非常強大，可以通過它，查看堆信息的詳細使用情況。主要用於監控虛擬機的各種運行狀態信息，如類的裝載、內存、垃圾回收、JIT編譯器等，在沒有GUI的伺服器上，這款工具是首選的一款監控工具。
基本使用語法為：

選項option可以由以下值構成：

-class：顯示ClassLoader的相關信息。
-compiler：顯示JIT編譯的相關信息。
-gc：顯示與GC相關的堆信息。
-gccapacity：顯示各個代的容量及使用情況。
-gccause：顯示垃圾收集相關信息（同-gcutil），同時顯示最後一次或當前正在發生的垃圾收集的誘發原因。
-gcnew：顯示新生代信息。
-gcnewcapacity：顯示新生代大小與使用情況。
-gcold：顯示老年代與永久代的信息。
-gcoldcapacity：顯示老年代的大小。
-gcmetacapacity：顯示元空間的大小。（在java8之前是使用-gcpermcapacity顯示永久代的大小）
-gcutil：顯示垃圾收集信息。
-printcompilation：輸出JIT編譯的方法信息。
以上選項可以輸入 jstat -options 查看。

-t 參數可以在輸出信息前加一個 Timestamp 列，顯示程序的運行時間。

-h 參數可以在周期性數據輸出時，輸出多少行數據後，跟著輸出一個表頭信息。

vmid 參數就是Java進程id。

interval 參數用於指定輸出統計數據的周期，單位為毫秒。

count 用於指定一共輸出多少次數據。

jinfo 可以用來查看正在運行的Java運行程序的擴展參數，甚至支持在運行時修改部分參數。可以用來查看正在運行的 java 應用程序的擴展參數，包括Java System屬性和JVM命令行參數；也可以動態的修改正在運行的 JVM 一些參數。當系統崩潰時，jinfo可以從core文件裡面知道崩潰的Java應用程序的配置信息。

jmap 可以生成Java應用程序的堆快照和對象的統計信息。基本語法為：

option 選項如下：
-mp 生成java堆轉儲快照。格式為： -mp:[live,]format=b,file=,其中live子參數說明是否只mp出存活的對象
-finalizerinfo 顯示在F-Queue中等待Finalizer線程執行finalize方法的對象。只在Linux/Solaris平台下有效
-heap 顯示java堆詳細信息，如使用哪種收集器、參數配置、分代情況等，在Linux/Solaris平台下有效
-histo 顯示堆中對象統計信息，包含類、實例對象、合集容量
-permstat 以ClassLoader為統計口徑顯示永久代內存狀態。只在Linux/Solaris平台下有效
-F 當虛擬機進程對-mp選項沒有相應時。可使用這個選項強制生成mp快照。只在Linux/Solaris平台下有效

使用 jhat 工具可以用於分析Java應用程序的堆快照內容。jhat 在分析完成後，使用HTTP伺服器展示其分析結果。在瀏覽器中訪問 http://localhost:7000/

jstack 可用於導出Java應用程序的線程堆棧。語法為：

-l選項用於列印鎖的附加信息。
jstack 工具會在控制台輸出程序中所有的鎖信息，可以使用重定向將輸出保存到文件。
通過 jstack 工具不僅可以得到線程堆棧，它還能自動進行死鎖檢查，輸出找到的死鎖信息。

之前所述的工具中，只涉及到監控本機的Java應用程序。而在這些工具中，一些監控工具也支持對遠程計算機的監控（如：jps、jstat）。為了啟用遠程監控，則需要配合使用jstatd工具。
命令jstatd是一個RMI服務端程序，它的作用相當於代理伺服器，建立本地計算機與遠程監控工具的通信。jstatd伺服器將本機的Java應用程序信息傳遞到遠程計算機。

JConsole（Java Monitoring and ManagementConsole）工具時JDK自帶的圖形化性能監控工具。通過JConsole工具，可以查看Java應用程序的運行概況，監控堆信息、永久區使用情況、類載入情況等。

⑶ jvm 性能調優工具之 jstat 命令詳解

Jstat名稱：Java Virtual Machine statistics monitoring tool

功能描述：

Jstat是JDK自帶的一個輕量級小工具。它位於java的bin目錄下，主要利用JVM內建的指令對Java應用程序的資源和性能進行實時的命令行的監控，包括了對Heap size和垃圾回收狀況的監控。

命令用法：jstat [-命令選項] [vmid] [間隔時間/毫秒] [查詢次數]
注意：使用的jdk版本是jdk8。

C:\Users\Administrator>jstat -helpUsage: jstat -help|-options jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]] Definitions: <option> An option reported by the -options option <vmid> Virtual Machine Identifier. A vmid takes the following form: <lvmid>[@<hostname>[:<port>]] Where <lvmid> is the local vm identifier for the target Java virtual machine, typically a process id; <hostname> is the name of the host running the target Java virtual machine; and <port> is the port number for the rmiregistry on the target host. See the jvmstat documentation for a more complete description of the Virtual Machine Identifier. <lines> Number of samples between header lines. <interval> Sampling interval. The following forms are allowed: <n>["ms"|"s"] Where <n> is an integer and the suffix specifies the units as milliseconds("ms") or seconds("s"). The default units are "ms". <count> Number of samples to take before terminating. -J<flag> Pass <flag> directly to the runtime system.
option：參數選項
-t：可以在列印的列加上Timestamp列，用於顯示系統運行的時間
-h：可以在周期性數據輸出的時候，指定輸出多少行以後輸出一次表頭
vmid：Virtual Machine ID（進程的 pid）
interval：執行每次的間隔時間，單位為毫秒
count：用於指定輸出多少次記錄，預設則會一直列印
option 可以從下面參數中選擇

jstat -options

-class 用於查看類載入情況的統計
-compiler 用於查看HotSpot中即時編譯器編譯情況的統計
-gc 用於查看JVM中堆的垃圾收集情況的統計
-gccapacity 用於查看新生代、老生代及持久代的存儲容量情況
-gcmetacapacity 顯示metaspace的大小
-gcnew 用於查看新生代垃圾收集的情況
-gcnewcapacity 用於查看新生代存儲容量的情況
-gcold 用於查看老生代及持久代垃圾收集的情況
-gcoldcapacity 用於查看老生代的容量
-gcutil 顯示垃圾收集信息
-gccause 顯示垃圾回收的相關信息（通-gcutil）,同時顯示最後一次僅當前正在發生的垃圾收集的原因
-printcompilation 輸出JIT編譯的方法信息
示例：

1.-class 類載入統計

[root@hadoop ~]# jps #先通過jps獲取到java進程號（這里是一個zookeeper進程）3346 QuorumPeerMain7063 Jps[root@hadoop ~]# jstat -class 3346 #統計JVM中載入的類的數量與sizeLoaded Bytes Unloaded Bytes Time 1527 2842.7 0 0.0 1.02
Loaded:載入類的數量
Bytes：載入類的size，單位為Byte
Unloaded：卸載類的數目
Bytes：卸載類的size，單位為Byte
Time：載入與卸載類花費的時間
2.-compiler 編譯統計

[root@hadoop ~]# jstat -compiler 3346 #用於查看HotSpot中即時編譯器編譯情況的統計Compiled Failed Invalid Time FailedType FailedMethod 404 0 0 0.19 0
Compiled：編譯任務執行數量
Failed：編譯任務執行失敗數量
Invalid：編譯任務執行失效數量
Time：編譯任務消耗時間
FailedType：最後一個編譯失敗任務的類型
FailedMethod：最後一個編譯失敗任務所在的類及方法
3.-gc 垃圾回收統計

[root@hadoop ~]# jstat -gc 3346 #用於查看JVM中堆的垃圾收集情況的統計 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 128.0 128.0 0.0 128.0 1024.0 919.8 15104.0 2042.4 8448.0 8130.4 1024.0 996.0 7 0.019 0 0.000 0.019
S0C：年輕代中第一個survivor（倖存區）的容量（位元組）
S1C：年輕代中第二個survivor（倖存區）的容量 (位元組)
S0U：年輕代中第一個survivor（倖存區）目前已使用空間 (位元組)
S1U：年輕代中第二個survivor（倖存區）目前已使用空間 (位元組)
EC：年輕代中Eden（伊甸園）的容量 (位元組)
EU：年輕代中Eden（伊甸園）目前已使用空間 (位元組)
OC：Old代的容量 (位元組)
OU：Old代目前已使用空間 (位元組)
MC：metaspace(元空間)的容量 (位元組)
MU：metaspace(元空間)目前已使用空間 (位元組)
CCSC：當前壓縮類空間的容量 (位元組)
CCSU：當前壓縮類空間目前已使用空間 (位元組)
YGC：從應用程序啟動到采樣時年輕代中gc次數
YGCT：從應用程序啟動到采樣時年輕代中gc所用時間(s)
FGC：從應用程序啟動到采樣時old代(全gc)gc次數
FGCT：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT：從應用程序啟動到采樣時gc用的總時間(s)
4.-gccapacity 堆內存統計

[root@hadoop ~]# jstat -gccapacity 3346 #用於查看新生代、老生代及持久代的存儲容量情況 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0[root@hadoop ~]# jstat -gccapacity -h5 3346 1000 #-h5：每5行顯示一次表頭 1000：每1秒鍾顯示一次，單位為毫秒 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0 1280.0 83264.0 1280.0 128.0 128.0 1024.0 15104.0 166592.0 15104.0 15104.0 0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 7 0
NGCMN：年輕代(young)中初始化(最小)的大小(位元組)
NGCMX：年輕代(young)的最大容量 (位元組)
NGC：年輕代(young)中當前的容量 (位元組)
S0C：年輕代中第一個survivor（倖存區）的容量 (位元組)
S1C：年輕代中第二個survivor（倖存區）的容量 (位元組)
EC：年輕代中Eden（伊甸園）的容量 (位元組)
OGCMN：old代中初始化(最小)的大小 (位元組)
OGCMX：old代的最大容量(位元組)
OGC：old代當前新生成的容量 (位元組)
OC：Old代的容量 (位元組)
MCMN：metaspace(元空間)中初始化(最小)的大小 (位元組)
MCMX：metaspace(元空間)的最大容量 (位元組)
MC：metaspace(元空間)當前新生成的容量 (位元組)
CCSMN：最小壓縮類空間大小
CCSMX：最大壓縮類空間大小
CCSC：當前壓縮類空間大小
YGC：從應用程序啟動到采樣時年輕代中gc次數
FGC：從應用程序啟動到采樣時old代(全gc)gc次數
5.-gcmetacapacity 元數據空間統計

[root@hadoop ~]# jstat -gcmetacapacity 3346 #顯示元數據空間的大小MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC FGCT GCT0.0 1056768.0 8448.0 0.0 1048576.0 1024.0 8 0 0.000 0.020
MCMN：最小元數據容量
MCMX：最大元數據容量
MC：當前元數據空間大小
CCSMN：最小壓縮類空間大小
CCSMX：最大壓縮類空間大小
CCSC：當前壓縮類空間大小
YGC：從應用程序啟動到采樣時年輕代中gc次數
FGC：從應用程序啟動到采樣時old代(全gc)gc次數
FGCT：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT：從應用程序啟動到采樣時gc用的總時間(s)
6.-gcnew 新生代垃圾回收統計

[root@hadoop ~]# jstat -gcnew 3346 #用於查看新生代垃圾收集的情況S0C S1C S0U S1U TT MTT DSS EC EU YGC YGCT128.0 128.0 67.8 0.0 1 15 64.0 1024.0 362.2 8 0.020
S0C：年輕代中第一個survivor（倖存區）的容量 (位元組)
S1C：年輕代中第二個survivor（倖存區）的容量 (位元組)
S0U：年輕代中第一個survivor（倖存區）目前已使用空間 (位元組)
S1U：年輕代中第二個survivor（倖存區）目前已使用空間 (位元組)
TT：持有次數限制
MTT：最大持有次數限制
DSS：期望的倖存區大小
EC：年輕代中Eden（伊甸園）的容量 (位元組)
EU：年輕代中Eden（伊甸園）目前已使用空間 (位元組)
YGC：從應用程序啟動到采樣時年輕代中gc次數
YGCT：從應用程序啟動到采樣時年輕代中gc所用時間(s)
7.-gcnewcapacity 新生代內存統計

[root@hadoop ~]# jstat -gcnewcapacity 3346 #用於查看新生代存儲容量的情況NGCMN NGCMX NGC S0CMX S0C S1CMX S1C ECMX EC YGC FGC1280.0 83264.0 1280.0 8320.0 128.0 8320.0 128.0 66624.0 1024.0 8 0
NGCMN：年輕代(young)中初始化(最小)的大小(位元組)
NGCMX：年輕代(young)的最大容量 (位元組)
NGC：年輕代(young)中當前的容量 (位元組)
S0CMX：年輕代中第一個survivor（倖存區）的最大容量 (位元組)
S0C：年輕代中第一個survivor（倖存區）的容量 (位元組)
S1CMX：年輕代中第二個survivor（倖存區）的最大容量 (位元組)
S1C：年輕代中第二個survivor（倖存區）的容量 (位元組)
ECMX：年輕代中Eden（伊甸園）的最大容量 (位元組)
EC：年輕代中Eden（伊甸園）的容量 (位元組)
YGC：從應用程序啟動到采樣時年輕代中gc次數
FGC：從應用程序啟動到采樣時old代(全gc)gc次數
8.-gcold 老年代垃圾回收統計

[root@hadoop ~]# jstat -gcold 3346 #用於查看老年代及持久代垃圾收集的情況MC MU CCSC CCSU OC OU YGC FGC FGCT GCT8448.0 8227.5 1024.0 1003.7 15104.0 2102.2 8 0 0.000 0.020
MC：metaspace(元空間)的容量 (位元組)
MU：metaspace(元空間)目前已使用空間 (位元組)
CCSC：壓縮類空間大小
CCSU：壓縮類空間使用大小
OC：Old代的容量 (位元組)
OU：Old代目前已使用空間 (位元組)
YGC：從應用程序啟動到采樣時年輕代中gc次數
FGC：從應用程序啟動到采樣時old代(全gc)gc次數
FGCT：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT：從應用程序啟動到采樣時gc用的總時間(s)
9.-gcoldcapacity 老年代內存統計

[root@hadoop ~]# jstat -gcoldcapacity 3346 #用於查看老年代的容量OGCMN OGCMX OGC OC YGC FGC FGCT GCT15104.0 166592.0 15104.0 15104.0 8 0 0.000 0.020
OGCMN：old代中初始化(最小)的大小 (位元組)OGCMX：old代的最大容量(位元組)OGC：old代當前新生成的容量 (位元組)OC：Old代的容量 (位元組)YGC：從應用程序啟動到采樣時年輕代中gc次數FGC：從應用程序啟動到采樣時old代(全gc)gc次數FGCT：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)GCT：從應用程序啟動到采樣時gc用的總時間(s) 在此我向大家推薦一個架構學習交流圈。交流學習指導偽鑫：1253431195（裡面有大量的面試題及答案）裡面會分享一些資深架構師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高並發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多
10.-gcutil 垃圾回收統計

[root@hadoop ~]# jstat -gcutil 3346 #顯示垃圾收集信息S0 S1 E O M CCS YGC YGCT FGC FGCT GCT52.97 0.00 42.10 13.92 97.39 98.02 8 0.020 0 0.000 0.020
S0：年輕代中第一個survivor（倖存區）已使用的占當前容量百分比
S1：年輕代中第二個survivor（倖存區）已使用的占當前容量百分比
E：年輕代中Eden（伊甸園）已使用的占當前容量百分比
O：old代已使用的占當前容量百分比
M：元數據區已使用的占當前容量百分比
CCS：壓縮類空間已使用的占當前容量百分比
YGC ：從應用程序啟動到采樣時年輕代中gc次數
YGCT ：從應用程序啟動到采樣時年輕代中gc所用時間(s)
FGC ：從應用程序啟動到采樣時old代(全gc)gc次數
FGCT ：從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT：從應用程序啟動到采樣時gc用的總時間(s)
11.-gccause

[root@hadoop ~]# jstat -gccause 3346 #顯示垃圾回收的相關信息（通-gcutil）,同時顯示最後一次或當前正在發生的垃圾回收的誘因S0 S1 E O M CCS YGC YGCT FGC FGCT GCT LGCC GCC52.97 0.00 46.09 13.92 97.39 98.02 8 0.020 0 0.000 0.020 Allocation Failure No GC
LGCC：最後一次GC原因
GCC：當前GC原因（No GC 為當前沒有執行GC）
12.-printcompilation JVM編譯方法統計

[root@hadoop ~]# jstat -printcompilation 3346 #輸出JIT編譯的方法信息Compiled Size Type Method421 60 1 sun/nio/ch/Util$2 clear
Compiled：編譯任務的數目
Size：方法生成的位元組碼的大小
Type：編譯類型
Method：類名和方法名用來標識編譯的方法。類名使用/做為一個命名空間分隔符。方法名是給定類中的方法。上述格式是由-XX:+PrintComplation選項進行設置的
遠程監控

與jps一樣，jstat也支持遠程監控，同樣也需要開啟安全授權，方法參照jps。

C:\Users\Administrator>jps 192.168.146.1283346 QuorumPeerMain3475 JstatdC:\Users\Administrator>jstat -gcutil [email protected] S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 52.97 0.00 65.15 13.92 97.39 98.02 8 0.020 0 0.000 0.020

⑷ 如何優化JAVA程序開發，提高JAVA性能

可供程序利用的資源（內存、CPU時間、網路帶寬等）是有限的，優化的目的就是讓程序用盡可能少的資源完成預定的任務。優化通常包含兩方面的內容：減小代碼的體積，提高代碼的運行效率。本文討論的主要是如何提高代碼的效率。
在Java程序中，性能問題的大部分原因並不在於Java語言，而是在於程序本身。養成好的代碼編寫習慣非常重要，比如正確地、巧妙地運用java.lang.String類和java.util.Vector類，它能夠顯著地提高程序的性能。下面我們就來具體地分析一下這方面的問題。

1、盡量指定類的final修飾符帶有final修飾符的類是不可派生的。在Java核心API中，有許多應用final的例子，例如java.lang.String。為String類指定final防止了人們覆蓋length()方法。另外，如果指定一個類為final，則該類所有的方法都是final。Java編譯器會尋找機會內聯（inline）所有的final方法（這和具體的編譯器實現有關）。此舉能夠使性能平均提高50%
。

2、盡量重用對象。特別是String 對象的使用中，出現字元串連接情況時應用StringBuffer 代替。由於系統不僅要花時間生成對象，以後可能還需花時間對這些對象進行垃圾回收和處理。因此，生成過多的對象將會給程序的性能帶來很大的影響。

3、盡量使用局部變數，調用方法時傳遞的參數以及在調用中創建的臨時變數都保存在棧（Stack）中，速度較快。其他變數，如靜態變數、實例變數等，都在堆（Heap）中創建，速度較慢。另外，依賴於具體的編譯器/JVM，局部變數還可能得到進一步優化。請參見《盡可能使用堆棧變數》。

4、不要重復初始化變數默認情況下，調用類的構造函數時，
Java會把變數初始化成確定的值：所有的對象被設置成null，整數變數（byte、short、int、long）設置成0，float和double變數設置成0.0，邏輯值設置成false。當一個類從另一個類派生時，這一點尤其應該注意，因為用new關鍵詞創建一個對象時，構造函數鏈中的所有構造函數都會被自動調用。

5、在JAVA + ORACLE 的應用系統開發中，java中內嵌的SQL語句盡量使用大寫的形式，以減輕ORACLE解析器的解析負擔。

6、 Java 編程過程中，進行資料庫連接、I/O流操作時務必小心，在使用完畢後，即使關閉以釋放資源。因為對這些大對象的操作會造成系統大的開銷，稍有不慎，會導致嚴重的後果。

7、由於JVM的有其自身的GC機制，不需要程序開發者的過多考慮，從一定程度上減輕了開發者負擔，但同時也遺漏了隱患，過分的創建對象會消耗系統的大量內存，嚴重時會導致內存泄露，因此，保證過期對象的及時回收具有重要意義。JVM回收垃圾的條件是：對象不在被引用；然而，JVM的GC並非十分的機智，即使對象滿足了垃圾回收的條件也不一定會被立即回收。所以，建議我們在對象使用完畢，應手動置成null。

8、在使用同步機制時，應盡量使用方法同步代替代碼塊同步。

9、盡量減少對變數的重復計算
例如：for(int i = 0;i < list.size; i ++) {
…
}
應替換為：
for(int i = 0,int len = list.size();i < len; i ++) {
…
}

10、盡量採用lazy loading 的策略，即在需要的時候才開始創建。
例如： String str = 「aaa」;
if(i == 1) {
list.add(str);
}
應替換為：
if(i == 1) {
String str = 「aaa」;
list.add(str);
}
11、慎用異常
異常對性能不利。拋出異常首先要創建一個新的對象。Throwable介面的構造函數調用名為fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法檢查堆棧，收集調用跟蹤信息。只要有異常被拋出，VM就必須調整調用堆棧，因為在處理過程中創建了一個新的對象。異常只能用於錯誤處理，不應該用來控製程序流程。

12、不要在循環中使用：
Try {
} catch() {
}
應把其放置在最外層。

13、StringBuffer 的使用：
StringBuffer表示了可變的、可寫的字元串。
有三個構造方法 :
StringBuffer (); //默認分配16個字元的空間
StringBuffer (int size); //分配size個字元的空間
StringBuffer (String str); //分配16個字元+str.length()個字元空間
你可以通過StringBuffer的構造函數來設定它的初始化容量，這樣可以明顯地提升性能。這里提到的構造函數是StringBuffer(int
length)，length參數表示當前的StringBuffer能保持的字元數量。你也可以使用ensureCapacity(int
minimumcapacity)方法在StringBuffer對象創建之後設置它的容量。首先我們看看StringBuffer的預設行為，然後再找出一條更好的提升性能的途徑。
StringBuffer在內部維護一個字元數組，當你使用預設的構造函數來創建StringBuffer對象的時候，因為沒有設置初始化字元長度，StringBuffer的容量被初始化為16個字元，也就是說預設容量就是16個字元。當StringBuffer達到最大容量的時候，它會將自身容量增加到當前的2倍再加2，也就是（2*舊值+2）。如果你使用預設值，初始化之後接著往裡面追加字元，在你追加到第16個字元的時候它會將容量增加到34（2*16+2），當追加到34個字元的時候就會將容量增加到70（2*34+2）。無論何事只要StringBuffer到達它的最大容量它就不得不創建一個新的字元數組然後重新將舊字元和新字元都拷貝一遍――這也太昂貴了點。所以總是給StringBuffer設置一個合理的初始化容量值是錯不了的，這樣會帶來立竿見影的性能增益。
StringBuffer初始化過程的調整的作用由此可見一斑。所以，使用一個合適的容量值來初始化StringBuffer永遠都是一個最佳的建議。

14、合理的使用Java類 java.util.Vector。
簡單地說，一個Vector就是一個java.lang.Object實例的數組。Vector與數組相似，它的元素可以通過整數形式的索引訪問。但是，Vector類型的對象在創建之後，對象的大小能夠根據元素的增加或者刪除而擴展、縮小。請考慮下面這個向Vector加入元素的例子：
Object obj = new Object();
Vector v = new Vector(100000);
for(int I=0;
I<100000; I++) { v.add(0,obj); }

除非有絕對充足的理由要求每次都把新元素插入到Vector的前面，否則上面的代碼對性能不利。在默認構造函數中，Vector的初始存儲能力是10個元素，如果新元素加入時存儲能力不足，則以後存儲能力每次加倍。Vector類就象StringBuffer類一樣，每次擴展存儲能力時，所有現有的元素都要復制到新的存儲空間之中。下面的代碼片段要比前面的例子快幾個數量級：
Object obj = new Object();
Vector v = new Vector(100000);
for(int I=0; I<100000; I++) { v.add(obj); }

同樣的規則也適用於Vector類的remove()方法。由於Vector中各個元素之間不能含有「空隙」，刪除除最後一個元素之外的任意其他元素都導致被刪除元素之後的元素向前移動。也就是說，從Vector刪除最後一個元素要比刪除第一個元素「開銷」低好幾倍。

假設要從前面的Vector刪除所有元素，我們可以使用這種代碼：
for(int I=0; I<100000; I++)
{
v.remove(0);
}

但是，與下面的代碼相比，前面的代碼要慢幾個數量級：
for(int I=0; I<100000; I++)
{
v.remove(v.size()-1);
}

從Vector類型的對象v刪除所有元素的最好方法是：
v.removeAllElements();

假設Vector類型的對象v包含字元串「Hello」。考慮下面的代碼，它要從這個Vector中刪除「Hello」字元串：
String s = "Hello";
int i = v.indexOf(s);
if(I != -1) v.remove(s);

這些代碼看起來沒什麼錯誤，但它同樣對性能不利。在這段代碼中，indexOf()方法對v進行順序搜索尋找字元串「Hello」，remove(s)方法也要進行同樣的順序搜索。改進之後的版本是：
String s = "Hello";
int i = v.indexOf(s);
if(I != -1) v.remove(i);

這個版本中我們直接在remove()方法中給出待刪除元素的精確索引位置，從而避免了第二次搜索。一個更好的版本是：
String s = "Hello"; v.remove(s);

最後，我們再來看一個有關Vector類的代碼片段：
for(int I=0; I++;I < v.length)

如果v包含100,000個元素，這個代碼片段將調用v.size()方法100,000次。雖然size方法是一個簡單的方法，但它仍舊需要一次方法調用的開銷，至少JVM需要為它配置以及清除堆棧環境。在這里，for循環內部的代碼不會以任何方式修改Vector類型對象v的大小，因此上面的代碼最好改寫成下面這種形式：
int size = v.size(); for(int I=0; I++;I<size)

雖然這是一個簡單的改動，但它仍舊贏得了性能。畢竟，每一個CPU周期都是寶貴的。

15、當復制大量數據時，使用System.array()命令。

16、代碼重構：增強代碼的可讀性。
例如：
public class ShopCart {
private List carts ;
…
public void add (Object item) {
if(carts == null) {
carts = new ArrayList();
}
crts.add(item);
}
public void remove(Object item) {
if(carts. contains(item)) {
carts.remove(item);
}
}
public List getCarts() {
//返回只讀列表
return Collections.unmodifiableList(carts);
}

//不推薦這種方式
//this.getCarts().add(item);
}

17、不用new關鍵詞創建類的實例
用new關鍵詞創建類的實例時，構造函數鏈中的所有構造函數都會被自動調用。但如果一個對象實現了Cloneable介面，我們可以調用它的clone()方法。clone()方法不會調用任何類構造函數。
在使用設計模式（Design Pattern）的場合，如果用Factory模式創建對象，則改用clone()方法創建新的對象實例非常簡單。例如，下面是Factory模式的一個典型實現：
public static Credit getNewCredit() {
return new Credit();
}
改進後的代碼使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路對於數組處理同樣很有用。

18、乘法和除法
考慮下面的代碼：
for (val = 0; val < 100000; val +=5) {
alterX = val * 8; myResult = val * 2;
}
用移位操作替代乘法操作可以極大地提高性能。下面是修改後的代碼：
for (val = 0; val < 100000; val += 5) {
alterX = val << 3; myResult = val << 1;
}
修改後的代碼不再做乘以8的操作，而是改用等價的左移3位操作，每左移1位相當於乘以2。相應地，右移1位操作相當於除以2。值得一提的是，雖然移位操作速度快，但可能使代碼比較難於理解，所以最好加上一些注釋。

19、在JSP頁面中關閉無用的會話。
一個常見的誤解是以為session在有客戶端訪問時就被創建，然而事實是直到某server端程序調用HttpServletRequest.getSession(true)這樣的語句時才被創建，注意如果JSP沒有顯示的使用 <%@pagesession="false"%> 關閉session，則JSP文件在編譯成Servlet時將會自動加上這樣一條語句HttpSession
session = HttpServletRequest.getSession(true);這也是JSP中隱含的session對象的來歷。由於session會消耗內存資源，因此，如果不打算使用session，應該在所有的JSP中關閉它。
對於那些無需跟蹤會話狀態的頁面，關閉自動創建的會話可以節省一些資源。使用如下page指令：<%@ page session="false"%>

20、JDBC與I/O
如果應用程序需要訪問一個規模很大的數據集，則應當考慮使用塊提取方式。默認情況下，JDBC每次提取32行數據。舉例來說，假設我們要遍歷一個5000行的記錄集，JDBC必須調用資料庫157次才能提取到全部數據。如果把塊大小改成512，則調用資料庫的次數將減少到10次。
[p][/p]21、Servlet與內存使用
許多開發者隨意地把大量信息保存到用戶會話之中。一些時候，保存在會話中的對象沒有及時地被垃圾回收機制回收。從性能上看，典型的症狀是用戶感到系統周期性地變慢，卻又不能把原因歸於任何一個具體的組件。如果監視JVM的堆空間，它的表現是內存佔用不正常地大起大落。
解決這類內存問題主要有二種辦法。第一種辦法是，在所有作用范圍為會話的Bean中實現HttpSessionBindingListener介面。這樣，只要實現valueUnbound()方法，就可以顯式地釋放Bean使用的資源。另外一種辦法就是盡快地把會話作廢。大多數應用伺服器都有設置會話作廢間隔時間的選項。另外，也可以用編程的方式調用會話的setMaxInactiveInterval()方法，該方法用來設定在作廢會話之前，Servlet容器允許的客戶請求的最大間隔時間，以秒計。

22、使用緩沖標記
一些應用伺服器加入了面向JSP的緩沖標記功能。例如，BEA的WebLogic Server從6.0版本開始支持這個功能，Open
Symphony工程也同樣支持這個功能。JSP緩沖標記既能夠緩沖頁面片斷，也能夠緩沖整個頁面。當JSP頁面執行時，如果目標片斷已經在緩沖之中，則生成該片斷的代碼就不用再執行。頁面級緩沖捕獲對指定URL的請求，並緩沖整個結果頁面。對於購物籃、目錄以及門戶網站的主頁來說，這個功能極其有用。對於這類應用，頁面級緩沖能夠保存頁面執行的結果，供後繼請求使用。

23、選擇合適的引用機制
在典型的JSP應用系統中，頁頭、頁腳部分往往被抽取出來，然後根據需要引入頁頭、頁腳。當前，在JSP頁面中引入外部資源的方法主要有兩種：include指令，以及include動作。
include指令：例如<%@ include file="right.html"
%>。該指令在編譯時引入指定的資源。在編譯之前，帶有include指令的頁面和指定的資源被合並成一個文件。被引用的外部資源在編譯時就確定，比運行時才確定資源更高效。
include動作：例如<jsp:include page="right.jsp"
/>。該動作引入指定頁面執行後生成的結果。由於它在運行時完成，因此對輸出結果的控制更加靈活。但時，只有當被引用的內容頻繁地改變時，或者在對主頁面的請求沒有出現之前，被引用的頁面無法確定時，使用include動作才合算。

24、及時清除不再需要的會話
為了清除不再活動的會話，許多應用伺服器都有默認的會話超時時間，一般為30分鍾。當應用伺服器需要保存更多會話時，如果內存容量不足，操作系統會把部分內存數據轉移到磁碟，應用伺服器也可能根據「最近最頻繁使用」（Most
Recently
Used）演算法把部分不活躍的會話轉儲到磁碟，甚至可能拋出「內存不足」異常。在大規模系統中，串列化會話的代價是很昂貴的。當會話不再需要時，應當及時調用HttpSession.invalidate()方法清除會話。HttpSession.invalidate()方法通常可以在應用的退出頁面調用。

25、不要將數組聲明為：public static final 。

26、HashMap的遍歷效率討論
經常遇到對HashMap中的key和value值對的遍歷操作，有如下兩種方法：Map<String, String[]> paraMap = new HashMap<String, String[]>();
................//第一個循環
Set<String> appFieldDefIds = paraMap.keySet();
for (String appFieldDefId : appFieldDefIds) {
String[] values = paraMap.get(appFieldDefId);
......
}

//第二個循環
for(Entry<String, String[]> entry : paraMap.entrySet()){
String appFieldDefId = entry.getKey();
String[] values = entry.getValue();
.......
}

第一種實現明顯的效率不如第二種實現。
分析如下 Set<String> appFieldDefIds = paraMap.keySet(); 是先從HashMap中取得keySet

代碼如下：
public Set<K> keySet() {
Set<K> ks = keySet;
return (ks != null ? ks : (keySet = new KeySet()));
}

private class KeySet extends AbstractSet<K> {
public Iterator<K> iterator() {
return newKeyIterator();
}
public int size() {
return size;
}
public boolean contains(Object o) {
return containsKey(o);
}
public boolean remove(Object o) {
return HashMap.this.removeEntryForKey(o) != null;
}
public void clear() {
HashMap.this.clear();
}
}
其實就是返回一個私有類KeySet, 它是從AbstractSet繼承而來，實現了Set介面。

再來看看for/in循環的語法
for(declaration : expression_r)
statement

在執行階段被翻譯成如下各式
for(Iterator<E> #i = (expression_r).iterator(); #i.hashNext();){
declaration = #i.next();
statement
}

因此在第一個for語句for (String appFieldDefId : appFieldDefIds) 中調用了HashMap.keySet().iterator() 而這個方法調用了newKeyIterator()

Iterator<K> newKeyIterator() {
return new KeyIterator();
}
private class KeyIterator extends HashIterator<K> {
public K next() {
return nextEntry().getKey();
}
}

所以在for中還是調用了
在第二個循環for(Entry<String, String[]> entry : paraMap.entrySet())中使用的Iterator是如下的一個內部類

private class EntryIterator extends HashIterator<Map.Entry<K,V>> {
public Map.Entry<K,V> next() {
return nextEntry();
}
}

此時第一個循環得到key，第二個循環得到HashMap的Entry
效率就是從循環裡面體現出來的第二個循環此致可以直接取key和value值
而第一個循環還是得再利用HashMap的get(Object key)來取value值

現在看看HashMap的get(Object key)方法
public V get(Object key) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length); //Entry[] table
Entry<K,V> e = table;
while (true) {
if (e == null)
return null;
if (e.hash == hash && eq(k, e.key))
return e.value;
e = e.next;
}
}
其實就是再次利用Hash值取出相應的Entry做比較得到結果，所以使用第一中循環相當於兩次進入HashMap的Entry中
而第二個循環取得Entry的值之後直接取key和value，效率比第一個循環高。其實按照Map的概念來看也應該是用第二個循環好一點，它本來就是key和value的值對，將key和value分開操作在這里不是個好選擇。

⑸ 如何利用 JConsole觀察分析Java程序的運行，進行排錯調優

⑹ 如何優化java虛擬機，提高性能

關於性能調優：
1 需要一個性能探測器，找到調用最頻繁的代碼段，優化這部分代碼（優化演算法）
2 往往1%的代碼運行時間佔99%。所以優化這些代碼就能事半功倍。
3 最好是能看懂編譯後的代碼，這樣分析最徹底。
Java的性能分析使用JProfiler
堆棧分析使用的Jstack

Java性能調優 SSH框架優化以適應特定的項目
一、JVM調優
1 各種垃圾回收演算法及其優劣；
2 針對不同應用類型如何選擇JVM參數
3 常用調優工具的使用（jps/jstat/jmap/jstack/jinfo/jhat）
4 調優案例分析(如何選擇不同內存塊的大小，如何選擇不同的演算法來提升性能、響應時間)

二、Java應用中CPU佔用率、使用情況分析，線程死鎖等鎖
系統性能瓶頸的分析定位
1 JStack的深度使用
2 各種Linux監控命令的配合使用(top,vmstat,iostat,sar 不要輕信自己能完全掌控這些命令)、分析
(前一陣Java漏洞通過製造Hash沖突來占盡CPU資源就可以通過top命令快速定位到,你肯定沒有這么用過)
3 JProfiler的詳細使用

三、Java內存溢出分析
1 用EMA來分析內存佔用情況

2 通過案例分析來定位內存泄漏

互聯網中的性能主要是兩個方面：
1 吞吐量，就是系統支持的訪問量。
2 延遲，就是一個請求提交後，相應的時間。
一般硬體不變的情況下，兩方面各自優化到極限後，相互會制約，也就是吞吐量增強的話比如需要延遲加大，反之亦然。

⑺ 如何利用JConsole觀察分析JAVA程序的運行

一、JConsole是什麼

從Java 5開始引入了 JConsole。JConsole 是一個內置 Java 性能分析器，可以從命令行或在 GUI
shell 中運行。您可以輕松地使用 JConsole（或者，它更高端的「近親」 VisualVM ）來監控 Java 應用程序性能和跟蹤
Java 中的代碼。

二、如何啟動JConsole

如果是從命令行啟動，使 JDK 在 PATH 上，運行 jconsole 即可。
如果從 GUI shell 啟動，找到 JDK 安裝路徑，打開 bin 文件夾，雙擊 jconsole
。

當分析工具彈出時（取決於正在運行的 Java 版本以及正在運行的 Java 程序數量），可能會出現一個對話框，要求輸入一個進程的 URL 來連接，也可能列出許多不同的本地 Java 進程（有時包含 JConsole 進程本身）來連接。如圖所示：

想分析那個程序就雙擊那個進程。

三、如何設置JAVA程序運行時可以被JConsolse連接分析

本地程序（相對於開啟JConsole的計算機），無需設置任何參數就可以被本地開啟的JConsole連接（Java SE 6開始無需設置，之前還是需要設置運行時參數 -Dcom.sun.management.jmxremote ）
無認證連接 (下面的設置表示：連接的埠為8999、無需認證就可以被連接)
Java代碼

-Dcom.sun.management.jmxremote.port=8999 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false
如果考慮到安全因素，需要認證，需要安全連接，也是可以搞定的。參考：http://download.oracle.com/javase/6/docs/technotes/guides/management/agent.html#gdenv

四、JConsole如何連接遠程機器的JAVA程序（舉例說明）

1、寫一個簡單的一直運行的JAVA程序，運行在某台機器上如(192.168.0.181)

Java代碼
java -cp . -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.managent.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false JConsoleTest

2、另外一台機器進行連接

可以直接使用命令：

Java代碼
jconsole.exe 192.168.0.181:8999

也可以在已經打開的JConsole界面操作連接->新建連接->選擇遠程進程->輸入遠程主機IP和埠號->點擊「連接」，如圖：

然後就會進入分析界面：

性能分析

下面說說如何分析，如何使用這六個標簽

概述:
Displays overview information about the Java VM and monitored values.
內存:
顯示內存使用信息
線程:
顯示線程使用信息
類:
顯示類裝載信息
*VM摘要:*顯示java VM信息
MBeans:
顯示 MBeans.

概述

概述很簡單沒啥說的，自己看看吧，不過值得一提的是對著圖點擊右鍵可以保存數據到CSV文件，以後可以使用其他工具來分析這些數據。

內存

這個比較有價值，參看堆內存，非堆內存，內存池的狀況總體內存的分配和使用情況以及不同的GC進行垃圾回收的次數和時間。可以手動進行GC查看內存變化。

在分析JAVA內存問題進行調優時候非常有用，你要學習JVM內存模型，之後會發現這里的每個值都具有意義。

GC的演算法和參數對性能有顯著的影響，注意垃圾回收次數、時間、以及partial GC和full GC，調整你所使用的不同GC和以及各個GC下的參數，然後在這個視圖下觀察，以得到好的性能。

這里貼一下 Java HotSpot
VM garbage collector 下generational GC 的各代的劃分圖：

關於GC，可以參考：http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

線程

左下角顯示所有的活動線程（如果線程過多，可以在下面的過濾欄中輸入字元串過濾出你想要觀察的線程）。點擊某個顯示會顯示這個線程的名稱、狀態、阻塞和等待的次數、堆棧的信息。

統計圖顯示的是線程數目的峰值（紅色）和當前活動的線程（藍色）。

另外下面有個按鈕「檢測到死鎖」，有時候會有用處。

類

沒啥要說的。

VM摘要

也沒啥要說的，看看吧，內存狀況，操作系統...

MBean

這里可以有一些額外的操作。
http://jiajun.iteye.com/blog/810150

⑻ 如何利用 JConsole觀察分析Java程序的運行，進行排錯調優

JConsole 是一個內置 Java 性能分析器，可以從命令行或在 GUI shell 中運行。您可以輕松地使用 JConsole（或者，它更高端的「近親」 VisualVM ）來監控 Java 應用程序性能和跟蹤 Java 中的代碼。

⑼ 如何利用JConsole觀察分析JAVA程序的運行

⑽ 如何用javavisualvm 來進行性能分析

啟動jvisualvm
首先到JDK安裝目錄/bin目錄下，雙擊jvisualvm.exe文件啟動

進入jvisualvm界面，右側為正在運行的Java程序，打開了一個jconsole程序來做示例

雙擊要監控的Java進行，有關監控進程的概要，監控，線程等信息都會以圖像的方式顯現出來，能更方便的對Java運行程序做分析

右鍵左邊欄，正在運行的Java程序，可以執行Dump,線程，Dump堆的操作並且可以將正在運行的程序進行快照儲備，同時可以設置在發生內存溢出時自動生成Dump文件。

右鍵【文件】-->【添加遠程主機】可對遠程運行的Java程序進行監控

菜單欄，工具-->插件輔助功能可以幫助我們更細致對Java程序進行監視分析，比如Visual GC 能顯示年輕代里的Eden區和survivor區的實時數據

Visualvm是一個非常實用的Java 監控工具，操作十分方便，多用幾次就會很快的入手啦。

導航:首頁 > 程序命令 > java性能分析命令

java性能分析命令

與java性能分析命令相關的資料