大学期间必须知道的JVM知识

小鱼儿 2023-01-12 13:00 164阅读 0赞

> 真正没有资格谈明天的人，是那个不懂得珍惜今日的人。  
> 你好，我是梦阳辰，期待与你相遇！

### 文章目录 ###

*  概述
 *  01.类装载器ClassLoader
 *   *  类装载器的种类
     *  类加载器的双亲委派机制
     *  执行引擎
 *  02.Native Method Stack(本地方法栈）
 *  03.Native Interface本地方法接口
 *  04.程序计数器
 *  05.Method Area方法区
 *  06.Heap堆
 *  07.堆参数调优
 *   *  引用计数法
     *  复制算法
     *  标记清除算法（Mark-Sweep)
     *  标记压缩算法(Mark-ComPact)
 *  08.JMM

# 概述 #

它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。  
JVM有自己完善的硬件架构，如处理器、堆栈、寄存器等，还具有相应的指令系统。Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关，实现跨平台。所以，JAVA虚拟机JVM是属于JRE的，而现在我们安装JDK时也附带安装了JRE(当然也可以单独安装JRE)。

Java虚拟机主要分为五大模块：类装载器子系统、运行时数据区、执行引擎、本地方法接口和垃圾收集模块。  
JVM是运行在操作系统之上的,它与硬件没有直接的交互  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70]  
**JVM体系结构概览**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 1]  
亮色区域：  
线程共享

存在垃圾回收

# 01.类装载器ClassLoader #

负责**加载class文件**，class文件在文件开头**有特定的文件标示**，  
将class文件字节码内容加载到内存中，并将这些内容转换成**方法区**中的运行时数据结构并且ClassLoader**只负责class文件的加载**，至于它是否可以运行，则由Execution Engine决定。

类装载器类似于快递公司。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 2]  
\*\*特定标识：\*\*cafe babe  
![在这里插入图片描述][20210128160550627.png]

## 类装载器的种类 ##

虚拟机自带的加载器

启动类加载器（Bootstrap)
    C++扩展类加载器(Extension）
    ava应用程序类加载器（AppClassLoader）Java也叫系统类加载器，加载当前应用的classpath的所有类

用户自定义加载器

Java.lang. ClassLoader的子类，用户可以定制类的加载方式

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 3]

## 类加载器的双亲委派机制 ##

当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求**委派给父类**去完成，每一个**层次类加载器都是如此**，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载。

采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。

砂箱安全机制  
保证你写的代码不会污染java内置的代码.

## 执行引擎 ##

主要的执行技术有:解释，即时编译，自适应优化、芯片级直接执行其中解释属于第一代JVM，即时编译JIT属于第二代JVM，自适应优化（目前Sun的HotspotJVM采用这种技术）则吸取第一代JVM和第二代JVM的经验，采用两者结合的方式 。

自适应优化：开始对所有的代码都采取解释执行的方式，并监视代码执行情况，然后对那些经常调用的方法启动一个后台线程，将其编译为本地代码，并进行仔细优化。若方法不再频繁使用，则取消编译过的代码，仍对其进行解释执行。

**Execution Engine执行引擎负责解释命令，提交操作系统执行**。

# 02.Native Method Stack(本地方法栈） #

它的具体做法是Native Method Stack中登记native方法，在ExecutionEngine执行时加载本地方法库。

# 03.Native Interface本地方法接口 #

本地接口的作用是融合不同的编程语言为Java所用，它的初  
衷是融合C/C++程序，Java诞生的时候是C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。

目前该方法使用的越来越少了，除非是与硬件相关的应用，比  
如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用  
中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等，不多做介绍。

# 04.程序计数器 #

pc寄存器

每个线程都有一个程序计数器，是线程私有的,就是一个指针，  
指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码)，由**执行引擎**读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

这块内存区域很小，它是当前线程**所执行的字节码的行号指示器**，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。如果执行的是一个Native方法，那这个计数器是空的。

用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误。

# 05.Method Area方法区 #

线程共享

存在垃圾回收

**方法区：**  
供各线程共享的运行时内存区域。**它存储了每一个类的结构信息**（类模板），例如运行时常量池（Runtime Constant Pool)、字段和方法数据、构造函数和普通方法的字节码内容。上面讲的是规范，在不同虚拟机里头实现是不一样的，最典型的就是永久代(PermGen space)和元空间(Metaspace)。

But

实例变量存在堆内存中,和方法区无关。

stack  
栈管运行，堆管存储

栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它  
的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

**栈存储什么?**  
栈帧中主要保存3类数据:

本地变量（Local Variables）:输入参数和输出参数以及方法内的变量;

栈操作（Operand Stack）:记录出栈、入栈的操作;

栈帧数据（Frame Data）:包括类文件、方法等等。

**栈运行原理:**  
栈中的数据都是以栈帧(Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，  
A方法又调用了B方法，于是产生栈帧F2也被压入栈，  
B方法又调用了C方法，于是产生栈帧F3也被压入栈，………  
执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……  
遵循“先进后出”/“后进先出”原则。

每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完毕的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。栈的大小和具体JVM的实现有关，通常在256K~756K之间,与等于1Mb左右。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 4]

