工作以后,发觉真的几乎没有像大学那样空闲的时间,坐下来看看书写写博客了。最近的一篇博客距离现在已经近一个多月了,最近也在复习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理解也不是特别的深入,如有错误,还希望各位大神能指出。大家一同学习进步。