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