JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jsta

启动jvm监控服务。它是一个基于rmi的应用，向远程机器提供本机jvm应用程序的信息。默认端口1099。
实例：jstatd -J-Djava.security.policy=my.policy

my.policy文件需要自己建立，内如如下：
grant codebase "file:$JAVA_HOME/lib/tools.jar" {
 permission java.security.AllPermission;
};
这是安全策略文件，因为jdk对jvm做了jaas的安全检测，所以我们必须设置一些策略，使得jstatd被允许作网络操作


列出所有的jvm实例
实例：
jps
列出本机所有的jvm实例

jps 192.168.0.77
列出远程服务器192.168.0.77机器所有的jvm实例，采用rmi协议，默认连接端口为1099
（前提是远程服务器提供jstatd服务）

输出内容如下：
jones@jones:~/data/ebook/java/j2se/jdk_gc$ jps
6286 Jps
6174  Jstat

jconsole
一个图形化界面，可以观察到java进程的gc，class，内存等信息。虽然比较直观，但是个人还是比较倾向于使用jstat命令（在最后一部分会对jstat作详细的介绍）。

（linux下特有）
观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数
实例：jinfo 2083
其中2083就是java进程id号，可以用jps得到这个id号。
输出内容太多了，不在这里一一列举，大家可以自己尝试这个命令。

（linux下特有）
可以观察到jvm中当前所有线程的运行情况和线程当前状态
jstack 2083
输出内容如下：


 

（linux下特有，也是很常用的一个命令）
观察运行中的jvm物理内存的占用情况。
参数如下：
-heap：打印jvm heap的情况
-histo：打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
-histo：live ：同上，但是只答应存活对象的情况
-permstat：打印permanent generation heap情况

命令使用：
jmap -heap 2083
可以观察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的内存使用情况
输出内容：


 

jmap -histo 2083 ｜ jmap -histo:live 2083
可以观察heap中所有对象的情况（heap中所有生存的对象的情况）。包括对象数量和所占空间大小。
输出内容：


 
写个脚本，可以很快把占用heap最大的对象找出来，对付内存泄漏特别有效。


最后要重点介绍下这个命令。
这是jdk命令中比较重要，也是相当实用的一个命令，可以观察到classloader，compiler，gc相关信息
具体参数如下：
-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况
-printcompilation：不知道干什么的，一直没用过。

一般比较常用的几个参数是：
jstat -class 2083 1000 10 （每隔1秒监控一次，一共做10次）
输出内容含义如下：

Loaded	Number of classes loaded.
Bytes	Number of Kbytes loaded.
Unloaded	Number of classes unloaded.
Bytes	Number of Kbytes unloaded.
Time	Time spent performing class load and unload operations.

 

 

jstat -gc 2083 2000 20（每隔2秒监控一次，共做10）
输出内容含义如下：

S0C	Current survivor（存活的） space 0 capacity (KB).
EC	Current eden space capacity (KB).
EU	Eden space utilization (KB).
OC	Current old space capacity (KB).
OU	Old space utilization (KB).
PC	Current permanent space capacity (KB).
PU	Permanent space utilization (KB).
YGC	Number of young generation GC Events.
YGCT	Young generation garbage collection time.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.

 

 

 

 

 

 

 

 

 

 

 

 

输出内容：


 

 

 监控内存使用情况 参数 （查看内存溢出相对有用）

jstat -gccause 2083 5000 （每隔5秒监控一次）
输出内容含义如下：

 

 

S0	Survivor space 0 utilization as a percentage of the space's current capacity.
S1	Survivor space 1 utilization as a percentage of the space's current capacity.
E	Eden space utilization as a percentage of the space's current capacity.
O	Old space utilization as a percentage of the space's current capacity.
P	Permanent space utilization as a percentage of the space's current capacity.
YGC	Number of young generation GC events.
YGCT	Young generation garbage collection time.
FGC	Number of full GC events.
FGCT	Full garbage collection time.
GCT	Total garbage collection time.
LGCC	Cause of last Garbage Collection.
GCC	Cause of current Garbage Collection.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

如果能熟练运用这些命令，尤其是在linux下，那么完全可以代替jprofile等监控工具了，谁让它收费呢。呵呵。
用命令的好处就是速度快，并且辅助于其他命令，比如grep gawk sed等，可以组装多种符合自己需求的工具。

