一、运行时数据区域
Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。
- JDK1.8 运行时数据区的划分，它包括：
1.1 程序计数器、Java虚拟机栈、本地方法栈
1.2 堆、元空间、直接内存
- Java运行时内存空间可以分为两种，线程私有和线程共享
线程私有：Java虚拟机栈、本地方法栈、程序计数器
线程共享：堆、元空间、直接内存
二、Java堆Heap的结构
Java堆内存概述
Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代：再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。
Java堆的结构
jvm启动conf中配置参数： -XX:NewRatio=4 -XX:SurvivorRatio=2
- 年轻代用来存放新分配的对象，年轻代中经过垃圾回收，没有回收掉的对象，被复制到老年代；
- 老年代存储对象比年轻代存储对象的年龄大得多，老年代存储一些大对象；
- 整个堆大小 = 年轻代 + 老年代；
- 年轻代 = Eden + S0 + S1；
- 从 JDK1.8 开始，元空间（MetaSpace）用来存放Class、Method 等元信息的区域，元空间并不在虚拟机里面，而是直接使用本地内存；
Java堆的参数
-Xms：初始化堆大小，默认物理内存的 1/64
-Xmx：最大堆大小，默认物理内存的 1/4
-Xmn：年轻代大小，默认整个堆的 3/8
-XX：+HeapDumpOnOutOfMemoryError：OOM时导出堆到文件
-XX：+HeapDumpPath：导出 OOM 的路径
-XX: NewRatio：老年代与年轻代的比值，如果 xms=xmx，且设置了 xmn 的情况，该参数不用设置
-XX: SurvivorRatio：Eden区和Survivor区的大小比值，设置为8，则两个 Survivor 区与一个Eden区的比值为 2:8，一个 Survivor 占整个新生的 1/10
-XX:OnOutOfMemoryError：在OOM时，执行一个脚本
-Xss：通常只有几百k，决定了函数调用的深度
解释：
-XX:NewRatio=4 设置老年代OldGen和年轻代YongGen比值 4 : 1，OldGen：4/5，YongGen：1/5
-XX:SurvivorRatio=2 设置Eden和Survivor比值 2 : 1，Eden：2/4，S0：1/4，S1：1/4
元空间的参数
-XX:MetaspaceSize：初始空间大小
-XX:MaxMetaspaceSize：最大空间，默认是没有限制的
-XX:MinMetaspaceFreeRatio：在GC之后，最小的Metaspace 剩余空间容量的百分比
-XX:MaxMetaspaceFreeRatio：在GC之后，最大的Metaspace剩余空间容量的百分比
conf文件配置示例：
JAVA_OPTS="-Xms512m -Xmx512m -XX:SurvivorRatio=2 -XX:NewRatio=4 -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/yuanben/dumps/ -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/yuanben/gclog/gclog -Dfile.encoding=UTF-8"
查看各个代的内存配置和使用情况：jmap -heap pid
MaxHeapSize = 512M，OldZize = 410M(512✖️0.8)，NewSize = 102M(512✖️0.2) = Eden(51M) + S0(25.5M) + S1(25.5M)
垃圾回收
新生代 = 1 个 Eden 区 + 2 个 Survivor 区（From Survivor, ToSurvivor）
绝大部分对象在 Eden 区生成，当 Eden 区装填满的时候，会触发 Young Garbage Collection, 即 YGC。大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收时，没有被引用的对象则直接回收，如果对象还存活，则会进入s1("To")，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。经过这次GC后，Eden区和"From"区已经被清空。这个时候，"From"和"To"会交换他们的角色，也就是新的"To"就是上次GC前的“From”，新的"From"就是上次GC前的"To"。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，"To"区被填满之后，会将所有对象移动到老年代中。
-
堆内存分配策略
堆内存常见分配策略.png
3.1 对象优先在 eden 区分配
大多数情况下，对象在新生代中 eden 区分配。当 eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。
新生代 GC（Minor GC）:指发生新生代的的垃圾收集动作，Minor GC 非常频繁，回收速度一般也比较快。
老年代 GC（Major GC/Full GC）:指发生在老年代的 GC，出现了 Major GC 经常会伴随至少一次的 Minor GC（并非绝对），Major GC 的速度一般会比 Minor GC 的慢 10 倍以上。
3.2 大对象直接进入老年代
大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
3.3 长期存活的对象将进入老年代
对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间中，并将对象年龄设为 1。对象在 Survivor 中每熬过一次 MinorGC，年龄就增加 1岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。
垃圾收集算法
- 标记/清除算法
- 复制算法
- 标记/整理算法
新生代采用复制算法，老年代采用标记/清除算法或标记/整理算法；
原理：在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记一整理”算法来进行回收；
JVM这篇文章中使用了图文结合分析了垃圾回收算法原理，比较易懂，推荐
垃圾收集器
- Serial 收集器
- ParNew 收集器
- Parallel Scavenge 收集器
- Serial Old 收集器
- Parallel Old 收集器
- CMS 收集器
- G1 收集器
指标解释
jstat -gc 用于显示堆内存和垃圾收集的信息，例如：
S0C、S1C、S0U、S1U：分别展示新生代中第一个(s0)和第二个(s1) Survivor Space 的当前容量(Capacity)和已使用大小(Used)；
EC、EU：表示新生代中 Eden Space 的当前容量和已使用大小；
OC、OU：表示老年代空间的当前容量和已使用大小；
YGC、YGT、FGC、FGCT、GCT：分别表示新生代垃圾回收次数、新生代垃圾回收耗时、老年代垃圾回收次数、老年代垃圾回收耗时、总垃圾回收耗时。
S0C、S1C、EC、SC、OC、MC、CCSC：表示 Survivor 0、Survivor 1、Eden Space、Permanent Space、老年代、元空间、压缩类空间的当前容量；
监视java进程gc情况：
jstat -gcutil pid 3000 (百分比)
存储GC日志
conf文件配置：-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/xxx/gclog/gclog
- 生成gc日志；
- 上传gc日志文件，gceasy检测gc日志； gceasy官网
思考：如果服务在一定时间内FullGC次数过高，但是有没有OutOfMemory，我们可以利用FullGC的时间节点，在打印日志中查找调用了哪些接口，再结合代码，排查一些潜在的大中对象，解决一些潜在的内存溢出风险；
存储抛出内存dump文件
jvm配置内存溢出时，抛出内存dump文件
conf文件配置：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/xxx/dumps/
1.服务挂了，日志中出现java.lang.OutOfMemoryError: GC overhead limit exceeded；
2.使用MAT工具分析dump文件，定位问题；
jvisualvm工具
默认路径：C:\Program Files\Java\jdk1.8.0_181\bin\jvisualvm.exe
Java VisualVM 提供内存和 CPU 分析，堆转储分析，内存泄漏检测等；
思考：
1.可以利用jvisualvm工具，排查一些隐患问题。我们启动本地服务（前后端），使用系统功能，同时监测是否存在消耗了大量的内存；
2.如果通过日志发现了可疑的接口或功能（查询数据量过大等），我们可以本地复现该功能或接口是否存在大对象；
参考和学习文章：
JVM
JVM要点
深入理解JVM-内存模型（jmm）和GC
如何进行GC调优
JVM GC日志文件分析
查看JVM参数、内存使用情况及分析
每天100w次登陆请求, 8G 内存该如何设置JVM参数？
