JVM参数以及用法 - wenbochang - 博客园

JVM参数以及用法

工作以后,发觉真的几乎没有像大学那样空闲的时间,坐下来看看书写写博客了。最近的一篇博客距离现在已经近一个多月了,最近也在复习Java的东西,准备校招,看了看JVM的东西,就当作记笔记。

(一)JVM参数:

  • 第一类包括了标准参数。顾名思义,标准参数中包括功能和输出的参数都是很稳定的,很可能在将来的 JVM 版本中不会改变。你可以用 java 命令(或者是用 java -help)检索出所有标准参数。我们在第一部分中已经见到过一些标准参数,例如:-server。
  • 第二类是 X 参数,非标准化的参数在将来的版本中可能会改变。所有的这类参数都以 - X 开始,并且可以用 java -X 来检索。注意,不能保证所有参数都可以被检索出来,其中就没有 - Xcomp。
  • 第三类是包含 XX 参数(到目前为止最多的),它们同样不是标准的,甚至很长一段时间内不被列出来(最近,这种情况有改变 ,我们将在本系列的第三部分中讨论它们)。然而,在实际情况中 X 参数和 XX 参数并没有什么不同。X 参数的功能是十分稳定的,然而很多 XX 参数仍在实验当中(主要是 JVM 的开发者用于 debugging 和调优 JVM 自身的实现)。 

(1)-Xms20M

表示设置JVM启动内存的最小值为20M,必须以M为单位

(2)-Xmx20M

表示设置JVM启动内存的最大值为20M,必须以M为单位。将-Xmx和-Xms设置为一样可以避免JVM内存自动扩展。大的项目-Xmx和-Xms一般都要设置到10G、20G甚至还要高

(3)-verbose:gc

表示输出虚拟机中GC的详细情况

(4)-Xss128k

表示可以设置虚拟机栈的大小为128k

(5)-Xoss128k

表示设置本地方法栈的大小为128k。不过HotSpot并不区分虚拟机栈和本地方法栈,因此对于HotSpot来说这个参数是无效的

(6)-XX:PermSize=10M

表示JVM初始分配的永久代的容量,必须以M为单位

(7)-XX:MaxPermSize=10M

表示JVM允许分配的永久代的最大容量,必须以M为单位,大部分情况下这个参数默认为64M

(8)-Xnoclassgc

表示关闭JVM对类的垃圾回收

(9)-XX:+TraceClassLoading

表示查看类的加载信息

(10)-XX:+TraceClassUnLoading

表示查看类的卸载信息

(11)-XX:NewRatio=4

表示设置年轻代:老年代的大小比值为1:4,这意味着年轻代占整个堆的1/5

(12)-XX:SurvivorRatio=8

表示设置2个Survivor区:1个Eden区的大小比值为2:8,这意味着Survivor区占整个年轻代的1/5,这个参数默认为8

(13)-Xmn20M

表示设置年轻代的大小为20M

(14)-XX:+HeapDumpOnOutOfMemoryError

表示可以让虚拟机在出现内存溢出异常时Dump出当前的堆内存转储快照

(15)-XX:+UseG1GC

表示让JVM使用G1垃圾收集器

(16)-XX:+PrintGCDetails

表示在控制台上打印出GC具体细节

(17)-XX:+PrintGC

表示在控制台上打印出GC信息

(18)-XX:PretenureSizeThreshold=3145728

表示对象大于3145728(3M)时直接进入老年代分配,这里只能以字节作为单位

(19)-XX:MaxTenuringThreshold=1

表示对象年龄大于1,自动进入老年代

(20)-XX:CompileThreshold=1000

表示一个方法被调用1000次之后,会被认为是热点代码,并触发即时编译

(21)-XX:+PrintHeapAtGC

表示可以看到每次GC前后堆内存布局

(22)-XX:+PrintTLAB

表示可以看到TLAB的使用情况

(23)-XX:+UseSpining

开启自旋锁

(24)-XX:PreBlockSpin

更改自旋锁的自旋次数,使用这个参数必须先开启自旋锁


 

 

(二)用法实例:

 

 1 import java.util.Date;
 2 import java.util.concurrent.TimeUnit;
 3 
 4 public class Main {
 5     public static final int MB = 1024 * 1024;
 6     public static void main(String[] args) throws InterruptedException {
 7 
 8         TimeUnit.SECONDS.sleep(20);
 9         byte[] b1, b2, b3, b4;
10         b1 = new byte[2 * MB];
11         System.out.println("第一个2M分配完毕 time = " + new Date());
12         TimeUnit.SECONDS.sleep(5);
13         b2 = new byte[2 * MB];
14         System.out.println("第二个2M分配完毕 time = " + new Date());
15         TimeUnit.SECONDS.sleep(5);
16         b3 = new byte[2 * MB];
17         System.out.println("第三个2M分配完毕 time = " + new Date());
18         TimeUnit.SECONDS.sleep(5);
19         b4 = new byte[2 * MB];
20         System.out.println("第四个2M分配完毕 time = " + new Date());
21         TimeUnit.SECONDS.sleep(10);
22     }
23 }

 

 

