转自: http://dolphin-ygj.iteye.com/blog/366216
jstatd
启动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被允许作网络操作
jps
列出所有的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作详细的介绍)。
jinfo(linux下特有)
观察运行中的java程序的运行环境参数:参数包括Java System属性和JVM命令行参数
实例:jinfo 2083
其中2083就是java进程id号,可以用jps得到这个id号。
输出内容太多了,不在这里一一列举,大家可以自己尝试这个命令。
jstack(linux下特有)
可以观察到jvm中当前所有线程的运行情况和线程当前状态
jstack 2083
输出内容如下:
jmap(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最大的对象找出来,对付内存泄漏特别有效。
jstat
最后要重点介绍下这个命令。
这是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等,可以组装多种符合自己需求的工具。
评论
jdk6 windows下也有了
jdk6 windows下也有了
关于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相关的部分,而是在其它部分。
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程序中每个窗口有一个后台显示缓存,当该窗口原来被遮挡,现在要显示时直接从该缓存拷贝数据进行渲染,即使该窗口的绘制线程被阻塞也可以完成这一渲染。