jvm内存模型
这是java堆和方法区内存模型
参考：https://www.cnblogs.com/honey01/p/9475726.html
Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种：Minor GC、FullGC ( 或称为 Major GC )。
Minor GC 是发生在新生代中的垃圾收集动作，所采用的是复制算法。
新生代几乎是所有 Java 对象出生的地方，即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部
分对象通常不需长久存活，具有朝生夕灭的性质。
当一个对象被判定为 "死亡" 的时候，GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的
频繁区域。
当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如
果对象还存活，并且能够被另外一块 Survivor 区域所容纳( 上面已经假设为 from 区域，这里应为 to 区域，
即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对
象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即
from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年
龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定
)，这些对象就会成为老年代。
但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。
Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。
现实的生活中，老年代的人通常会比新生代的人"早死"。堆内存中的老年代(Old)不同于这个，老年代里面的对象
几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 "死掉" 了的。因此，Full GC 发生的次数不
会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。
另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象
分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。
典型设置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xms 为jvm启动时分配的内存，比如-Xms200m，表示分配200M -Xmx 为jvm运行过程中分配的最大内存，比如-Xms500m，表示jvm进程最多只能够占用500M内存
-Xmn 堆内新生代的大小，剩下德是老年代。 -Xss 为jvm启动的每个线程分配的内存大小，默认JDK1.4中是256K，JDK1.5+中是1M
到了 java 8的时候，方法区（永久代）被元空间取代，需要注意：
1.元空间占用的直接内存，不在jvm内。
2.以前的方法区中的运行时常量池被放到堆中了，变成这样：
垃圾回收
Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；
栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。
而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存，后续讨论中的“内存”分配与回收也仅指这一部分内存。
对象死亡判断
引用计数算法
给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。作者面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案&oq=给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。作者面试过很多的应届生和一些有多年工作经验的开发人员，他们对于这个问题给予的都是这个答案。
可达性分析算法
在主流的商用程序语言（ Java、 C#， 甚至包括前面提到的古老的Lisp） 的主流实现中，都是称通过可达性分析（ Reachability Analysis） 来判定对象是否存活的。 这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点， 从这些节点开始向下搜索， 搜索所走过的路径称为引用链（ Reference Chain） ， 当一个对象到GC Roots没有任何引用链相连（ 用图论的话来说， 就是从GC Roots到这个对象不可达） 时， 则证明此对象是不可用的。 如图3-1所示， 对象object 5、 object 6、 object 7虽然互相有关联， 但是它们到GC Roots是不可达的， 所以它们将会被判定为是可回收的对象。
可作为GC Roots的对象包括下面几种：
1.虚拟机栈（ 栈帧中的本地变量表） 中引用的对象。
2.方法区中类静态属性引用的对象。
3.方法区中常量引用的对象。
4.本地方法栈中JNI（ 即一般说的Native方法） 引用的对象。
垃圾收集器
JVM提供了4种GC回收器：
- 串行回收器（ SerialGC） 。
- 并行回收器（ ParallelGC） ， 主要针对年轻带进行优化（ JDK 8默认策略） 。
- 并发回收器（ ConcMarkSweepGC， 简称CMS） ， 主要针对年老带进行优化。
- G1GC回收器， 主要针对大内存（ 32GB以上才叫大内存） 进行优化。
详细可以参考：https://www.cnblogs.com/baizhanshi/p/6140925.html?utm_source=itdadao&utm_medium=referral
内存配置/垃圾收集参数可以参考官网：
https://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
other：
还是别人的笔记比较详细：