JVM的体系结构及原理

思考
- 请谈谈你对JVM的理解，Java8的虚拟机有什么更新？
- 什么是OOM?什么是StackOverflowError？有哪些方法分析？
- JVM的常用参数调优你知道哪些？
- 谈谈JVM中，对类加载器你的认识

JVM体系结构

JVM位置

JVM是运行在操作系统之上的，它与硬件没有直接的交互

JVM体系结构概览

类装载器ClassLoader

简介

负责加载class文件，class文件在文件开头有特定的文件标示，将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定
Car.class字节码文件被ClassLoader类装载器加载并初始化，在方法区中生成了一个Car Class的类模板，而我们平时所用到的实例化，就是在这个类模板的基础上，形成了一个个实例，即car1，car2。反过来讲，我们可以对某个具体的实例进行getClass()操作，就可以得到该实例的类模板，即Car Class。再接着，我们对这个类模板进行getClassLoader()操作，就可以得到这个类模板是由哪个类装载器进行加载的
ClassLoader加载class文件，不光光只看文件后缀名.class，还需要检查文件开头是否有特定的标示

有哪些类装载器

虚拟机自带的加载器
- 启动类加载器（Bootstrap，C++编写），也叫根加载器，加载%JAVAHOME%/jre/lib/rt.jar
  
  rt：Runtime