• 大小: 283.4 KB

• 大小: 270.3 KB

• 大小: 354.3 KB

• 大小: 576.7 KB

• 查看图片附件

java内存模型 | apache自带的性能测试工具

• 22:06
• 浏览 (5408)
• 评论 (2)
• 分类:

评论

2 楼 2009-04-12   引用

java内存模型  http://dolphin-ygj.javaeye.com/blog/366280

关于JVM内存管理（适用于所有J2EE产品）
援引JDK1.3为例(JDK 1.4除了在垃圾回收上有变化，其他的变化不大)：

现在无论是JDK1.3还是1.4，我们都是使用Sun JDK。
请注意：weblogic8.0自带了2种JDK，一种是Sun JDK，另一种是BEA自己的JRocket。

1. JVM内存段分配及启动参数：

J2EE服务器的内存组成：
? Java堆：我们的程序和对象都在这个堆进行管理
? C堆：当引用到一些Native的对象，如网络访问、OCI方式的数据库连接等都在C堆里进行管理

Java堆的描述：

如下图





内存由 Perm 和 Heap 组成. 其中

Heap = {Old + young = { Eden , from, to } }


? Young及Old区域用来存放由Java类而生成的内存对象；
? Perm区域用来存放Java类及其他虚拟机自己的静态数据

垃圾回收描述：

垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收Young中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）；释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区/OLD区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

Java堆相关参数：

ms/mx：定义YOUNG+OLD段的总尺寸，ms为JVM启动时YOUNG+OLD的内存大小；mx为最大可占用的YOUNG+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

NewSize/MaxNewSize：定义YOUNG段的尺寸，NewSize为JVM启动时YOUNG的内存大小；MaxNewSize为最大可占用的YOUNG内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。

SurvivorRatio：设置Survivor空间和Eden空间的比例

例：
MEM_ARGS="-Xms512m -Xmx512m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:SurvivorRatio=6"

在上面的例子中：
YOUNG+OLD: 512M
YOUNG: 256M
Perm: 128M
Eden: YOUNG*6/(6+1+1)=192M
Survivor: YOUNG/(6+1+1)=32M

Java堆的总尺寸=YOUNG+OLD+Perm=640M

2. JVM内存分析工具

可以使用HPjmeter来进行分析，需要将JDK的GC日志打开(-verbose:gc)，可定期用HPjmeter对GC日志进行分析，Demo工具可提供Java Heap内存变化图，以及垃圾回收图，这样就很容易分析内存溢出时是哪个段产生问题

3. 内存溢出的可能性

1. OLD段溢出

这种内存溢出是最常见的情况之一，产生的原因可能是：
1) 设置的内存参数过小(ms/mx, NewSize/MaxNewSize)
2) 程序问题
? 单个程序持续进行消耗内存的处理，如循环几千次的字符串处理，对字符串处理应建议使用StringBuffer。此时不会报内存溢出错，却会使系统持续垃圾收集，无法处理其它请求，相关问题程序可通过Thread Dump获取（见系统问题诊断一章）

? 单个程序所申请内存过大，有的程序会申请几十乃至几百兆内存，此时JVM也会因无法申请到资源而出现内存溢出，对此首先要找到相关功能，然后交予程序员修改，要找到相关程序，必须在Apache日志中寻找。

? 当Java对象使用完毕后，其所引用的对象却没有销毁，使得JVM认为他还是活跃的对象而不进行回收，这样累计占用了大量内存而无法释放。由于目前市面上还没有对系统影响小的内存分析工具，故此时只能和程序员一起定位。

2. Perm段溢出

通常由于Perm段装载了大量的Servlet类而导致溢出，目前的解决办法：
1) 将PermSize扩大，一般256M能够满足要求
2) 若别无选择，则只能将servlet的路径加到CLASSPATH中，但一般不建议这么处理

3. C Heap溢出

系统对C Heap没有限制，故C Heap发生问题时，Java进程所占内存会持续增长，直到占用所有可用系统内存。以下是一个案例，发生在INCOME：

假如项目的生产环境为HPUX，使用的数据库连接池为OCI模式，在应用服务器所安装的Oracle客户端版本为Oracle 9201

症状：Java进程所占内存不断增长，直到使用完系统所有内存而崩溃。

