性能文章>JVM源码分析之jstat工具原理完全解读>

JVM源码分析之jstat工具原理完全解读原创

2年前
11262018

概述

jstat是hotspot自带的工具,和java一样也位于JAVA_HOME/bin下面,我们通过该工具可以实时了解当前进程的gc,compiler,class,memory等相关的情况,具体我们可以通过jstat -options来看我们到底支持哪些类型的数据,譬如JDK8下的结果是:

-class-compiler
-gc
-gccapacity
-gccause
-gcmetacapacity
-gcnew
-gcnewcapacity
-gcold
-gcoldcapacity
-gcutil
-printcompilation

jstat的输出

jstat大家用得其实挺多的,最常见的用法是jstat -gcutil,输出如下:

~ ᐅ jstat -gcutil 692 1000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT  0.00  41.49  59.79  83.66  89.92  78.74    295    5.436    10    3.855    9.291
  0.00  41.49  59.80  83.66  89.92  78.74    295    5.436    10    3.855    9.291
  0.00  41.49  59.80  83.66  89.92  78.74    295    5.436    10    3.855    9.291
  0.00  41.49  59.80  83.66  89.92  78.74    295    5.436    10    3.855    9.291
  0.00  41.49  59.80  83.66  89.92  78.74    295    5.436    10    3.855    9.291

那每一列是怎么定义,怎么计算的呢,其实在tools.jar里存在一个文件叫做jstat_options,这个文件里定义了上面的每种类型的输出结果,比如说gcutil

option gcutil {
  column {
    header "^S0^"    /* Survivor 0 Space - Percent Used */
    data (1-((sun.gc.generation.0.space.1.capacity - sun.gc.generation.0.space.1.used)/sun.gc.generation.0.space.1.capacity)) * 100
    scale raw
    align right
    width 6
    format "0.00"
  }
  column {
    header "^S1^"    /* Survivor 1 Space - Percent Used */
    data (1-((sun.gc.generation.0.space.2.capacity - sun.gc.generation.0.space.2.used)/sun.gc.generation.0.space.2.capacity)) * 100
    scale raw
    align right
    width 6
    format "0.00"
  }
  column {
    header "^E^"    /* Eden Space - Percent Used */
    data (1-((sun.gc.generation.0.space.0.capacity - sun.gc.generation.0.space.0.used)/sun.gc.generation.0.space.0.capacity)) * 100
    align right
    scale raw
    width 6
    format "0.00"
  }
  column {
    header "^O^"    /* Old Space - Percent Used */
    data (1-((sun.gc.generation.1.space.0.capacity - sun.gc.generation.1.space.0.used)/sun.gc.generation.1.space.0.capacity)) * 100
    align right
    scale raw
    width 6
    format "0.00"
  }
  column {
    header "^M^"    /* Metaspace Space - Percent Used */
    data (1-((sun.gc.metaspace.capacity - sun.gc.metaspace.used)/sun.gc.metaspace.capacity)) * 100
    align right
    width 6
    scale raw
    format "0.00"
  }
  column {
    header "^CCS^"    /* Compressed Class Space Space - Percent Used */
    data (1-((sun.gc.compressedclassspace.capacity - sun.gc.compressedclassspace.used)/sun.gc.compressedclassspace.capacity)) * 100
    align right
    width 6
    scale raw
    format "0.00"
  }
  column {
    header "^YGC^"    /* Young Generation Collections */
    data sun.gc.collector.0.invocations
    align right
    width 6
    format "0"
  }
  column {
    header "^YGCT^"    /* Young Generation Collection Time */
    data sun.gc.collector.0.time/sun.os.hrt.frequency
    align right
    scale sec
    width 8
    format "0.000"
  }
  column {
    header "^FGC^"    /* Full Collections */
    data sun.gc.collector.1.invocations
    align right
    width 5
    scale raw
    format "0"
  }
  column {
    header "^FGCT^"    /* Full Collection Time */
    data sun.gc.collector.1.time/sun.os.hrt.frequency
    align right
    scale sec
    width 8
    format "0.000"
  }
  column {
    header "^GCT^"    /* Total Garbage Collection Time */
    data (sun.gc.collector.0.time + sun.gc.collector.1.time)/sun.os.hrt.frequency
    align right
    width 8
    scale sec
    format "0.000"
  }
}

从上面的定义我们知道gcutil的每一列是什么意思,怎么计算出来的,其中类似sun.gc.generation.0.space.0.capacity这样的一些变量是jvm里创建并实时更新的值

