深入JVM内核（三）——常用JVM配置参数

迈不过友情╰ 2022-05-20 09:50 331阅读 0赞

**由于之前看的容易忘记，因此特记录下来，以便学习总结与更好理解，该系列博文也是第一次记录，所有有好多不完善之处请见谅与留言指出，如果有幸大家看到该博文，希望报以参考目的看浏览，如有错误之处，谢谢大家指出与留言。**

# 一、常用JVM配置参数 #

1、Trace跟踪参数

2、堆的分配参数

3、栈的分配参数

# 二、Trace跟踪参数（主要是gc的跟踪） #

1、-verbose:gc    打开gc的跟踪日志

2、-XX:+printGC   这个也是打开GC的log开关

3、可以打印GC的简要信息（在系统程序运行时就可以打印gc的日志信息）

每一次GC（垃圾回收）都会有相关的信息打出，包块话费的时间

\[GC 4790K->374K(15872K), 0.0001606 secs\] 原本堆4790k  gc之后374K

从log可以货到的信息：在gc之前用了4兆，gc之后用了374K，所以表示回收了将近4兆空间，而整个堆的大小空间将近16兆，同事也可以看到花费的时间

\[GC 4790K->374K(15872K), 0.0001474 secs\]

\[GC 4790K->374K(15872K), 0.0001563 secs\]

\[GC 4790K->374K(15872K), 0.0001682 secs\]

4、-XX:+PrintGCDetails （上面的方式打印的信息方式稍微简单，可以通过这个打印详细信息）

打印GC详细信息

5、-XX:+PrintGCTimeStamps （打印GC发生的时间戳）

打印CG发生的时间戳

例 Details 日志信息：

\[GC\[DefNew: 4416K->0K(4928K), 0.0001897 secs\] 4790K->374K(15872K), 0.0002232 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]

6、-XX:+PrintGCDetails的输出  （这个是在PrintGCDetails运行后的一段描述）

Heap                                12288K+ 1536K                           低边界               当前边界             最高边界

def new generation   total 13824K, used 11223K \[0x27e80000, 0x28d80000, 0x28d80000)    （0x28d80000-0x27e80000)/1024/1024=15M

eden space 12288K,  91% used \[0x27e80000, 0x28975f20, 0x28a80000)

from space 1536K,   0% used \[0x28a80000, 0x28a80000, 0x28c00000)

to   space 1536K,   0% used \[0x28c00000, 0x28c00000, 0x28d80000)

tenured generation   total 5120K, used 0K \[0x28d80000, 0x29280000, 0x34680000)

the space 5120K,   0% used \[0x28d80000, 0x28d80000, 0x28d80200, 0x29280000)

compacting perm gen  total 12288K, used 142K \[0x34680000, 0x35280000, 0x38680000)

the space 12288K,   1% used \[0x34680000, 0x346a3a90, 0x346a3c00, 0x35280000)

ro space 10240K,  44% used \[0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)

rw space 12288K,  52% used \[0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)

就是在程序结束后描述，他会把程序的整个堆的信息打印出来。

首先他展示的事def new generation新生代的状况， 可看出新生代一共有13兆空间，已经使用11兆；同时可看到eden space（伊甸园）对象出生的地方，可使用的空间是2288K，那么这个空间已经有91% 被使用了；下面的from和to就是两个幸存代，对等的，他们大小一定是相等的。接着打印老年代tenured generation，再往后是持久代compacting ，也就是perm gen永久区和方法区被使用情况，他的使用时142K，相对比较小，是因为在jdk1.5后，在串行gc基础上，加上了共享空间，一些简单的类都会加载在这里。ro和rw是共享区间，供所有jvm使用，一个是只读，一个是可读可写的，他们占得比重比较大，也就是主要的类主要加载在这里面。

进一步介绍：例如：\[0x27e80000, 0x28d80000, 0x28d80000) 分别介绍新生代他在内存中的位置。如上面显示，第一个代表低边界，也就是他的起始位置，第二个代表他当前所使用的，被分配的，申请到的位置，最后一个代表他是所能申请到的位置。

（0x28d80000-0x27e80000)/1024/1024=15M  这个正好15兆，也就是新生代15兆，但他只能用13兆。而 total 13824K也就是12288K+ 1536K 这两块之和。

7、-Xloggc:log/gc.log  （如何来重定向log，因为，他默认是控制台，无法保存，所以通过重定向把他保存起来）

