JVM：内存模型、内存分配机制、内存分配冲突、JVM垃圾标记算法、JVM1.8增加元数据区缘由

JVM 内存模型

线程共享区：

堆

堆内存有一部分空间在jdk1.8后用作为常量池，其余的空间内存如何划分都将以垃圾回收器来进行划分，例如常见的parnew、cms等年轻代老年代的垃圾回收器，会将堆内存划分为老年代与年轻代，年轻代又分为两个幸存区和一个eden区，而“非分代年龄垃圾收集器”例如G1、ZGC等垃圾收集器，将整个堆内存划分2048个region，每一个region存储着一样类型的对象，类型又分为了幸存区、eden区、老年代、大对象等四类。

方法区(元空间)

jdk1.8 jvm将方法区以元空间作为具体的实现，主要存储类的元数据，元空间的内存不再由jvm分配，而是使用直接内存。

线程私有区

线程栈

线程栈中，存储的单元为栈幁，每一个栈幁就是一个方法，栈幁的结构如下：

1、方法出口

方法出口就是返回地址，无论是正常执行完毕还是异常结束，都需要返回到方法调用的地方， 简而言之方法出口就是记录了方法调用的位置。

2、操作数栈

方法中局部变量的字面量就存储在这块，例如int a=10；

3、局部变量表

在局部变量表中存储着各类变量，例如基本类型的变量、引用类型的变量，等到操作数栈中的数据出栈时将会把这些数据以及引用赋值给局部变量表中的变量。

4、动态链接

动态链接就是当前栈幁的方法在运行时常量池的引用。

本地方法栈

执行native 方法压栈出栈是通过本地方法栈完成的，内部结构仍然是以栈幁为单元。

程序计数器

在方法的压栈出栈、异常情况、上下文切换等情况时都必须通过程序计数器去记录代码的执行情况，程序计数器是线程私有的。

为什么JDK1.8会增加对方法区的实现/为什么JDK1.8将方法区更改为元数据区

移除永久代是为融合HotSpot JVM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代

现实使用中存在问题：方法区存储类的元数据信息，我们不清楚一个程序到底有多少类需要被加载，且方法区位于JVM内存，我们不清楚需要给方法区分配多大内存，太小容易PermGen OOM，太大，在触发Full GC时又极其影响性能，同时还存在一些内存泄露的问题

JVM内存分配机制

指针碰撞

指针碰撞适用于parnew等类型的垃圾回收器，在指针碰撞的内存分配机制中，内存分为两大块左边是已使用的，右边是空闲内存，在已使用的内存与空闲内存之间存在一个指针，等到需要分配存储时只需要将指针向右移动，完成内存分配。

空闲列表

实时上内存不是一块完整的，非空闲内存空间与空闲内存扣减相互交错，jvm维护了一个列表，列表中记录了内存中所有的空闲内存，等到分配内存时找一块相应大小的内存空间即可。

内存分配冲突

CAS乐观锁解决

通过cas自旋来解决并发场景下内存分配冲突问题，大概思路为，内存分配时获取到指针的指向地址A，等到分配时判断当前指针位置是否为当初的地址A若为地址A则分配成功，若不相同则重新获取指针地址执行上述操作。

TLAB解决

每一个线程都有对应的TLAB区域，首先分配内存时判断对象是否可以直接在栈上分配，若不可以则判断TLAB是否能放的下该对象，若放不下则判断是否直接进入老年代(大对象直接进入老年代)，若不进入老年代则放入eden区。

JVM垃圾标记算法

对象被回收前则需要进行算法计算，判断对象是否为垃圾对象，对于对象的存活判断的算法常见的有：

1、引用计数算法

每个对象都有计数属性，关联该对象时则加一，引用关联失效时减一。
缺陷：算法复杂度较大，需要在每一个对象都要有计数属性，且无法解决循环依赖的问题，例如a 引用b 然后b引用a，在java中没有采用该算法。

2、可达性算法

以GCROOT为根从上至下搜索对象之间的引用关联，判断对象是否可达，若对象没有任何关联则认为不可达意味着就是垃圾对象。