一、虚拟机参数配置
在上一篇《Java自动内存管理机制——Java内存区域（上）》中介绍了有关的基础知识，这一篇主要是通过一些示例来了解有关虚拟机参数的配置。
1、Java堆参数设置
a）下面是一些简单的使用参数
其中最后一个是一个运行时参数设置的简单实例。一般-XX是系统级别的配置（日志信息，或者是配置使用什么样的垃圾回收器等等），后面跟上+表示启用。不是-XX基本上是对于应用层面的配置信息
下面是一个简单的实例：表示设置初始堆大小为5M，最大堆大小为20M，并将虚拟机的参数设置打印出来，后面会用示例程序来说明
b）如下所示程序：
package cn.jvm.test;
public class Test01 {
//-XX:+PrintGC -Xms5m -Xmx20m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+PrintCommandLineFlags
public static void main(String[] args) {
//查看GC信息
System.out.println("没有分配时候");
System.out.println("最大堆内存===" + Runtime.getRuntime().maxMemory());
System.out.println("空闲内存===" + Runtime.getRuntime().freeMemory());
System.out.println("总内存===" + Runtime.getRuntime().totalMemory());
byte[] testByte1 = new byte[1024 * 1024];
System.out.println("分配了1M");
System.out.println("最大堆内存===" + Runtime.getRuntime().maxMemory());
System.out.println("空闲内存===" + Runtime.getRuntime().freeMemory());
System.out.println("总内存===" + Runtime.getRuntime().totalMemory());
byte[] testByte2 = new byte[4 * 1024 * 1024];
System.out.println("分配了4M");
System.out.println("最大堆内存===" + Runtime.getRuntime().maxMemory());
System.out.println("空闲内存===" + Runtime.getRuntime().freeMemory());
System.out.println("总内存===" + Runtime.getRuntime().totalMemory());
}
}
然后配置上 -Xms5m -Xmx20m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+PrintCommandLineFlags参数来运行查看结果信息，在IDEA中进入，然后在VM Options中设置上面配置的参数
c）分析结果
"E:\Program Files\Java\jdk1.8.0_141\bin\java.exe" -Xms5m -Xmx20m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+PrintCommandLineFlags "-javaagent:E:\Program Files\IntelliJ IDEA 2018.3.3\lib\idea_rt.jar=49362:E:\Program Files\IntelliJ IDEA 2018.3.3\bin" -Dfile.encoding=UTF-8 -classpath "E:\Program Files\Java\jdk1.8.0_141\jre\lib\charsets.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\deploy.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\access-bridge-64.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\cldrdata.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\dnsns.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\jaccess.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\jfxrt.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\localedata.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\nashorn.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\sunec.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\sunjce_provider.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\sunmscapi.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\sunpkcs11.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\ext\zipfs.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\javaws.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\jce.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\jfr.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\jfxswt.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\jsse.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\management-agent.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\plugin.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\resources.jar;E:\Program Files\Java\jdk1.8.0_141\jre\lib\rt.jar;E:\IDEAProject\JVM\out\production\JVM" cn.jvm.test.Test01
-XX:InitialHeapSize=5242880 -XX:MaxHeapSize=20971520 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseSerialGC
[GC (Allocation Failure) [DefNew: 1664K->192K(1856K), 0.0018176 secs] 1664K->605K(5952K), 0.0028416 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
没有分配时候
最大堆内存===20316160
空闲内存===5202432
总内存===6094848
分配了1M
最大堆内存===20316160
空闲内存===4149872
总内存===6094848
[GC (Allocation Failure) [DefNew: 1485K->31K(1856K), 0.0025246 secs][Tenured: 1626K->1658K(4096K), 0.0031723 secs] 1899K->1658K(5952K), [Metaspace: 3432K->3432K(1056768K)], 0.0061214 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
分配了4M
最大堆内存===20316160
空闲内存===4406496
总内存===10358784
2112
Heap
def new generation total 1920K, used 76K [0x00000000fec00000, 0x00000000fee10000, 0x00000000ff2a0000)
eden space 1728K, 4% used [0x00000000fec00000, 0x00000000fec13018, 0x00000000fedb0000)
from space 192K, 0% used [0x00000000fedb0000, 0x00000000fedb0000, 0x00000000fede0000)
to space 192K, 0% used [0x00000000fede0000, 0x00000000fede0000, 0x00000000fee10000)
tenured generation total 8196K, used 5754K [0x00000000ff2a0000, 0x00000000ffaa1000, 0x0000000100000000)
the space 8196K, 70% used [0x00000000ff2a0000, 0x00000000ff83e998, 0x00000000ff83ea00, 0x00000000ffaa1000)
Metaspace used 3469K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 380K, capacity 388K, committed 512K, reserved 1048576K Process finished with exit code 0
输出的整个结果
我们通过查看输出结果和打印的日志信息，结合刚刚设置的参数来简单分析一下Java堆参数和程序运行的关系
1）我们在参数设置中配置了–XX:+PrintCommandLineFlags就会在结果中打印下面的信息
-XX:InitialHeapSize=5242880 -XX:MaxHeapSize=20971520 -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseLargePagesIndividualAllocation -XX:+UseSerialGC
然后将这些信息做一简单的解释：
-XX:InitialHeapSize=5242880 //设置初始堆大小（我们在参数设置中设置为5M）
-XX:MaxHeapSize=20971520 //设置最大堆大小（参数设置中设置为10M）
-XX:+PrintCommandLineFlags //打印自己设置的JVM参数
-XX:+PrintGCDetails //打印包括新生代（Eden、from、to）和老年代以及元空间的信息
-XX:+UseCompressedClassPointers //使用-XX:+UseCompressedClassPointers选项来压缩类指针,对象中指向类元数据的指针会被压缩成32位,类指针压缩空间会有一个基地址
-XX:+UseCompressedOops//使用-XX:+UseCompressedOops压缩对象指针,"oops"指的是普通对象指针("ordinary" object pointers)。
Java堆中对象指针会被压缩成32位。使用堆基地址（如果堆在低26G内存中的话，基地址为0）
-XX:-UseLargePagesIndividualAllocation
-XX:+UseSerialGC //使用串行收集器
2）下面是输出结果信息，我们来具体的看一下每行代表的含义
[GC (Allocation Failure) [DefNew: 1647K->192K(1856K), 0.0026381 secs] 1647K->604K(5952K), 0.0035661 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
没有分配时候
最大堆内存===20316160
空闲内存===5177136
总内存===6094848
分配了1M
最大堆内存===20316160
空闲内存===4128544
总内存===6094848
[GC (Allocation Failure) [DefNew: 1508K->30K(1856K), 0.0031475 secs][Tenured: 1626K->1656K(4096K), 0.0031027 secs] 1920K->1656K(5952K), [Metaspace: 3411K->3411K(1056768K)], 0.0067187 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
分配了4M
最大堆内存===20316160
空闲内存===4401904
总内存===10358784
①[GC (Allocation Failure) [DefNew: 1647K->192K(1856K), 0.0026381 secs] 1647K->604K(5952K), 0.0035661 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 结果分析
[
GC //用来区分是 Minor GC 还是 Full GC 的标志(Flag). 这里的 GC 表明本次发生的是 Minor GC.
(Allocation Failure) //引起垃圾回收的原因. 本次GC是因为年轻代中没有任何合适的区域能够存放需要分配的数据结构而触发的.
[DefNew: //使用的垃圾收集器的名字. DefNew 这个名字代表的是: 单线程采用标记复制(mark-copy)算法的, 使整个JVM暂停运行的年轻代(Young generation) 垃圾收集器.
1647K->192K(1856K), 0.0026381 secs] //在本次垃圾收集之前和之后的年轻代内存使用情况，从1647K回收到了192K（使用情况），括号中的1856K表示年轻代的总的大小.
1647K->604K(5952K), 0.0035661 secs] //在本次垃圾收集之前和之后整个堆内存的使用情况(Total used heap).括号中的5952K代表总的堆大小（基本上和初始时候设置的堆大小相同）
[Times:
user=0.00 //此次垃圾回收, 垃圾收集线程消耗的所有CPU时间.
sys=0.00, //系统调用以及等待系统事件的时间(waiting for system event)
real=0.00 // 应用程序暂停的时间(Clock time). 由于串行垃圾收集器(Serial Garbage Collector)只会使用单个线程, 所以 real time 等于 user 以及 system time 的总和.
secs]
②这是开始没有分配内存的时候打印的结果信息
没有分配时候
最大堆内存===20316160 //设置的-XX:MaxHeapSize=20971520
空闲内存===5177136 //初始的时候设置的-XX:InitialHeapSize=5242880
总内存===6094848 //堆内存加上其他的数据区域所占
③第一次分配1M内存时
分配了1M
最大堆内存===20316160 //这个值没有变化，和第一次没有分配的时候打印的结果一样
空闲内存===4128544 //分配1M后从5177136变化为现在的数值（5177136-4128544 =1048576 = 1024 * 1024）
总内存===6094848//总内存没有变化，和初始没有分配的时候是一样的
④第二次分配4M的时候，上面第一次分配之后还剩下4128544 = 3 * 1024 * 1024 = 3M，所以不够分配4M，这时候就需要扩展内存，（刚刚设置的-XX:MaxHeapSize=20971520 = 20 * 1024 * 1024 = 20M）
分配了4M
最大堆内存===20316160 //最大内存不变，和上面的两次输出相同
空闲内存===4401904 //总内存现在是9M，然后分配了5M，还剩下4M（4 * 1024 * 1024 = 4401904 ）
总内存===10358784 //由于最开始的5M不够分配，所以直接从最大内存处申请4M，这时候总内存就是9M = 9 * 1024 * 1024 = 10358784
⑤下面是第二次对整个堆进行GC
[GC
(Allocation Failure)
[DefNew:
1508K->30K(1856K), 0.0031475 secs] //新生代空间GC信息
[Tenured: 1626K->1656K(4096K), 0.0031027 secs] 1920K->1656K(5952K), //老年代空间回收信息 [Metaspace: 3411K->3411K(1056768K)], 0.0067187 secs] //元空间GC信息
[Times: user=0.00 sys=0.00, real=0.01 secs]
⑥开始的是时候我们设置了-XX:+PrintGCDetails ，所以最后会打印出整个GC的详细信息
Heap //GC主要在堆上面进行
def new generation total 1920K, used 82K [0x00000000fec00000, 0x00000000fee10000, 0x00000000ff2a0000) //新生代
eden space 1728K, 4% used [0x00000000fec00000, 0x00000000fec148c8, 0x00000000fedb0000) //eden区
from space 192K, 0% used [0x00000000fedb0000, 0x00000000fedb0000, 0x00000000fede0000) //from区
to space 192K, 0% used [0x00000000fede0000, 0x00000000fede0000, 0x00000000fee10000) //to区
//eden区+from区+to区总共使用2112K，在newgeneration中：(0x00000000fee10000-0x00000000fec00000) / 1024 = 2112
tenured generation total 8196K, used 5752K [0x00000000ff2a0000, 0x00000000ffaa1000, 0x0000000100000000)
//5752/8196 = 70%
the space 8196K, 70% used [0x00000000ff2a0000, 0x00000000ff83e2d8, 0x00000000ff83e400, 0x00000000ffaa1000) //老年代
Metaspace used 3461K, capacity 4496K, committed 4864K, reserved 1056768K //元空间区空间信息
class space used 379K, capacity 388K, committed 512K, reserved 1048576K
2、新生代中参数设置
1）通过设置-Xmn来设置新生代的大小，设置一个比较大的新生代可以减小老年代的空间大小，这样的设置对于整个GC的行为有比较大影响，新生代的大小一般会设置为整个堆空间的1/3或者1/4大小左右。-XX:SurvivorRatio用来设置新生代中eden和from/to的比例。-XX:SurvivorRatio=eden/from=eden/to
2）通过示例程序来查看关于新生代参数设置的方式和JVM结果分析。代码中会对于同一程序段进行三次不同的配置，然后通过jvm日志来分析不同的结果信息
package cn.jvm.test;
public class Test02 {
//第一次配置
//-Xms20m -Xmx20m -Xmn1m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC
//第二次配置
//-Xms20m -Xmx20m -Xmn7m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC
//第三次配置
//-XX:NewRatio = 老年代/新生代
//-Xms20m -Xmx20m -XX:NewRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC
public static void main(String[] args) {
byte[] b = null;
for (int i = 0; i < 10; i++) {
b = new byte[1 * 1024 * 1024];
}
}
}
①第一次配置-Xms20m -Xmx20m -Xmn1m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC
（初始堆大小=最大堆大小=20M，新生代大小为1M，新生代中eden:from:to = 2:1:1，然后使用使用串行收集器，并且打印GC详细信息）
这个时候的新生代就是1M，其中eden:from:to = 2:1:1，下面是在IDEA中配置信息
运行的结果如下所示，可以计算出得到新生代的大小和分配的大小相同，新生代中的eden和from/to的比例为2:1:1
②第二次配置同样是在Run/Debug Configuration中的VM options里面配置上-Xms20m -Xmx20m -Xmn7m -XX:SurvivorRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC，与第一次不同的只是改变了新生代的大小为7M，下面是运行结果
③设置第三次的分配参数-Xms20m -Xmx20m -XX:NewRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC。使用-XX:NewRatio可以设置老年代和新生代比例（-XX:NewRatio = 老年代/新生代）。所以第三次使用的是老年代和新生代按照比例进行划分，同样是在Run/Debug Configuration中的VM options里面配置上-Xms20m -Xmx20m -XX:NewRatio=2 -XX:+PrintGCDetails -XX:+UseSerialGC然后我们来查看运行结果：
3）不同的堆分布情况会对于系统的执行产生大的影响，可以考虑尽量的将对象预留在新生代中，减少老年代的GC次数。
3、栈参数设置
a）在HotSpot中，使用-Xss来设置栈容量的大小，如果请求的栈深度大于所提供允许的最大深度，将抛出Stack Overflow异常，如果扩展栈的时候不能申请到足够的内存，将会抛出OutOfMemoryError异常。
b）下面使用一个简单的测试程序演示OOM异常，程序中反复的调用自身，会一直申请栈空间，导致栈空间不够继续申请，最终抛出OOM异常
package cn.jvm.test;
public class Test04 {
//-Xss1m
private static int stackLength = 1;
public static void stackLeak() {
stackLength ++;
stackLeak();
}
public static void main(String[] args) {
try {
stackLeak();
} catch (Throwable e) {
System.out.println("最大栈深度" + stackLength);
e.printStackTrace();
}
}
}
c）在下面的输出结果之中：在单个线程下面，无论是由于栈帧太大还是由于虚拟机栈容量太小，当无法分配足够的内存的时候，都会抛出Stack OverflowError异常
d）在多线程模式下面：在多线程环境开发中，如果对于每个线程的栈分配的空间越大，越容易引起内存溢出的异常。原因如下：
操作系统为每个线程分配的进程的内存是有限度的，虚拟机可以使用参数来控制堆内存和方法区内存的max值，剩余的内存减去这两部分的所占空间，再除去永久区（1.7）、程序计数器的空间，余下的部分就会被每个线程各自分配的到自己的栈空间（包括虚拟机栈和本地方法栈），这样看来，如果每个线程所设置的栈空间大小越大那么再次建立线程的时候就会越容易引起耗尽剩余的内存（从而引起OOM异常）。
所以在多线程 环境之中，如果是建立多线程导致的内存溢出异常，在没有减少线程数或者提供更大的内存的情况下，就需要通过减小最大堆内存和减小每个线程的栈容量的方式来创建更多的线程。