调度系统设计精要

标签：共享内存   需求分析   损坏   unp   dom   申请   schedule   高度   问题：   

JDK提供了几个很实用的工具，如下：

jinfo：观察运行中的java程序的运行环境参数：参数包括Java System属性和JVM命令行参数，java class path等信息。命令格式：jinfo 进程pid
jps：用来显示本地的java进程，可以查看本地运行着几个java程序，并显示他们的进程号。命令格式：jps   或 jps 远程服务ip地址    （默认端口1099）
jstat：一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量。

jstack：可以观察到jvm中当前所有线程的运行情况和线程当前状态。, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。命令格式：jstack 进程pid
              当程序出现死锁的时候，使用命令：jstack 进程ID > jstack.log，然后在jstack.log文件中，搜索关键字“BLOCKED”，定位到引起死锁的地方。

jmap：观察运行中的jvm物理内存的占用情况（如：产生哪些对象，及其数量）。命令格式：jmap [option] pid

      option参数如下：
             -heap：打印jvm heap的情况
             -histo：打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
             -histo：live ：同上，但是只答应存活对象的情况
             -permstat：打印permanent generation heap情况

       使用jmap进行 heap dump的例子： jmap -dump:format=b,file=<filename> <pid>  

       打印内存统计图：jmap -histo:live <pid>

       结果中每行显示了当前堆中每种类类型的信息，包含被分配的实例个数及其消耗的字节数。选项“live”，表示只统计存活的对象

       需要注意的是，jmap不是运行分析工具，在生成统计图时JVM可能会暂停，因此当生成统计图时需要确认这种暂停对程序是可接受的。
jconsole：一个java GUI监视工具，可以以图表化的形式显示各种数据。并可通过远程连接监视远程的服务器VM。

这些命令的使用，见官方文档：
jps：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jps.html
jstat：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html

jstack：http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstack.html
jmap：http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html
jconsole：http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

 jstat的一些参数：

你可以只关心那些最常用的命令，你会经常用到 -gcutil (或-gccause), -gc and –gccapacity。

·         -gcutil 被用于检查堆间的使用情况，GC执行的次数以及GC操作所花费的时间。

·         -gccapacity以及其他的参数可以用于检查实际分配内存的大小。

不同的jstat参数输出不同类型的列，如下表所示，根据你使用的”jstat option”会输出不同列的信息。

参考文章：http://www.importnew.com/2057.html

下面内容，摘自：http://jameswxx.javaeye.com/blog/731763

在本机执行 jstat -gcutil 340 10000，这个命令是每个10秒钟输出一次jvm的gc信息，10000指的是间隔时间为10000毫秒。屏幕上显示如下信息（我只取了第一行，因为是按的一定频率显示，所以实际执行的时候，会有很多行）：

   S0       S1       E        O          P       YGC     YGCT    FGC    FGCT     GCT  
 54.62   0.00  42.87  43.52  86.24   1792    5.093     33       7.670   12.763

S0:新生代的susvivor0区，空间使用率为54..62% S1:新生代的susvivor1区，空间使用率为0.00%(因为还没有执行第二次minor收集) E:eden区，空间使用率42.87% O:旧生代，空间使用率43.52% P:持久带，空间使用率86.24% YGC:minor gc执行次数1792次 YGCT:minor gc耗费的时间5.093毫秒 FGC:full gc执行次数33 FGCT:full gc耗费的时间7.670毫秒 GCT:gc耗费的总时间12.763毫秒

如果young gc和full gc能够正常发生，而且都能有效回收内存，常驻内存区变化不明显，则说明java内存释放情况正常，垃圾回收及时，java内存泄露的几率就会大大降低。但也不能说明一定没有内存泄露。

每次young gc消耗的时间，可以用相间隔的两行YGCT相减得到。每次full gc消耗的时间，可以用相隔的两行FGCT相减得到

官方文档的一个例子：

Using the gcutil option

This example attaches to lvmid 21891 and takes 7 samples at 250 millisecond intervals and displays the output as specified by the -gcutil option.

jstat -gcutil 21891 250 7
  S0     S1     E      O      P     YGC    YGCT    FGC    FGCT     GCT
 12.44   0.00  27.20   9.49  96.70    78    0.176     5    0.495    0.672
 12.44   0.00  62.16   9.49  96.70    78    0.176     5    0.495    0.672
 12.44   0.00  83.97   9.49  96.70    78    0.176     5    0.495    0.672
  0.00   7.74   0.00   9.51  96.70    79    0.177     5    0.495    0.673
  0.00   7.74  23.37   9.51  96.70    79    0.177     5    0.495    0.673
  0.00   7.74  43.82   9.51  96.70    79    0.177     5    0.495    0.673
  0.00   7.74  58.11   9.51  96.71    79    0.177     5    0.495    0.673
The output of this example shows that a young generation collection occurred between the 3rd and 4th sample. The collection took 0.001 seconds and promoted objects from the eden space (E) to the old space (O), resulting in an increase of old space utilization from 9.49% to 9.51%. Before the collection, the survivor space was 12.44% utilized, but after this collection it is only 7.74% utilized.

调度系统设计精要

标签：共享内存   需求分析   损坏   unp   dom   申请   schedule   高度   问题：   

原文地址：https://blog.51cto.com/14890690/2518254