指定GC log的位置，以文件输出

帮助开发人员分析问题

![70][]

8、-XX:+PrintHeapAtGC

每次一次GC后，都打印堆信息

\{Heap before GC invocations=0 (full 0):  def new generation   total 3072K, used 2752K \[0x33c80000, 0x33fd0000, 0x33fd0000)   eden space 2752K, 100% used \[0x33c80000, 0x33f30000, 0x33f30000)   from space 320K,   0% used \[0x33f30000, 0x33f30000, 0x33f80000)   to   space 320K,   0% used \[0x33f80000, 0x33f80000, 0x33fd0000)  tenured generation   total 6848K, used 0K \[0x33fd0000, 0x34680000, 0x34680000)    the space 6848K,   0% used \[0x33fd0000, 0x33fd0000, 0x33fd0200, 0x34680000)  compacting perm gen  total 12288K, used 143K \[0x34680000, 0x35280000, 0x38680000)    the space 12288K,   1% used \[0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)     ro space 10240K,  44% used \[0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)     rw space 12288K,  52% used \[0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)

**\[GC\[DefNew: 2752K->320K(3072K), 0.0014296 secs\] 2752K->377K(9920K), 0.0014604 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\] （这里是gc,上面是gc之前，下面是GC之后）**

Heap after GC invocations=1 (full 0):  def new generation   total 3072K, used 320K \[0x33c80000, 0x33fd0000, 0x33fd0000)   eden space 2752K,   0% used \[0x33c80000, 0x33c80000, 0x33f30000)   from space 320K, 100% used \[0x33f80000, 0x33fd0000, 0x33fd0000)   to   space 320K,   0% used \[0x33f30000, 0x33f30000, 0x33f80000)  tenured generation   total 6848K, used 57K \[0x33fd0000, 0x34680000, 0x34680000)    the space 6848K,   0% used \[0x33fd0000, 0x33fde458, 0x33fde600, 0x34680000)  compacting perm gen  total 12288K, used 143K \[0x34680000, 0x35280000, 0x38680000)    the space 12288K,   1% used \[0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)     ro space 10240K,  44% used \[0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)     rw space 12288K,  52% used \[0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000) \}

9、-XX:+TraceClassLoading

作用：监控类的加载 （监控类的加载顺序，哪些类被加载）

\[Loaded java.lang.Object from shared objects file\]

\[Loaded java.io.Serializable from shared objects file\]

\[Loaded java.lang.Comparable from shared objects file\]

\[Loaded java.lang.CharSequence from shared objects file\]

\[Loaded java.lang.String from shared objects file\]

\[Loaded java.lang.reflect.GenericDeclaration from shared objects file\]

\[Loaded java.lang.reflect.Type from shared objects file\]

10、-XX:+PrintClassHistogram（用于打印类的使用情况，）

按下Ctrl+Break后，打印类的信息：

num     \#instances         \#bytes  class name ----------------------------------------------