JVM的参数设置如下:  -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8

Xms最小堆,Xmx最大堆都设置为了20M。Xmn年轻代设置为了10M,那么老年代也为10M,SurvivorRatio年轻带的Eden和Survivor的比值为8:1:1。

 

2 [GC (Allocation Failure) [PSYoungGen: 8192K->1008K(9216K)] 8192K->1648K(19456K), 0.0012271 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
 3 [GC (Allocation Failure) [PSYoungGen: 7446K->1016K(9216K)] 8086K->2352K(19456K), 0.0016344 secs] [Times: user=0.13 sys=0.00, real=0.00 secs] 
 4 第一个2M分配完毕 time = Sun Jul 29 16:00:40 CST 2018
 5 第二个2M分配完毕 time = Sun Jul 29 16:00:45 CST 2018
 6 第三个2M分配完毕 time = Sun Jul 29 16:00:50 CST 2018
 7 [GC (Allocation Failure) [PSYoungGen: 8414K->1000K(9216K)] 9750K->8577K(19456K), 0.0065138 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
 8 [Full GC (Ergonomics) [PSYoungGen: 1000K->0K(9216K)] [ParOldGen: 7577K->8005K(10240K)] 8577K->8005K(19456K), [Metaspace: 9104K->8987K(1058816K)], 0.0158481 secs] [Times: user=0.13 sys=0.00, real=0.02 secs] 
 9 第四个2M分配完毕 time = Sun Jul 29 16:00:55 CST 2018
10 Heap
11  PSYoungGen      total 9216K, used 2921K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
12   eden space 8192K, 35% used [0x00000000ff600000,0x00000000ff8da738,0x00000000ffe00000)
13   from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
14   to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
15  ParOldGen       total 10240K, used 8005K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
16   object space 10240K, 78% used [0x00000000fec00000,0x00000000ff3d15f8,0x00000000ff600000)
17  Metaspace       used 9046K, capacity 9256K, committed 9600K, reserved 1058816K
18   class space    used 1060K, capacity 1117K, committed 1152K, reserved 1048576K
19 
20 Process finished with exit code 0

 

 

 

 

 分析如下:

 第二,第三行可能是  TimeUnit.SECONDS.sleep(20); 这个占了内存,导致内存不足,然后就进行了两次年轻代GC,主要是为了看jconsole的那两幅图。

分配了三个2M以后,发觉eden区不够位置了,此时进行了年轻代的GC,但是 担保失败了 GC (Allocation Failure)。可能在老年代没有找到连续的内存,所以担保失败后,进行了一次full gc。

我们看jconsole上面的两幅图片,在16:01前面,Eden区突然下降,Old区突然上升。说明full gc将Eden区的三个2M的全部放到了Old区。然后将第四个2M的放到了Eden区。

所以最后,Eden区分配了一个b4,Old区分配了b1,b2,b3三个。看日志也可以看出来。

 

下来我们修改下参数,避免它进行full gc,毕竟full gc是不太好的。 

-verbose:gc -Xms110M -Xmx110M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8

我们将老年代调到100M,你会发觉就不会进行full gc了,因为担保成功了。所以新生代,老年代最好的比列,并不是1:1,而是老年代站绝大多数,毕竟新生代 “死的快”。

 

最近接触到的JVM参数仅限于这几个,工具用的也就是jps,jconsole,不是特别的多。所以这里就举了一个例子出来。但这个例子的很好的说明了,如何避免Full GC

Full GC发生大概有以下几种情况:

1:老年代不足,比如上面的full gc。新生代的对象不能全部进入老年代,即担保失败,那么就行一次full gc。同理大对象直接进入老年代,也可能进行full gc

2:CMS垃圾回收器。CMS因为采用的标记清除算法,所以很容易产生大量的碎片,所以full gc特别容易。还有一种就是CMS是一种并发清理垃圾的,在并发清理的过程,有对象进入,但空间不足,也会造成一次full gc。可能通过调参来避免,比如调到老年代用到了90%,85%等进行cms收集来避免。

 

自己本人由于是学生,实战经验比较少,对JVM理解也不是特别的深入,如有错误,还希望各位大神能指出。大家一同学习进步。

 

posted on 2018-08-10 19:23 wenbochang 阅读(...) 评论(...) 编辑 收藏

导航

公告