一般我们写代码，就是写数据、指令、控制。
数据：类里的成员变量
指令：int a = 10
控制： return

1.我们可以看到虚拟机栈，每一个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用。

2.运行时常量池是包含在非堆里，也就方法区。

线程在cpu上执行，cpu在执行时是用时间片，时间片是抢占式的。线程是可以被挂起的，

当前的指令不一定就一定是一次性运行完的，所以需要找个地方把指令存起来。

每个线程都有一个自己的程序计数器。

方法运行时的基础数据结构，每个方法运行时都会创建一个栈帧。通俗的个人理解，
可以认为栈帧就是栈里的一个元素，当前栈帧就是顶部的要出栈的元素，这个元素是一个数据
结构，存储局部变量表，操作数栈，动态链接，出口等信息。

private Object obj = new Object();

public void print()
{
    int a = 10;
    int sum = a + 10;

    Object object = obj; 

    return;

    //todo 
}

1.jdk1.8完全废弃了永久代概念，改用本地内存中实现的元空间。
2.取消永久代，方法区存放于元空间(Metaspace)。
3.元空间仍然与堆不相连，但与堆共享物理内存，逻辑上可认为在堆中 ，但是实际上我们说的堆指的是用于存放java对象的那些空间。
4.元空间并不在虚拟机中,而是使用本地内存。

1.永久代有-XX：MaxPermSize上限，容易遇到内存溢出。而元空间使用的是直接内存，
受本机可用内存的限制，只要没有触碰到进程可用的内存上限理论上就不会有问题。

2.直接内存，JVM将会在IO操作上具有更高的性能，因为它直接作用于本地系统的IO操作。
而非直接内存，也就是堆内存中的数据，如果要作IO操作，会先复制到直接内存，再利用本地IO处理。

参考链接：
https://blog.csdn.net/qq_26222859/article/details/73135660

1.全局字符串池（string pool也有叫做string literal pool）
全局字符串池里的内容是在类加载完成，经过验证，准备阶段之后在堆中生成字符串对象实例，然后将该字符串对象实例的引用值存到string pool中（记住：string pool中存的是引用值而不是具体的实例对象，具体的实例对象是在堆中开辟的一块空间存放的。）。

在HotSpot VM里实现的string pool功能的是一个StringTable类，它是一个哈希表，里面存的是驻留字符串(也就是我们常说的用双引号括起来的)的引用（而不是驻留字符串实例本身），也就是说在堆中的某些字符串实例被这个StringTable引用之后就等同被赋予了”驻留字符串”的身份。

这个StringTable在每个HotSpot VM的实例只有一份，被所有的类共享。


2.class文件常量池（class constant pool）
我们都知道，class文件中除了包含类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池(constant pool table)，用于存放编译器生成的各种字面量(Literal)和符号引用(Symbolic References)。

字面量就是我们所说的常量概念，如文本字符串、被声明为final的常量值等。

符号引用是一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可（它与直接引用区分一下，直接引用一般是指向方法区的本地指针，相对偏移量或是一个能间接定位到目标的句柄）。


3.运行时常量池（runtime constant pool）
jvm在执行某个类的时候，必须经过加载、连接、初始化，而连接又包括验证、准备、解析三个阶段。

而当类加载到内存中后，jvm就会将class常量池中的内容存放到运行时常量池中，由此可知，运行时常量池也是每个类都有一个。在上面我也说了，class常量池中存的是字面量和符号引用，也就是说他们存的并不是对象的实例，而是对象的符号引用值。

而经过解析（resolve）之后，也就是把符号引用替换为直接引用，解析的过程会去查询全局字符串池，也就是我们上面所说的StringTable，以保证运行时常量池所引用的字符串与全局字符串池中所引用的是一致的。

从右上图的堆内存结构图1.7和1.8对比可以看出：
1.jdk1.7有永久代，并且永久代是位于蓝色区域的方法区。

2.jdk1.8没有了永久代，取而代之的是元空间，同时元空间不属于方法区也不在堆，
但与堆共享物理内存，逻辑上可认为在堆中，元空间使用的是本地内存（Native Memory）

Java对象实例和数组元素都是在堆上分配内存的吗？

不一定，满足特定条件时，它们可以在（虚拟机）栈上分配内存

参考链接：
https://blog.csdn.net/mrchaochao/article/details/106668122

1.加锁进行同步处理

2.TLAB线程本地分配缓存（常称栈上分配）

对象头存储是与对象自生定义的数据无关的额外信息：
    .对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁...
    .类型指针，虚拟机通过指针来确定这个对象是哪个类的实例。