1:        890617      470266000 ** \[B**    代表byte数组，表示他占用的大小

2:        890643       21375432  java.util.**HashMap**$Node      可以看出haspMAP被大量使用，里面保存比较多

3:        890608       14249728  java.lang.**Long**

4:            13        8389712       \[Ljava.util.HashMap$Node;

5:          2062         371680    \[C

6:           463          41904      java.lang.Class

分别显示：**序号、实例数量、总大小、    类型**

# 三、堆的分配参数 #

1、-Xmx –Xms 指定最大堆和最小堆  说java虚拟机，最大可以使用多少空间  。在系统启动时，系统默认分配最小堆空间

-Xmx20m -Xms5m  运行代码：

System.out.print("Xmx=");

System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");  最大

System.out.print("free mem=");

System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");  可以没拿到系统可用的系统空间

System.out.print("total mem=");

System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");  总空间

输出如下：

Xmx=19.375M

free mem=4.342750549316406M

total mem=4.875M  当前可以用的，被分配的  就是Xms5m指定5兆

2、-Xmx20m -Xms5m  运行代码    这个案例是给数组分配一兆空间大小，结果如下

**byte\[\] b=new byte\[1\*1024\*1024\];  分配一兆**

System.out.println("分配了1M空间给数组");

System.out.print("Xmx="); System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");

System.out.print("free mem=");

System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");

System.out.print("total mem="); System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");

分配了1M空间给数组

Xmx=19.375M  最大是不变的

free mem=3.4791183471679688M   可用则减小一兆

total mem=4.875M  总空间不变，他还没有扩展，在java运行当中，Java会尽可能维持在最小堆中运行，你指定了5兆他会想办法在5兆内执行，如果他做了gc之后无法再5兆内去运行，内存不够，那么他才会去扩容。

**Java会尽可能维持在最小堆**

3、-Xmx20m -Xms5m  运行代码  （来展示扩容案例）

b=new byte\[4\*1024\*1024\]; System.out.println("分配了4M空间给数组");

System.out.print("Xmx="); System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");

System.out.print("free mem=");

System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");

System.out.print("total mem="); System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");

分配了4M空间给数组

Xmx=19.375M

free mem=3.5899810791015625M

total mem=9.00390625M   总内存变了

4、-Xmx20m -Xms5m  运行代码 （来看看做个GC的情况）

System.gc(); System.out.println("回收内存");

System.out.print("Xmx="); System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");

System.out.print("free mem=");

System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");

System.out.print("total mem="); System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");

回收内存 Xmx=19.375M

free mem=6.354591369628906M   做了gc之后，可用的内存增多。

total mem=10.75390625M    总内存来增多了

\-Xmx 和 –Xms 应该保持一个什么关系，可以让系统的性能尽可能的好呢？

如果你要做一个Java的桌面产品，需要绑定JRE，但是JRE又很大，你如何做一下JRE的瘦身呢？

5、-Xmn  用来设置绝对值

用来 设置新生代大小

6、-XX:NewRatio   是一个比例  》可以设置百分比

新生代（eden+2\*s）和老年代（不包含永久区）的比值

4 表示 新生代:老年代=1:4，即年轻代占堆的1/5

7、-XX:SurvivorRatio  幸存代的比率

设置两个Survivor区和eden的比

8表示 两个Survivor :eden=2:8，即一个Survivor占年轻代的1/10

看一个例子：

![70 1][]

如上设置之后，打印信息如上，如上新生代内存比较少，所以10兆的内存全部分配在老年代，老年分配52%比例，没有处罚GC。

如下，新生代值调整到15兆，如下，新生代大于10兆，所以代码运行的10兆，存入新生代，所以老年代没有使用

![70 2][]

在如下案例，分配7兆，发生了gc

![70 3][]

现在调整幸存代值，如下

![70 4][]

一共处罚，三次gc.一共出发了7兆的回收![70 5][]

老年代，并没有使用，因为增大了from和to，导致幸存代他自己可以处理了，所以没有使用老年代；主要他是分配系统级别的对象的空间，这里使用比较简单的对象。比如线程等等

如下，进一步增大，from和to

![70 6][]

gc一次进行了两次，剩余的内存3兆还在新生代。

下面案例： 幸存代用多了是非常浪费的，所以合理的减少幸存代大小。 把幸存代减到了2兆（2048K）.,那么eden区扩展了6兆，这是gc次数下降了1次，因为空间得到了更加合理的利用。同样，gc的次数减少，好多对象就没有机会晋升到老年代，所以老年代使用为0.

![70 7][]

8、-XX:+HeapDumpOnOutOfMemoryError  （做堆做一个转存，如果系统发生这个outofMe....问题，说明这个系统是不稳定了，那么重现是很困难的，所以在运行时可以使用这个参数，把堆信息导出来。当系统dump后来分析这个文件）

OOM时导出堆到文件

9、-XX:+HeapDumpPath  （定义这个堆，dump后到那个位置）

导出OOM的路径

如这个例子：

\-Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/a.dump

Vector v=new Vector();

for(int i=0;i<25;i++)

v.add(new byte\[1\*1024\*1024\]);

![70 8][]

下面就是dump的文件

![70 9][]

如图上图看出，byte塞满了整个空间

11、-XX:OnOutOfMemoryError  （用来指定一个脚本，在OOM之后，可以执行任何脚本）

在OOM时，执行一个脚本

"-XX:OnOutOfMemoryError=D:/tools/jdk1.7\_40/bin/printstack.bat %p“

当程序OOM时，在D:/a.txt中将会生成线程的dump

printstack.bat这个脚本做的事情是：  D:/tools/jdk1.7\_40/bin/jstack -F %1 > D:/a.txt  就是把线程信息打印到D:/a.txt这个文件，同时这个脚本可以任意指定的，所以：

可以在OOM时，发送邮件，甚至是重启程序

# 四、堆的分配参数 – 总结 #

1.根据实际事情调整新生代和幸存代的大小（并没有最优的搭配，根据实际情况）

2.官方推荐新生代占堆的3/8、幸存代占新生代的1/10

4.在OOM时，**记得Dump出堆，确保可以排查现场问题**

# 五、永久区分配参数 #

1、-XX:PermSize  、-XX:MaxPermSize 分别 设置永久区的初始空间和最大空间

他们表示，一个系统可以容纳多少个类型

实验：

使用CGLIB等库的时候，可能会产生大量的类，这些类，他就会占用永久代，有可能撑爆永久区导致OOM

for(int i=0;i<100000;i++){
        CglibBean bean = new CglibBean("geym.jvm.ch3.perm.bean"+i,new HashMap());
    }

不断产生新的类，

下面可看到Perm已经满了。

![70 10][]

可以看出持久代用了99%,说明产生OOM就是他的内存满了原因。

3、打开堆的Dump  （可以到处上面使用情况）

** 堆空间实际占用非常少**

** 但是永久区溢出 一样抛出OOM**

![70 11][]

**如果堆空间没有用完也抛出了OOM，有可能是永久区导致的**

# 六、栈大小分配（栈指的是每个线程私有的区域，每个线程都会拥有栈，他对线程的运行时必不可少的。） #

1、-Xss  （通过这个参数设置）

一般来说 通常只分配几百K（因为栈越大，因为线程数越多，系统中线程一增多，所以想运行更多线程，就要设置小一点）

栈 也决定了函数调用的深度 ，在系统中有递归调用，那么栈空间就比较重要，如果栈空间小，那么就会发生栈溢出。

每个线程都有独立的栈空间

局部变量、参数 分配在栈上

比如：递归溢出案例

public class TestStackDeep {
    	private static int count=0;
    	public static void recursion(long a,long b,long c){
    		long e=1,f=2,g=3,h=4,i=5,k=6,q=7,x=8,y=9,z=10;
    		count++;
    		recursion(a,b,c);
    	}
    	public static void main(String args[]){
    		try{
    			recursion(0L,0L,0L);
    		}catch(Throwable e){
    			System.out.println("deep of calling = "+count);
    			e.printStackTrace();
    		}
    	}
    }

递归调用
    -Xss128K
    deep of calling = 701
    java.lang.StackOverflowError
    
    -Xss256K
    deep of calling = 1817
    java.lang.StackOverflowError

如上图可看：分配一些大的栈空间情况，使用递归。

例如：

![70 12][]

方式一情况：分配128K,那么在执行第701次报出内存溢出。将来遇到这个错可以看出，意味着你的函数的调用层次太深。

如果适量的增加栈空间

![70 13][]

那么调用的次数也会增加，因为他是一个没有出口的递归函数，所以他必然的会栈溢出。

另一个情况，想让函数多调用几次：那么可以减少局部变量 ，因为在栈争里面主要的就是局部变量表，而局部变量表包含两个部分，一个是参数，一个是这个函数中局部变量，那么如果能够减少局部变量数量，那么就可以函数调用每一次消耗的栈空间，那么也能这样让函数多调用几次。

这里面主要介绍主要的参数，其他还有很多，大家有时间可以去研究。

[70]: /images/20220520/fe5108b7599e47208a997349bdba7b9f.png
[70 1]: /images/20220520/b191151d5e5a4eafa80f321da04c504d.png
[70 2]: /images/20220520/f63e7c26551e46d18ab3ed68c22a9d88.png
[70 3]: /images/20220520/7428aa65b1de4b34b36413b05b09b81e.png
[70 4]: /images/20220520/d6656de886e44397b76527a6041c9b9b.png
[70 5]: /images/20220520/67703f1a49dd4441b952dfa70c730053.png
[70 6]: /images/20220520/12e2f38270ac428b81236b103ef76727.png
[70 7]: /images/20220520/6610bee49eca4fcfb1fc31d05e33fd1f.png
[70 8]: /images/20220520/84ce66a582dd407ea26ab7e1245ba021.png
[70 9]: /images/20220520/078227a6acae4d2b885e83c4c7770348.png
[70 10]: /images/20220520/1798ebd3657b49528db90fcb87f9f1e8.png
[70 11]: /images/20220520/5014026e9c724f148449bc607ffca0e9.png
[70 12]: /images/20220520/bb74ef8d182148b6983835c13e750906.png
[70 13]: /images/20220520/36910e4cd7b848a18560b562291a8e86.png