每执行一个方法都会产生一个栈帧，保存到栈(后进先出)的顶部,顶部栈就是当前的方法，该方法执行完毕后会自动将此栈帧出栈。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 5]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 6]

HotSpot是使用指针的方式来访问对象:Java堆中会存放访问类**的元数据**的地址，reference存储的就直接是对象的地址

# 06.Heap堆 #

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。

类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分:

Young Generation Space 新生区  Young/New
    Tenure generation space养老区  old/ Tenure
    Permanent Space  永久区  Perm

Java7之前  
一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。  
类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 7]  
o1d养老区，满了，开启FuliGC = FGC

Full GC 多次，发现养老区空间没办法腾出来，OOM

**Java8为元空间，不是永久代**

物理上：新生+养老

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应  
用，最后被垃圾回收器收集，结束生命。新生区又分为两部分:伊甸区(Eden space）和幸存者区(Survivor pace），所有的类都是在伊甸区被new出来的。幸存区有两个:0区(Survivor 0 space）和1区  
(Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区。若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢?再移动到养老区。若养老区也满了，那么这个时候将产生MajiorGC (Eul1GC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryExror”。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。  
原因有二:  
(1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。(2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 8]  
from区和to区，他们的位置和名分，不是固定的，每次GC后会交换GC之后有交换，谁空谁是to

**MinorGC的过程(复制>清空>互换)**

1: eden、SurvivorFrom复制到Survivorlo，年龄+1

首先，当Eden区满的时候会触发第一次GC,把还活着的对象拷贝到SurvivorFrom区，当Eden区再次触发GC的时候会扫描Eden区和From区域,对这两个区域进行垃圾回收，经过这次回收后还存活的对象,则直接复制到To区域(如果有对象的年龄已经达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1

2:清空eden、SurvivorFrom  
然后，清空Eden和SurvivorFrom中的对象，也即复制之后有交换，谁空谁是to

3: SurvivorTo和 SurvivorErom互换  
最后，SurvivorTo和SurvivorFrom互换，原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From和To区域中复制来复制去,如此交换15次(由VM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 9]  
实际而言，方法区(Method Area）和堆一样，是各个线程共享的内  
存区域，它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。

对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代  
Parmanent Gen)”，但严格本质上说两者不同，或者说使用永久代来实现方去区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的反本中，已经将原本放在永久代的字符串常量池移走。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 10]  
**永久区(java7之前有)**  
永久存储区是一个常驻内存区域，用于存放JDK自身所携带的  
Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。

# 07.堆参数调优 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 11]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 12]  
在Java8中，永久代已经被移除，被一个称为元空间的区域所取代。元空间的本质和永久代类似。

**元空间与永久代之间最大的区别在于:**  
永久带使用的JVM的堆内存，但是java8以后的元空间并不在虚拟机中而是使用本机物理内存。

因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入native memory,字符串池和类的静态变量放入java堆中，这样可以加载多少类的元数据就不再由MaxPermsize控制,而由系统的实际可用空间来控制。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 13]  
GC:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 14]  
FullGC:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 15]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 16]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 17]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 18]  
JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。

因此GC按照回收的区域又分了两种类型，一种是普通GC(minor GC)，一种是全局GC(major GC or Full GC)

**Minor GC和IFull GC的区别**  
普通GC(minor GC):只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。  
全局GC(major GC or Full GC):指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC(但并不是绝对的）。Major GC的速度一般要比Minor GC慢上10倍以上

**判断对象是否已经死亡的算法**：引用计数算法，可达性分析算法；

四个垃圾收集算法：标记清除算法，复制算法，标记整理算法，分代收集算法；

七个垃圾收集器：Serial，SerialOld,ParNew,Parallel Scavenge,Parallel Old,CMS,G1.

## 引用计数法 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 19]  
在 Java 中，引用与对象相关联，如果要操作对象，则必须使用引用。因此，可以通过引用计数来确定对象是否可以回收。实现原则是，如果一个对象被引用一次，计数器 +1，反之亦然。当计数器为 0 时，该对象不被引用，则该对象被视为垃圾，并且可以被 GC 回收利用。

## 复制算法 ##

**年轻代：**

Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Oldgeneration中，也即一旦收集后，Eden是就变成空的了。

当对象在Eden (包括一个 Survivor区域，这里假设是from 区域）出生后，在经过一次 Minor GC后，如果对象还存活，并且能够被另外一块Survivor区域所容纳(上面已经假设为from 区域，这里应为 to区域，即 to区域有足够的内存空间来存储Eden和from区域中存活的对象)，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor区域(即 to区域）中，然后清理所使用过的Eden 以及 Survivor区域(即from区域)，并且将这些对象的年龄设置为1，以后对象在Survivor 区每熬过一次MinorGC，就将对象的年龄＋1，当对象的年龄达到某个值时（默认是15岁，通过-XX:MaxTenuringThreshold 来设定参数)，这些对象就会成为老年代。

\-XX:MaxTenuringThreshold一设置对象在新生代中存活的次数

HotSpot JVM把年轻代分为了三部分:1个Eden区和2个Survivor区(分别叫from和to)。默认比例为8:1:1，一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两惚，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 20]

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From"1就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 21]  
因为Eden区对象一般存活率较低。一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推。

**复制算法它的缺点也是相当明显的。**  
1、它浪费了一半的内存，这太要命了。

2、如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费

## 标记清除算法（Mark-Sweep) ##

**老年代**一般是由标记清除或者是标记清除与标记整理的混合实现  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 22]

