前言
由于先前也遇到过一些性能问题，OOM算是其中的一大类了。因此也对jvm产生了一些兴趣。自己对jvm略做了些研究。后续继续补充。
从oom引申出去
既然说到oom，首先需要知道oom的原因是什么。为啥会oom嘞？
oom的定义是outofmemory。当内存想为对象分配内存的时候，发现内存不足以去分配内存，或者gc的时候发现没有可以被回收的对象或回收后的内存也不足以为对象分配内存。
因此抛出这个java异常。
oom
可以分为以下四类
1.堆溢出：java堆
2.栈溢出：虚拟机栈和本地方法栈
3.方法区内存溢出：方法区和内存时常量池
4.本机直接内存溢出
因此，需要先了解堆，栈，方法区都是些啥
运行时数据区
先上图
程序计数器：当前线程所执行的字节码的行号指示器。
java虚拟机的多线程是通过轮流切换线程，并为线程分配执行时间片去运行来执行的。每个线程都有一个自己的程序计数器。我觉得这个可以这么理解：当一个线程在运行的时候，每执行一步程序计数器都会有个记录，记录当前执行到哪一步了。如果线程被切换后又切换回来，那么通过程序计数器就能知道执行到哪一步了，然后继续向下执行。
虚拟机栈：每个线程都会有一个虚拟机栈。虚拟机栈描述的是java方法执行的内存模型。因为线程执行的过程就是执行线程里的一个个方法，而每个方法都会创建对应自己的栈帧。
栈帧里存的内容如下：
- 局部变量表：存放了各种编译期可知基本数据类型，对象引用（引用指针或句柄）
- 操作数栈：大多数指令都要从这里弹出数据，执行运算，然后把结果压回操作数栈
- 动态链接
- 方法出口
64位的long和都double类型数据占用2个局部变量空间，其他数据类型占用一个，也就是每个局部变量空间为32位。
在这个地方，如果线程请求的深度大于虚拟机允许的深度，会抛出StackOverflowError.因为jvm分配给虚拟机栈的内存是有限的，而每个方法都会有对应的栈帧压入到栈中，如果调用方法过多，那么栈满了自然也就溢出了。（可能的场景：死循环代码，大量递归调用，那排查问题的时候也可以由此有一个思路）。可以通过调整-Xss去调整栈大小。
大部分java虚拟机允许动态扩展，但如果扩展的时候也申请不到足够内存时，就会报OOM了。
本地方法栈：和虚拟机发挥作用相似。区别：虚拟机栈为虚拟机执行java方法服务，本地方法栈为虚拟机使用的Native方法服务。Native Method就是一个java调用非java代码的接口，Native方法的实现由非java语言实现。读者不用纠结，略作了解即可。
堆：堆是所有线程共享的一块内存，作用是存放对象实例。堆可以分为新生代和老年代。新生代里还可细分为Eden,From survivor,To survivor等空间。后面讲述GC过程时会说到。
方法区：也是所有线程共享的一块内存，存放被虚拟机加载的类信息，常量，静态变量，编译器编译后的代码。也就是常说的永久代。
永久代的大小可以用-XX:MaxPermSize去设置。
运行时常量池：方法区的一部分。存放编译期生成的各种字面量和符号引用。字面量就是指这个量本身。比如字面量2，就是指2.
运行时常量池有一个重要特性就是动态性。常量不一定只有编译期才能产生，运行期间也可能将新的常量放入常量池。详情可见String类的
intern()方法。
此处推荐这篇博客，对intern()方法介绍的挺清楚的。
https://blog.csdn.net/soonfly...
直接内存：它不是虚拟机运行时数据区的一部分，但也频繁的被使用。直接内存不会受到java堆大小的限制，但是会受到本机总内存的限制。
GC过程
GC分为新生代GC（minor gc）和老年代GC(full gc)。新生代GC的频率远远高于老年代。而且
新生代GC的速度会比老年代的GC速度快10倍以上。根源在于新生代和老年代使用的GC算法不同。读者们可以去仔细思考下(答案文中有，哈哈)。新生代/老年代大小默认为1：2。
新生代GC过程：
新生代里可细分为Eden,From survivor,To survivor等空间。当我们需要给对象分配内存的时候，首先我们会在Eden区为对象分配内存，当Eden区内存不足时，会发生minor gc，此时会把仍然存活的对象放到From survivor，并给对象标记存活次数1；然后当Eden区再次被用完后，对Eden区和From survivor区筛选出存活的对象，放到To survivor区，清空Eden区和From survivor区，存活次数加1，之前存活的就是2了。
以此类推，默认是当存活次数到达15次（可配置）的时候，把这个对象存入老年代中。同时也可以看到，From survivor,To survivor区始终有一个是空置的。所以新生代使用的只有9/10的空间。
然而大家可以思考一下。Eden区和survivor区的大小为8：1，那么发生minor gc后如果存活的对象
的大小比survivor区还要大。这个时候会怎么处理？
这里需要引入一个叫“内存分配担保机制”的概念。就是当存活的对象连survivor区都放不下的时候，这部分放不下的对象会直接进入老年代。老年代是担保人。老年代进行担保，前提是老年代还有剩余空间。但是每次存活下来的对象大小是不确定的。所以只好取之前每次存储到老年代的对象大小的平均值。如果大于平均值，那么直接full gc。但是为了避免频繁full gc，仍然会开启handlepromotionfailure配置。如下图
老年代GC过程：
老年代采用了标记整理，标记清楚的算法。老年代会把仍然存活的对象都整理统一放到一边。整理完成后就会清楚掉边界外的对象。这样就避免了产生大量的内存碎片的问题。但是整理算法相较于新生代采用的复制算法，复杂程度肯定更高。这也导致了full gc的速度要远远慢于minor gc。
文中若有考虑不周或者错误，欢迎大家支招指正。一起学习交流。betterFighter!
