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性能分析命令相关的资料