解决了内存空间浪费的问题，但是会出现内存碎片，并且速度慢。

用通俗的话解释一下标记清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。|

![在这里插入图片描述][20210130163320900.png]

## 标记压缩算法(Mark-ComPact) ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 23]  
耗时长

在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。  
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。  
标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 24]  
内存效率:复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此)。内存整齐度:复制算法=标记整理算法>标记清除算法。  
内存利用率:标记整理算法=标记清除算法>复制算法。  
可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程

难道就没有一种最优算法吗?  
回答:无，没有最好的算法，只有最合适的算法。  
分代收集算法。

**年轻代(Young Gen)**

年轻代特点是区域相对老年代较小，对像存活率低。  
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。|

**老年代(Tenure Gen)**

老年代的特点是区域较大，对像存活率高。  
这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

Mark阶段的开销与存活对像的数量成正比，这点上:说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用,对并发、并行的形式提标记效率。

Sweep阶段的开销与所管理区域的大小形正相关，但Sweep“就地处决”的特点，回收的过程没有对像的移动。使其相对其它有对像移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题。

Compact阶段的开销与存活对像的数据成开比，如上一条所描述，对于大量对像的移动是很大开销的，做为老年代的第一选择并不合适。

基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。

# 08.JMM #

**volatile**是java虚拟机提供的轻量级的同步机制。

在变量前加volatile，使得各个线程可见。

1.可见性

2.原子性

3.VolatileDemo代码演示可见性

4.有序性

**JMM关于同步的规定:**  
1线程解锁前，必须把共享变量的值刷新回主内存

2线程加锁前，必须读取主内存的最新值到自己的工作内存

3加锁解锁是同一把锁

JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 25]

> To the time to life, rather than to life in time to the time to life, rather than to life in time.

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 26]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 27]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70]: /images/20221119/6b0ce92e2100433a935d71476c814c9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 1]: /images/20221119/e38cf431aa75444abbe16c666398c009.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 2]: /images/20221119/56a04caa5a45473687d26c7ec5963d37.png
[20210128160550627.png]: /images/20221119/27f1101436364aee958162acd8ea4c27.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 3]: /images/20221119/553fb67edf914a718f83948951f8d4fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 4]: /images/20221119/704c1e23078e4bf7a72e5e4015b849b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 5]: /images/20221119/6132ad8fcf2a4820a03519aa9e2b9f1f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 6]: /images/20221119/b8e81c5ece7a4afe92e8691ad6f951c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 7]: /images/20221119/a0129abc0d724b33b08c25568271d7bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 8]: /images/20221119/bb9bb0ab994c4e65a5512679ce0ad5f4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 9]: /images/20221119/1fb5ea3a565c45769d8ff0389c53ebab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 10]: /images/20221119/cbaf8c6cb25e44bca14ba079d5f2b674.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 11]: /images/20221119/a346640da7bc4936b2df9318bea58ecf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 12]: /images/20221119/0db71e96bc294877b82021a1af820854.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 13]: /images/20221119/c1da45617a0f4c48a2412498c6c8e0cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 14]: /images/20221119/747fd6cc55f944b8891563f725094e40.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 15]: /images/20221119/0906ea333a114e008e06eedf9c30ad1a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 16]: /images/20221119/922236178c0c4eb389b93efb42733f2b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 17]: /images/20221119/3a8b0aa2a5ac4cb7b32cb93e1e6ed068.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 18]: /images/20221119/f7dca4aa0b7e4a2ea67f9c04a496485b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 19]: /images/20221119/4457860476ac400688c2a2e8603a843a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 20]: /images/20221119/cd3bd8799e274887b7547305dddc6ceb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 21]: /images/20221119/a0fc7c968a624d8a9f16ce33c2402506.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 22]: /images/20221119/fa18a58a16754b4993bc14fa8b1c14d2.png
[20210130163320900.png]: /images/20221119/fe9525865990476baa695cc9fa55145b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 23]: /images/20221119/fc709bba246e47ad98fb2b146e97eb4d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 24]: /images/20221119/b98aa4ab93b04d15802454de28a323eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 25]: /images/20221119/9040101fc2f94d26ae3e9ae6c6ef60cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 26]: /images/20221119/d00a3e183b5e413485a0c1deea2774f2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWh1YW5f_size_16_color_FFFFFF_t_70 27]: /images/20221119/067c3cd0dfe1442c951d416d6746d1d0.png