对象真正存储的有效数据，也就是我们写代码中定义的各种字段，父类和子类定义都要记录。

HotSpot VM 的要求对象起始地址必须是8字节的整数倍，当实例数据部分没有对齐，

就需要对齐填充补全，没有特别意义，不一定存在。

java程序需要通过栈上的reference数据来操作堆上的具体对象。

两种主流：
    .使用句柄
    .直接指针

使用句柄，java堆中划分出一块内存来作为句柄池，reference中存储的是稳定的句柄地址，对象被垃圾回收，只会改变句柄中的实例数据指针，

而reference本身不用修改。

使用直接指针访问，java堆对象布局需要考虑如何放置访问类型数据的相关信息。

速度更快，节省一次指针定位的开销。HotSpot采用的是指针访问。

.虚拟机栈中本地变量表引用的对象
.方法区中：
       类静态变量引用的对象
       常量引用的对象
.本地方法栈中JNI引用的对象

虚拟机栈中本地变量表引用的对象在线程中是保持活跃性，不能一下子回收，

private Object obj = new Object();

public void print()
{
    int a = 10;
    int sum = a + 10;

    Object object = obj; 

    return;

    //todo 
}

通俗的讲，调用方法时你把方法内引用的对象给回收了，那我还怎么执行方法。

例如上面的objectd对象，我运行方法时发行被回收了，那我就没法运行了。

类静态变量引用的对象被他们的类持有，类一般不回轻易回收，类本身可以被垃圾收集，这将删除所有引用的静态变量。所以类静态变量引用的对象是GC根。

常量引用个人理解，常量是一直要使用的不能够轻易回收，所以也能成为GC根。

方法区1.7以前也有成为永久代，所以不进行垃圾回收。         

JNI引用是本机代码在JNI调用中创建的Java对象。这样创建的对象会被特殊处理，因为JVM不知道本机代码是否引用了它。这些对象表示一种非常特殊的GC根形式。

Options that begin with -X are non-standard (not guaranteed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the JDK.

Options that are specified with -XX are not stable and are subject to change without notice.

-Xms20M  starting 起始堆大小
-Xmx     max  最大的大小
-Xmn     new  堆的新生代大小

-XX:SurvivorRatio=8

8:1:1

1.经过统计，每次gc会有90%的对象被回收，所以要预留空间去保存剩下的10%。
eden区设置的大，survivor区设置的小。

2.设置两个Survivor区最大的好处就是解决了碎片化。

假设刚刚新建的对象在Eden中，一旦Eden满了，触发一次Minor GC，Eden中的存活对象就会被移动到Survivor区。这样继续循环下去，
下一次Eden满了的时候，问题来了，此时进行Minor GC，Eden和Survivor各有一些存活对象，如果此时把Eden区的存活对象硬放到Survivor区，
很明显这两部分对象所占有的内存是不连续的，也就导致了内存碎片化。内存产生碎片化后，堆中没有足够大的连续内存空间，会导致内存不可用，浪费内存。

设置两个Survivor，第一次eden满了，触发一次minor gc，存活的对象往s1移动。第二次eden满了，垃圾回收的是整个年轻代（包括s1和s2，只是现在s2是空的）。
此时存活的对象，全部往s2移动，清空s1。下一次再gc, 存活的对象全部往s1移动，如此反复。
解决了空间内存碎片化，同时，对象可以较长的时间呆在新生代，直到达到对象的年龄设置的阈值才往老年代移动。

所以新生代会有10%的内存空间被浪费。

另外，如果存活对象在survivor区放不下，将触发分配担保机制，进入老年代。

1.OopMap 用于枚举 GC Roots。

2.可达性分析，需要先找到GC Roots根节点，根节点往往存在于栈帧中的本地变量表或者全局性的引用（常量或类静态属性），
引用非常多，不可能每次都逐一检查，例如：如果需要知道栈帧中的本地变量表里有哪些引用，不可能逐一扫描方法区。

3.OopMap是一个数据结构，用于记录java栈上的对象引用，它的主要目的是在Java栈上查找GC根，
并在对象在堆中移动时更新引用，减少查找GC根节点时间。

这两篇文章可以学习下：

什么是oopMap?:
https://stackoverflow.com/questions/26029764/what-does-oop-maps-means-in-hotspot-vm-exactly.

R大：
https://www.iteye.com/blog/rednaxelafx-1044951

即程序执行时并非在所有的地方都能停顿下来GC，只有在到达安全点时才能暂停。
   .抢先式中断
   .主动式中断