- 扩展类加载器（Extension，Java编写），加载%JAVAHOME%/jre/lib/ext/*.jar
- 应用程序类加载器（AppClassLoader，Java编写），也叫系统类加载器，加载%CLASSPATH%的所有类
用户自定义加载器
- Java.lang.ClassLoader的子类，用户可以定制类的加载方式

双亲委派和沙箱安全

思考

通过下面代码来观察这几个类加载器。首先，我们先看自定义的ClassLoaderDemo，首先通过getClassLoader()获取到的是AppClassLoader，然后getParent()得到ExtClassLoader，再getParent()竟然是null？不应该是Bootstrap加载器么？这是因为，BootstrapClassLoader是使用C++语言编写的，Java在加载的时候就成了null

我们再来看Java自带的Object，通过getClassLoader()获取到的加载器直接就是BootstrapClassLoader，如果要想getParent()的话，因为是null值，所以就会报java.lang.NullPointerException空指针异常

Object object = new Object();
//自带的类 启动类加载器BootStrap
//System.out.println(object.getClass().getClassLoader().getParent().getParent());
//System.out.println(object.getClass().getClassLoader().getParent());
System.out.println(object.getClass().getClassLoader());

System.out.println("——————————————————————————————————");

//自定义的类
ClassLoaderDemo classLoaderDemo = new ClassLoaderDemo();
System.out.println(classLoaderDemo.getClass().getClassLoader().getParent().getParent());
System.out.println(classLoaderDemo.getClass().getClassLoader().getParent());

System.out.println(classLoaderDemo.getClass().getClassLoader());


![image-20201030104905503](https://img2020.cnblogs.com/blog/1875400/202011/1875400-20201120162746376-1786182009.png)

* ```java
Object object = new Object();
//自带的类 启动类加载器BootStrap
System.out.println(object.getClass().getClassLoader());

System.out.println("——————————————————————————————————");

//自定义的类
ClassLoaderDemo classLoaderDemo = new ClassLoaderDemo();
System.out.println(classLoaderDemo.getClass().getClassLoader().getParent().getParent());
System.out.println(classLoaderDemo.getClass().getClassLoader().getParent());
System.out.println(classLoaderDemo.getClass().getClassLoader());

输出中，sun.misc.Launcher是JVM相关调用的入口程序

双亲委派

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

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

沙箱安全

沙箱安全机制，是基于双亲委派机制上采取的一种JVM的自我保护机制，假设你要写一个java.lang.String的类，由于双亲委派机制的原理，此请求会先交给BootStrapClassLoader试图进行加载，但是BootStrapClassLoader在加载类时首先通过包和类名查找rt.jar中有没有该类，有则优先加载rt.jar包中的类，因此就保证了java的运行机制不会被破坏，确保你的恶意代码不会污染到Java的源码（例如自定义String类）

类加载器的加载顺序

1：当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成
2：当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成
3：如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载
4：若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException

本地方法栈（Native Method Stack）

Native Interface本地接口

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

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

本地方法栈（Native Method Stack）

就是在一个 Stack 中登记这些 native 方法，然后在执行引擎Execution Engine执行时加载本地方法库native libraies

接下来，我们通过下图的多线程部分源码来理解什么是native方法。首先我们观察start()的源码，发现它其实并没有做什么复杂的操作，只是单纯的调用了start0()这个方法，然后我们去观察start0()的源码，发现它只是一个使用了native关键字修饰的一个方法（private native void start0();），但只有声明却没有具体的实现！

程序计数器（Program Counter Register）

程序计数器（Program Counter Register），也叫PC寄存器
简单来说，PC寄存器就是保存下一条将要执行的指令地址的寄存器，其内容总是指向下一条将被执行指令的地址，这里的地址可以是一个本地指针，也可以是在方法区中相对应于该方法起始指令的偏移量
每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎Execution Engine读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记
这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令

如果执行的是一个Native方法，那这个计数器是空的

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

方法区（Method Area）

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

栈（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左右
- 图示在一个栈中有两个栈帧：
  - 栈帧2是最先被调用的方法，先入栈
  - 然后方法2又调用了方法1，栈帧1处于栈顶的位置
  - 栈帧2处于栈底，执行完毕后，依次弹出栈帧1和栈帧2
  - 线程结束，栈释放
- 每执行一个方法就会产生一个栈帧，保存到栈（后进后出）的顶部，顶部栈就是当前的方法，该方法执行完毕后，会自动将此栈帧出栈

栈溢出（StackOverflowError）

图例：使用递归的方式，test()方法里面又调用了test()方法

栈是一个内存块，它是有大小长度的。观察代码发现，只要代码一运行，test()方法就会一直进行入栈操作，而没有出栈操作，结果肯定会超出栈的大小，进而造成栈溢出错误，即java.lang.StackOverflowError
java.lang.StackOverflowError是错误，不是异常！证明如下：

栈+堆+方法区的交互关系

HotSpot

一般没有明确指定，JVM就是HotSpot
- Sun公司实现的一套符合JVM规范，即 Java HotSpot
- BA公司实现的一套符合JVM规范，即 Java Rocket
- 最后都被Orcle公司收购，并整个成了一个统一的，即 Java HotSpot
HotSpot是使用指针的方式来访问对象：Java堆中会存放访问类元数据的地址，reference存储的就直接是对象的地址
- 举例说明：MyObject myObject = new MyObject();，等号左边MyObject myObject的myObject就是引用，在Java栈里面。等号右边的new MyObject()，new出来的MyObject实例对象在堆里面。简单来说，就是Java栈中的引用myObject指向了堆中的MyObject实例对象

堆（Heap)

堆体系结构

Java7之前，一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行
- 堆内存逻辑上分为三部分：新生+养老+永久
- 其中，堆内存分为三部分：
  - Young Generation Space，新生区、新生代
  - Tenure Generation Space，老年区、老年代
  - Permanent Space，永久区、元空间
- Java7之前，堆结构图如下，而Java8则只将永久区变成了元空间
总结一下，堆内存在逻辑上分为新生+养老+元空间，而堆内存在物理上分为新生+养老

对象在堆中的生命周期

首次讲解

新生区是类的诞生、成长、消亡的区域，一个类在这里产生、应用、最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区（Eden space）和幸存区（Survivor space）,所有的类都是在伊甸区被new出来的。幸存区有两个：0区（Survivior 0 space）和1区（Survivor 1 space）。当伊甸区的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对将对伊甸区进行垃圾回收（Minor GC），YGC也叫轻GC。将伊甸区中不再被其他对象所引用的对象进行销毁。然后将伊甸区中的剩余对象移动到幸存0区，若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？再移动到养老区，若养老区也满了，那么这个时候将产生MajorGC（FullGC）又叫强GC,进行养老区的内存清理，若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。
如果出现 java.lang.OutOfMemoryError:Java heap space 异常，说明Java虚拟机的堆内存不够，原因有二：
- 1：java虚拟机的堆内存设置不够，可以通过参数 -Xms、-Xmx来调整
- 2：代码中创建了大量大对象，并且长时间不能被垃圾回收器收集（存在被引用）

面试题：语法笔试

要领：
- 基本类型传值、引用类型传指向对象的地址
- 基本类型值不变，引用类型值改变

MinorGC的过程（YGC、轻GC）

Java堆从GC的角度还可以细分为：新生区（Eden区、From Survivor区和To Survivor区）和养老区
- 新生区分为伊甸区（Eden）、幸存0区（From Survivor）、幸存1区（To Survivor），默认比例 8:1:1，也就是说 From区和To区，这两块永远相等
- 新生区占三分之一的堆空间，养老区占三分之二的堆空间
from区和to区，他们的位置和名分，不是固定的，每次GC后会交换
GC之后有交换，谁空谁是to

复制-->清空-->互换

eden、From Survivor复制到 To Survivor,年龄＋1
- 首先，当Eden区满的时候，会触发第一次GC,把还活着的对象拷贝到From Survivor 幸存0区，当Eden区再次触发GC的时候会扫描Eden区和From区域，对这两个区域进行垃圾回收，经过第二次回收后，还存活的对象，则直接复制到To区（如果有对象的年龄已经达到老年的标准，则赋值到养老区），同时把这些对象的年龄＋1
清空eden、From Survivor
- 清空Eden和From Survivor中的对象，也即复制之后有交换，谁空谁是to
To Survivor和 FromSurvivor互换
- 最后，To Survivor和From Survivor互换，原To Survivor成为下一次的GC时的From Survivor区，部分对象会在From和To区域复制来复制去，如此交换15次（由JVM参数MaxTenuringThreshold决定，这个参数默认是15），最终如果还是存活，就存入到养老区

HotSpot内存管理

不同对象的生命周期不同，其中98%的对象都是临时对象，即这些对象的生命周期大多只存在于Eden区
实际而言，方法区（Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的：类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap（非堆），目的就是要和堆分开
对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代”（Parmanent Gen）,但严格本质上说两者是不同的，或者说使用永久代来实现方法区而已，永久代是方法区（相当于是一个接口interface）的一个实现，jdk1.7的版本中，已经将原本的永久代的字符串常量池移走

永久区（Java7之前有）

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class，Interface的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存

堆参数调优

均以JDK1.8+HotSpot为例

Java7

Java8

JDK 1.8之后将最初的永久代取消了，由元空间取代。元空间的本质和永久代类似
- 元空间和永久代之间最大的区别在于：永久代使用JVM的堆内存，但是Java8以后的元空间并不在虚拟机中而是使用本机物理内存
- 因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入native memory，字符串池和类的静态变量放入Java堆中，这样可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制

JVM默认使用物理内存的四分之一（*）

堆内存调优简介

参数	说明
-Xms	设置初始内存分配大小，默认为物理内存的 1/64
-Xmx	最大分配内存，默认为物理内存的 1/4
-XX:+PrintGCDetails	输出详细的GC处理日志

//返回Java虚拟机试图使用的最大内存量
long maxMemory = Runtime.getRuntime().maxMemory();
//返回Java虚拟机中的内存总数
long totalMemory = Runtime.getRuntime().totalMemory();
System.out.println("-Xmx:MAX_MEMORY ="+maxMemory+"(字节)"+(maxMemory/(double)1024/1024)+"MB");
System.out.println("-Xms:TOTAL_MEMORY ="+totalMemory+"(字节)"+(totalMemory/(double)1024/1024)+"MB");

IDEA中如何配置JVM内存参数

在【Run】->【Edit Configuration…】->【VM options】中，输入参数-Xms1024m -Xmx1024m -XX:+PrintGCDetails，然后保存应用，退出
再次打印内存和堆内存结构详情，改为了刚刚修改的1024MB
- 堆（java8）由：新生区（伊甸区eden、幸存0区from、幸存1区to）、养老区和元空间组成

堆溢出（OutOfMemoryError）

一直new对象，导致Full GC也无法处理，直至撑爆堆内存，进而导致OOM堆溢出错误
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够，造成堆内存溢出。原因有两点：
1：Java虚拟机的堆内存设置太小，可以通过参数-Xms和-Xmx来调整
2：代码中创建了大量对象，并且长时间不能被GC回收（存在被引用）

GC（Java Garbage Collection）

GC是什么（分代收集算法）

次数上频繁收集Young区

次数上较少收集Old区

基本不动元空间

GC日志信息解读

YCG日志解读

日志内容

[GC (Allocation Failure) 
[PSYoungGen: 250570K->32K(270848K)] 497085K->344850K(658432K), 0.0540353 secs] 
[Times: user=0.24 sys=0.02, real=0.05 secs]

FULL GC日志解读

日志内容

[Full GC (Ergonomics) 
[PSYoungGen: 888K->0K(270848K)] [ParOldGen: 184327K->49907K(190976K)] 185215K->49907K(461824K), [Metaspace: 3286K->3286K(1056768K)], 0.0126262 secs] [Times: user=0.08 sys=0.00, real=0.01 secs]

规律

以"[]"为分割
名称：GC前内存占用->GC后内存占用（该区内存总大小）

GC4大算法

GC算法总体概述

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代，因此GC按照回收的区域又分为了两种类型，一种是普通GC(minor GC),一种是全局GC（major GC or Full GC）
Minor GC和Full GC的区别
- 普通GC（minor GC）:只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快
- 全局GC（major GC or Full GC）：指发生在老年代的垃圾收集动作，出现了Major GC,经常会伴随至少一次Minor GC（但并不是绝对的）Major GC的速度一般要比Minor GC慢上10倍以上

四大算法

引用计数法

引用计数算法是给每个对象设置一个计数器，当有地方引用这个对象的时候，计数器+1，当引用失效的时候，计数器-1，当计数器为0的时候，JVM就认为该对象不再被使用，是“垃圾”了

引用计数实现简单，效率高；但是不能解决循环引用问问题（A对象引用B对象，B对象又引用A对象，但是A，B对象已不被任何其他对象引用），同时每次计数器的增加和减少都带来了很多额外的开销，所以在JDK1.1之后，这个算法已经不再使用了

复制算法（Copying）

新生代（年轻代）中使用的Minor GC，这种GC算法采用的是复制算法
原理
- Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移动到Old generation中，也即一旦收集后，Eden就变成空的了
- 当对象Eden（包括一个Survivor区域，这里假设是From区域）出生后，在经过一次Minor GC后，如果对象还存活，并且能被另一块Survivor区域所容纳（上面已经假设为from区域，这里为to区域，即to区域有足够的内存来存储Eden和From区域中存活的对象），则使用复制算法将这些仍然还存活的对象复制到另外一块Survivor区域（即to区域）中，然后清理所使用的的Eden以及Survivor区域（即from区域），并且将这些对象的年龄设置为1，以后对象在Survivor区每熬过一次Minor GC,就将对象的年龄＋1，当对象的年龄达到某个值时（默认为15岁，通过-XX:MaxTenuringThreshold 来设定参数），这些对象将会成为老年代
- -XX：MaxTenuringThreshold --->设置对象在新生代中存活的次数
动态演示
- 解释
  - 年轻代中的GC,主要是复制算法（Copying）
  - HotSpot JVM把年轻代分为了三部分：伊甸（Eden）区、幸存0（From）区、幸存1（To）区。默认比例为8:1:1，一般情况下，新创建的对象都会被分配到Eden区（一些大对象特殊处理），这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一个Minor GC,年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到老年代中。因为年轻代中的对象基本都是朝生夕死（90%），所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片
  - 在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC,Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值（年龄阈值，可以通过-XX:MaxTenuringThreshold来设置）的对象会被移动到年老代，没有达到阈值的对象会被复制到To区域。经过这次GC后，Eden区和From区已经被清空。这个时候From和To会交换他们的角色，也就是新的To就是上次GC前的From,新的From就是上次GC前的To.不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到To区被填满，To区被填满之后，会将所有对象移动到年老代
    
    因为Eden区对象一般存活率较低，一般使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC,将10%的From活动区间和另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推
复制算法的缺点也是相当明显的
- 1：它浪费了一半的内存，这很致命
- 2：如果对象的存活率很高，可以极端假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变得不可忽视。所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须克服50%内存的浪费。

标记清除（Mark-Sweep）

老年代一般是由标记清除或者标记清除与标记整理的混合实现
原理
- 算法分成标记和清除两个阶段，先标记出要回收的对象，然后统一回收这些对象。形如：
- 用通俗的话解释一下标记清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行
劣势
- 1：首先，效率低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲
- 2：其次，主要缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随机的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找

标记压缩（Mark-Compact）

全称：标记清除压缩算法，简称：标记整理算法
原理
- 在整理压缩阶段，不再对标记的对象做回收，而是通过所有存活对象都像一端移动，然后直接清除边界以外的内存。可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销
  
  标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价

标记清除压缩（Mark-Sweep-Compact）

小总结

分代收集算法（*）

当前商业虚拟机都是采用分代收集算法，它根据对象存活周期的不同将内存划分为几块，一般是把Java堆分为新生代和老年代，然后根据各个年代的特点采用最适当的垃圾收集算法
在新生代中，每次垃圾收集都发现有大批对象死去，只有少量存活，就选用复制算法，而老年代因为对象存活率高，没有额外空间对它进行分配担保，就必须使用标记清除或者标记压缩算法来进行回收

年轻代（Young Gen）

年轻代特点是内存空间相对老年代较小，对象存活率低

复制算法的效率只和当前存活对象大小有关，因而很适用于年轻代的回收。而复制算法的内存利用率不高的问题，可以通过虚拟机中的两个Survivor区设计得到缓解。

老年代（Tenure Gen）

老年代的特点是内存空间较大，对象存活率高
这种情况，存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现
- 标记阶段（Mark） 的开销与存活对象的数量成正比。这点上说来，对于老年代，标记清除或者标记整理有一些不符，但可以通过多核/线程利用，对并发、并行的形式提标记效率
- 清除阶段（Sweep） 的开销与所管理内存空间大小形正相关。但Sweep“就地处决”的特点，回收的过程没有对象的移动。使其相对其他有对象移动步骤的回收算法，仍然是效率最好的。但是需要解决内存碎片问题
- 整理阶段（Compact） 的开销与存活对象的数据成开比。如上一条所描述，对于大量对象的移动是很大开销的，做为老年代的第一选择并不合适
基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以虚拟机中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高。而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器做为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。

GC垃圾回收算法比较

内存效率：复制算法>标记清除算法>标记算法（此处的效率只是简单的对比时间复杂度，实际情况不一定）
内存整齐度：复制算法=标记整理算法>标记清除算法
内存利用率：标记整理算法=标记清除算法>复制算法
可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面多提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程

面试题

JVM内存模型以及分区，需要详细到每个区放什么

堆里面的分区：Eden,Survivor from to,老年代各自的特点

GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方

Minor GC和 Full GC分别发生在什么时候

代码加载顺序练习

public class CodeBlock { //主类
    {
        System.out.println("CodeBlock的构造块444");
    }
    static {
        System.out.println("CodeBlock的静态代码块555");
    }
    public CodeBlock(){
        System.out.println("CodeBlock的构造方法666");
    }

    public static void main(String[] args) {
        System.out.println("分割线=============CodeBlock的main方法777");
        new CodeWb();
        System.out.println("--------------------------");
        new CodeWb();
        System.out.println("--------------------------");
        new CodeBlock();
    }
}

class CodeWb{
    public CodeWb(){
        System.out.println("Code的构造方法1111");
    }
    {
        System.out.println("Code的构造块2222");
    }
    static {
        System.out.println("Code的静态代码块3333");
    }
}

运行结果：静态先行仅执行一次。加载顺序：静态块>构造块>构造方法

JMM（Java内存模型）

volatile关键字

volatile是Java虚拟机提供的轻量级的同步机制
- 保证可见性
- 不保证原子性
- 禁止指令重排

JMM

JMM（Java内存模型 Java Memory Model,简称JMM）本身是一种抽象的概念并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式
由于JVM运行程序的实体是线程，而每个线程的创建时JVM都会为其创建一个工作内存（有些地方称为栈空间），工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作（读取赋值等）必须在工作内存中进行，首先要将变量从主内存拷贝到线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信（传值）必须通过主内存来完成，其简要访问过程如下图：

可见性

通知机制

public class JmmDemo {
    //JMM可见性（通知机制）
    public static void main(String[] args) {
        Mynumber mynumber = new Mynumber();
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"************************");
            try {
                Thread.sleep(3000);
            }catch (InterruptedException e){
                e.printStackTrace();
            }
            mynumber.addTo1205();
            System.out.println(Thread.currentThread().getName()+"\t update number,number value: "+mynumber.number);
        },"AAA").start();

        while (mynumber.number == 10) {
            //需要有一种通知机制告诉main线程，number已经修改为1205，跳出while
        }
        System.out.println(Thread.currentThread().getName()+"\t mission is over");
    }
}

class Mynumber {
    int number = 10;

    public void addTo1205() {
        this.number = 1205;
    }

}

运行结果：修改了number变量的值，但程序未跳出while循环终止，A线程修改了变量值，但没人通知main线程

添加关键字volatile 修饰number

class Mynumber {
    volatile int number = 10;

    public void addTo1205() {
        this.number = 1205;
    }

}

运行结果：

原子性

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。比如对于一个静态变量int x，两条线程同时对他赋值，线程A赋值为1，而线程B赋值为2，不管线程如何运行，最终x的值要么是1，要么是2，线程A和线程B间的操作是没有干扰的，这就是原子性操作，不可被中断的特点。有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可

有序性

有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象

posted @ 2020-11-20 16:28 12138Ok 阅读(159) 评论(0) 编辑收藏举报

刷新页面返回顶部

Stay Hungry,Stay Foolish

JVM的体系结构及原理

JVM的体系结构及原理

JVM体系结构

JVM位置

JVM体系结构概览

类装载器ClassLoader

简介

有哪些类装载器

双亲委派和沙箱安全

思考

双亲委派

沙箱安全

类加载器的加载顺序

本地方法栈（Native Method Stack）

Native Interface本地接口

本地方法栈（Native Method Stack）

程序计数器（Program Counter Register）

方法区（Method Area）

栈（Stack）

栈管运行，堆管存储

栈

栈存储什么

栈运行原理

栈溢出（StackOverflowError）

栈+堆+方法区的交互关系

HotSpot

堆（Heap)

堆体系结构

对象在堆中的生命周期

首次讲解

面试题 ：语法笔试

MinorGC的过程（YGC、轻GC）

复制-->清空-->互换

HotSpot内存管理

永久区（Java7之前有）

堆参数调优

Java7

Java8

JVM默认使用物理内存的四分之一（*）

堆内存调优简介

IDEA中如何配置JVM内存参数

堆溢出（OutOfMemoryError）

GC（Java Garbage Collection）

GC是什么（分代收集算法）

次数上频繁收集Young区

次数上较少收集Old区

基本不动元空间

GC日志信息解读

YCG日志解读

FULL GC日志解读

规律

GC4大算法

GC算法总体概述

四大算法

引用计数法

复制算法（Copying）

标记清除（Mark-Sweep）

标记压缩（Mark-Compact）

标记清除压缩（Mark-Sweep-Compact）

小总结

分代收集算法（*）

年轻代（Young Gen）

老年代（Tenure Gen）

GC垃圾回收算法比较

面试题

JVM内存模型以及分区，需要详细到每个区放什么

堆里面的分区：Eden,Survivor from to,老年代各自的特点

GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方

Minor GC和 Full GC分别发生在什么时候

代码加载顺序练习

JMM（Java内存模型）

volatile关键字

JMM

可见性

原子性

有序性

公告

面试题：语法笔试