前面看了jdk的几个查看jvm信息的命令，然后只看不动手，不用回头就忘记的干干净净了。还是实际使用一下，然后顺便结合着jvm的内存分区，再深层次的记录一下几个分区的名称、大小、gc器、等等。

首先，查看一个进程，筛选一个进程，就可以使用jps -mvl ，m让他带上方法参数，v带上设置的jvm参数，l显示完整的运行main方法名称。

完了之后，就可以看到这个pid的好多信息了。但是这个看到的不全，还是有些虚拟机默认的参数是看不到的，这个时候已经拿到了pid，再使用jinfo -flags pid，就会显示这个pid的手动在脚本里面显示的设置的各种参数，再加上虚拟机自动设置的默认值的参数，看一个pid的jvm设置就更完全了。

然后，还打算看看这个pid的gc情况，就可以使用jstat -gc 1s 100 意思就是1s执行一次，执行100次，连续的看内存的gc才能发现问题。

下面是 jinfo -flags pid的输出

     * 命令：jinfo -flags 64363* 输出：* Attaching to process ID 64363, please wait...* Debugger attached successfully.* Server compiler detected.* JVM version is 25.131-b11** Non-default VM flags: -XX:+AlwaysPreTouch -XX:CICompilerCount=4 -XX:CMSInitiatingOccupancyFraction=75* -XX:+HeapDumpOnOutOfMemoryError* -XX:InitialHeapSize=4294967296 -XX:MaxHeapSize=4294967296* -XX:MaxNewSize=697892864* -XX:MaxTenuringThreshold=6 -XX:MinHeapDeltaBytes=196608* -XX:NewSize=697892864* -XX:OldPLABSize=16* -XX:OldSize=3597074432* -XX:ThreadStackSize=1024* -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedClassPointers* -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseFastUnorderedTimeStamps* -XX:+UseParNewGC** Command line:  -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly* -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true* -Djdk.io.permissionsUseCanonicalPath=true -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true* -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true* -Dlog4j.skipJansi=true -XX:+HeapDumpOnOutOfMemoryError* -Xms4g* -Xmx4g* -Des.path.home=/home/lxk/elasticsearch*

从 command line里面可以看到，通过-Xms最小-Xmx最大都是4g，不让堆自动扩展，是不是以为这个heap的大小就是完整的4个g呢？我之前一直以为是这样的，直到下面的因为好奇而测试了一下，好像不是的。

下面是一个jstat -gc pid 的执行结果

     * 命令：jstat -gc 64363* 输出：*  S0C    S1C      S0U    S1U       EC       EU        OC         OU           MC     MU    CCSC   CCSU    YGC     YGCT    FGC    FGCT     GCT* 68096.0 68096.0  0.0   16160.3   545344.0  397868.8 3512768.0  2109826.5  71216.0 66507.1 9304.0 8046.9  22389  942.637  270    15.966  958.603*

这个jstat -gc其实已经把堆区的信息表达的差不多了，要是觉得这个还不够的话。

还有个jdk提供的命令，jmap -heap pid。他打印的也差不多是这个吧。

他可就不能批次执行，然后很直观的看每个分区的内存变化了。

要是打算看看内存活着live的对象具体是啥，就需要使用

jmap -histo:live pid，这个也比较重要。不过我这次是好奇大小问题。

然后，我就好奇，s区+e区+o区最终会不会等于堆heap的大小。

然后就有了下面的测试代码

package com.lxk.jdk.jvm.gc;import java.text.DecimalFormat;/*** 在 jdk1.8 前提下测试堆里面的各区间的大小* 参考 jps和jstat2个jdk提供的内存监控工具。** @author LiXuekai on 2020/6/5*/
public class HeapSizeTest {public static void main(String[] args) {// jinfo 出来的jvm参数，这三个的单位是 byte 字节long maxHeapSize = 4294967296L,newSize = 697892864L,oldSize = 3597074432L;System.out.println("InitialHeapSize = MaxHeapSize = " + showNumberBetter(maxHeapSize));long all = newSize + oldSize;System.out.println("newSize + oldSize = " + showNumberBetter(all));System.out.println("newSize + oldSize == maxHeapSize is true.");System.out.println("NewSize is " + showNumberBetter(newSize));System.out.println("OldSize is " + showNumberBetter(oldSize));// jstat 出来的jvm参数 下面的这些个的但是 k bytes KBlong s0 = 68096L,s1 = 68096L,eden = 545344L,old = 3512768L,mc = 71216,ccs = 9304;long young = s0 + s1 + eden;System.out.println("s0 + s1 + eden = " + showNumberBetter(young));long heap = young + old;System.out.println("young + old = " + showNumberBetter(heap));long total = heap + mc + ccs;System.out.println("heap + mc + ccs = " + showNumberBetter(total));}private static String showNumberBetter(long number) {DecimalFormat df = new DecimalFormat("#,###");return df.format(number);}
}

代码运行结果：

初始化的堆的大小是4.29个g，new区和old区的大小加起来和这个初始化堆的大小是一致的。

经常说新生代被分成2个s区和一个eden区，但是从上面的代码计算来看 s0 + s1 +Eden ！= newSize，稍微小了一丢丢。

jstat -gc 看到的old 的capacity的大小也比jinfo -flags看到的oldsize小一丢丢。

那最后的young + old =heap 也就少了

后面的heap + m + ccs 这个值就有点四不像了。

怎么这么加呢！

jdk1.8之后，metasapce区变成了本地内存，在堆之外，跟堆没关系。所以强行把他们加在一起，没道理。

ccs，是类压缩空间。说是针对64bit的系统优化的。

我就是看gc出来那么几个区，想都加一起，看看能否等于上面的初始化堆的大小。

当然是不可能的了，因为写代码的时候，我还没去了解啥是metaspace，啥是ccsc和ccscu呢。