思路：Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，
那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。
jvm参数：-Xmx 20M, -Xms 20M,避免堆自动扩展。
案列代码：
导致垃圾收集器无法自动回收他们的
内存溢出：
说明：如果不存在泄漏，换句话说，就是内存中的对象确实还必须存活着，
1.从代码上检查虚拟机的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大
2.从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少的程序运行期的内存消耗。
2.虚拟机栈和本地方法栈溢出
1.由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，
2.因此，对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的，
3.栈容量只由-Xss参数设定。
4.关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：
4.1如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
4.2如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。
5.这里把异常分成两种情况，看似更加严谨，但却存在着一些互相重叠的地方：
当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，
其本质上只是对同一件事情的两种描述而已。
类比：一个袋子里面装苹果，当袋子里面无法在装苹果时，到底是袋子太小，还是苹果太大；
装的个数代表栈的深度，苹果大小代表局部变量表的大小
6.在实验中，将实验范围限制于单线程中的操作，
尝试了下面两种方法均无法让虚拟机产生OutOfMemoryError异常，
尝试的结果都是获得StackOverflowError异常
6.1.使用-Xss参数减少栈内存容量。结果：抛出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小。
代码：
1 package com.wfd360.demo01; 2 3 /** 4 * @Copyright (C) 5 * @Author: LI DONG PING 6 * @Date: 2019-07-15 17:17 7 * @Description: 栈内存溢出测试 8 * <p> 9 * 测试代码设计思路 10 * 修改默认堆栈大小后,利用递归调用一个方法,达到栈深度过大的异常目的,同时在递归调用过程中记录调用此次,得出最大深度的数据 11 * jvm参数 12 * -Xss 180k:设置每个线程的堆栈大小(最小180k),默认是1M 13 */ 14 public class TestStackOverflowErrorDemo { 15 //栈深度统计值 16 private int stackLength = 1; 17 18 /** 19 * 递归方法,导致栈深度过大异常 20 */ 21 public void stackLeak() { 22 stackLength++; 23 stackLeak(); 24 } 25 26 /** 27 * 启动方法 28 * 测试结果:当-Xss 180k为180k时,stackLength~=1544,随着-Xss参数变大时stackLength值随之变大 29 * @param args 30 */ 31 public static void main(String[] args) { 32 TestStackOverflowErrorDemo demo = new TestStackOverflowErrorDemo(); 33 try { 34 demo.stackLeak(); 35 } catch (Throwable e) { 36 System.out.println("当前栈深度:stackLength=" + demo.stackLength); 37 e.printStackTrace(); 38 } 39 } 40 }