寻找问题方法：

对UNIX操作系统来说，Java Heap在进程的数据段、C Heap在进程的堆栈段，我们持续分析Java进程的数据段及堆栈段的增长情况（系统有相关的内存分析的系统调用），结果发现其堆栈段持续增长，说明问题不在Java相关的部分，而是在其它部分。

1 楼 2009-04-12   引用

java6性能
J2SE 6（代号：Mustang野马）主要设计原则之一就是提升J2SE的性能和扩展能力，主要通过最大程度提升运行效率，更好的垃圾收集和一些客户端性能来达到。
1、偏向锁（Biased locking）

Java 6以前加锁操作都会导致一次原子CAS（Compare-And-Set）操作，CAS操作是比较耗时的，即使这个锁上实际上没有冲突，只被一个线程拥 有，也会带来较大开销。为解决这一问题，Java 6中引入偏向锁技术，即一个锁偏向于第一个加锁的线程，该线程后续加锁操作不需要同步。大概的实现如下：一个锁最初为NEUTRAL状态，当第一个线程加 锁时，将该锁的状态修改为BIASED，并记录线程ID，当这一线程进行后续加锁操作时，若发现状态是BIASED并且线程ID是当前线程ID，则只设置 一下加锁标志，不需要进行CAS操作。其它线程若要加这个锁，需要使用CAS操作将状态替换为REVOKE，并等待加锁标志清零，以后该锁的状态就变成 DEFAULT，常用旧的算法处理。这一功能可用-XX：-UseBiasedLocking命令禁止。

2、锁粗化（Lock coarsening）

如果一段代码经常性的加锁和解锁，在解锁与下次加锁之间又没干什么事情，则可以将多次加加锁解锁操作合并成一对。这一功能可用-XX：-EliminateLocks禁止。

3、自适应自旋（Adaptive spinning）

一般在多CPU的机器上加锁实现都会包含一个短期的自旋过程。自旋的次数不太好决定，自旋少了会导致线程被挂起和上下文切换增加，自旋多了耗CPU.为此Java 6中引入自适应自旋技术，即根据一个锁最近自旋加锁成功概率动态调整自旋次数。

4、常用大内存分布的堆（large page heap）

在大内分页是x86/amd64架构上用来减小TLB（虚拟地址到物理地址翻译缓存）大小的TLB失配率。Java 6中的内存堆可以使用这一技术。

5、提高数组拷贝性能

对每种类型大小写一个定制的汇编数组拷贝程序。

6、后台进行代码优化

Background Compilation in HotSpot™ Client Compiler： 后台进行代码优化

7、线性扫描寄存器分配算法（Linear Scan Register Allocation）

一种新的寄存器分配策略，基于SSA（static single assignment），性能提高10%左右。常用的寄存器分配算法将寄存器分配看作图着色问题，时间复杂度是O（n^4），不适用于Java的JIT编 译。原来的JVM里是根据一些本地启发式规则来分配寄存器，效果不太好，Java 6中使用的线性扫描寄存器算法能够达到与图颜色算法相似的效果，并且时间复杂度是线性的。

8、并行缩并垃圾收集器（Parallel Compaction Collector）

进行Full GC时使用并行垃圾收集（JDK 5里原来非Full GC是并行的但Full GC是串行的），使用-XX：+UseParallelOldGC开启这一功能

9、并行低停顿垃圾收集器（Concurrent Low Pause Collector）

显式调用gc（如System.gc）时也可以并行进行标记-清扫式垃圾收集，使用-XX：+ExplicitGCInvokesConcurrent开启。

10、Ergonomics in the 6.0 Java Virtual Machine

自动调整垃圾收集策略、堆大小等配置，这一功能在JDK 5中加入，JDK 6中得到显著增强，SPECjbb2005性能提高70%.

11、boot类装载器的优化

jre中增加一个描述package所在jar文件的元索引文件，加快classloader加载类性能，提高桌面Java应用启动速度（+15%）。内存占用也减少了10%

12、图形程序优化

在jvm启动之前显示splash.

Swing程序中每个窗口有一个后台显示缓存，当该窗口原来被遮挡，现在要显示时直接从该缓存拷贝数据进行渲染，即使该窗口的绘制线程被阻塞也可以完成这一渲染。