jstat如何获取到这些变量的值

变量值显然是从目标进程里获取来的,但是是怎样来的?local socket还是memory share?其实是从一个共享文件里来的,这个文件叫PerfData,主要指的是/tmp/hsperfdata_<user>/<pid>这个文件

PerfData文件

文件创建

这个文件是否存在取决于两个参数,一个UsePerfData,另一个是PerfDisableSharedMem,如果设置了-XX:+PerfDisableSharedMem或者-XX:-UsePerfData,那这个文件是不会存在的,默认情况下PerfDisableSharedMem是关闭的,UsePerfData是打开的,所以默认情况下PerfData文件是存在的。对于UsePerfData和PerfDisableSharedMem这两个参数,这里着重讲一下:

  • UsePerfData:如果关闭了UsePerfData这个参数,那么jvm启动过程中perf memory都不会被创建,jvm运行过程中自然不会再将这些性能数据保存起来,默认情况是是打开的

  • PerfDisableSharedMem:该参数决定了存储PerfData的内存是不是可以被共享,也就是说不管这个参数设置没设置,jvm在启动的时候都会分配一块内存来存PerfData,只是说这个PerfData是不是其他进程可见的问题,如果设置了这个参数,说明不能被共享,此时其他进程将访问不了该内存,这样一来,譬如我们jps,jstat等都无法工作。默认这个参数是关闭的,也就是默认支持共享的方式

具体代码在PerfMemory::create_memory_region里

  if (PerfDisableSharedMem) {    // do not share the memory for the performance data.
    _start = create_standard_memory(size);
  }  else {
    _start = create_shared_memory(size);    if (_start == NULL) {      // creation of the shared memory region failed, attempt
      // to create a contiguous, non-shared memory region instead.
      //
      if (PrintMiscellaneous && Verbose) {
        warning("Reverting to non-shared PerfMemory region.\n");
      }
      PerfDisableSharedMem = true;
      _start = create_standard_memory(size);
    }
  }

文件删除

那这个文件什么时候删除?正常情况下当进程退出的时候会自动删除,但是某些极端情况下,比如kill -9,这种信号jvm是不能捕获的,所以导致进程直接退出了,而没有做一些收尾性的工作,这个时候你会发现进程虽然没了,但是这个文件其实还是存在的。那这个文件是不是就一直留着,只能等待人为的删除呢,jvm里考虑到了这种情况,会在当前用户接下来的任何一个java进程(比如说我们执行jps)起来的时候会去做一个判断,遍历/tmp/hsperfdata_<user>下的进程文件,挨个看进程是不是还存在,如果不存在了就直接删除该文件,判断是否存在的具体操作其实就是发一个kill -0的信号看是否有异常。

文件更新

由于这个文件是通过mmap的方式映射到了内存里,而jstat是直接通过DirectByteBuffer的方式从PerfData里读取的,所以只要内存里的值变了,那我们从jstat看到的值就会发生变化,内存里的值什么时候变,取决于-XX:PerfDataSamplingInterval这个参数,默认是50ms,也就是说50ms更新一次值,基本上可以认为是实时的了。

PerfData其他相关VM参数

  • -XX:PerfDataMemorySize:指定/tmp/hsperfdata_<user>
    下perfData文件的大小,默认是32KB,如果用户设置了该值,jvm里会自动和os的page size对齐,比如linux下pagesize默认是4KB,那如果你设置了31KB,那自动会分配32KB

  • -XX:+PerfDataSaveToFile:是否在进程退出的时候将PerfData里的数据保存到一个特定的文件里,文件路径由下面的参数指定,否则就在当前目录下

  • -XX:PerfDataSaveFile:指定保存PerfData文件的路径

jstat里的坑

本人暂时想到的两大坑:

  • 一次正常的Background CMS GC之后,发现FGC的值加了2次,后面发现主要原因是CMS有init mark和remark两个会暂停应用的阶段,同时因为是对old做gc,因此算了两次

  • JDK8下metaspace的使用情况不准确,比如说CCSC的值表示的是 Compressed Class Space Capacity,但是发现这个值的计算却不是reserve的值,所以我们可能会发现metaspace其实用了非常少,但是通过jstat看起使用率已经非常大了,因此这种情况最好是通过jmx的方式去取那些值做一个计算

size_t CompressedClassSpaceCounters::capacity() {  return MetaspaceAux::committed_bytes(Metaspace::ClassType);
}
请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得