JVM 周阳 尚硅谷19-06

一 JVM介绍

灰色: 代表线程私有 内存占用较少
橙色: 线程共享 存在垃圾回收

二 类加载器

回忆一下多线程8锁
静态同步方法锁的是上图的Car Class(模板)
非静态同步方法锁的是当前实例对象car1…

1 什么是类加载器

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

在文件开头有特定的文件标示

2 类加载器的种类

虚拟机自带的加载器

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

用户自定义加载器

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

例子

package com.luyi.demo;

/**
 * @author 卢意
 * @create 2021-01-12 16:41
 */
public class ClassLoadDemo {
	public static void main(String[] args) {
		Object object = new Object();
		System.out.println(object.getClass().getClassLoader());

		ClassLoadDemo classLoadDemo = new ClassLoadDemo();
		System.out.println(classLoadDemo.getClass().getClassLoader().getParent().getParent());// null 不让挖祖坟  哈哈哈
		System.out.println(classLoadDemo.getClass().getClassLoader().getParent());// sun.misc.Launcher$ExtClassLoader@78308db1
		System.out.println(classLoadDemo.getClass().getClassLoader());// sun.misc.Launcher$AppClassLoader@18b4aac2
	}
}

可以这么说 sun.misc.Launcher是Java虚拟机的入口

3 双亲委派机制

1. 当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己去加载。
2. 采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个 Object对象。

概括一下就是 再加载类的时候先去用BootStrapClassLoad加载,如果找不到该类再用ExtClassLoader加载,如果再找不到就去用AppClassLoader加载

4 沙箱安全机制

上面的双亲加载机制保证了Java原代码不受污染保证程序的安全

三 执行引擎

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

四 Native Interface 本地方法接口

native 代表调用的是C语言函数库和操作系统函数库

本地接口的作用是融合不同的编程语言为 Java 所用，它的初衷是融合 C/C++程序，Java 诞生的时候是 C/C++横行的时候，要想立足，必须有调用 C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是 Native Method Stack中登记 native方法，在Execution Engine 执行时加载native libraies。
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用 Socket通信，也可以使用Web Service等等，不多做介绍。

native方法只有声明 没有实现

Native Method Stack

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

五 PC寄存器(程序计数器) Program Countter Register

简单一句话 当前程序结束了 PC寄存器指向下一个程序

1. 每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
2. 这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。
3. 如果执行的是一个Native方法，那这个计数器是空的。
4. 用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误

六 方法区 Method Area

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

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

七 Stack栈内存 栈管运行 堆管存储

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

为什么栈管理方法

上面这段程序就可以看出 Main线程(方法) 需要等到m1方法结束才能继续执行并结束
栈层面来说 等m1出栈 main才能出栈 (突然悟了!!!)

栈存储的内容
栈帧中主要保存3 类数据：(java层面说的方法 在虚拟机内就是栈帧)

本地变量（Local Variables）:输入参数和输出参数以及方法内的变量；
栈操作（Operand Stack）:记录出栈、入栈的操作；
栈帧数据（Frame Data）:包括类文件、方法等等。

栈运行原理：

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

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

每执行一个方法都会产生一个栈帧，保存到栈(后进先出)的顶部，顶部栈就是当前的方法，该方法执行完毕 后会自动将此栈帧出栈

调用的方法如果过多会造成栈溢出
注意是Error

Exception in thread "main" java.lang.StackOverflowError

八 堆 栈 方法区的交互关系

HotSpot(Sun公司实现的JDK)是使用指针的方式来访问对象：
Java堆中会存放访问**类元数据(一个类的结构信息(类模板))**的地址，
reference存储的就直接是对象的地址

九 Heap 堆

Heap堆 结构简介

一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分：

1. 新生代

(1) 伊甸园区
(2) 幸存0区
(3) 幸存1区

2. 老年代
3. 元空间 / 永久代
   

java7 堆内存 逻辑上 分为 新生代 老年代 永久代
java8 永久代被元空间取代

new对象的流程

简单理解

1. new一个新对象 是将对象存放在新生代的伊甸园区
2. 如果一直new对象 达到一定阈值 触发GC(YGC) 新生区的GC(轻量级的GC) 新生代的一点园区的对象基本全部清空. 如果还在引用的对象会不被清除 但是会被移动到幸存者0区
3. 同上如果幸存者0区储存的对象到达一定阈值, 又会触发GC(YGC) 清除大部分对象 如果还在引用的对象会不被清除 但是会被移动到幸存者1区
4. 还是同样的道理 如果在幸存者1区触发GC还存活的对象就被转移到了老年代
5. 如果老年代也满了, 开启 FullGC(FGC) 多次以后 还是满了 会报OOM对内存溢出OutOfMemoryError

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

十 对象生命周期和GC

幸存者0区 = S0 = form
幸存者1区 = S1 = to
但是 form 区和 to 区 的名字和位置不是固定的, 每次GC里面存活的对象从伊甸园区(第一次只有伊甸园区存活的对象复制到from区)和form区复制到to区之后, from区和to区交换, 谁空谁是to区
(GC之后有交换(指的是from区和to区的交换), 谁空谁是to区)
物理上的堆内存

伊甸园区和from区的存留对象复制到to区, 存活对象的年龄+1, 当15次之后(15岁)还存留的对象,将会被复制到老年代

完整过程分析

十一 元空间

逻辑上新生老年元空间 物理上新生老年

十二 堆参数调优入门

堆结构

Xms 堆内存的初始值 Xmx 堆内存的最大值
Xmn 新生代的初始大小 默认新生代 : 老年代 的空间= 1 : 2
永久带的初始值和最大值 java8已经见不到了

在Java8中，永久代已经被移除，被一个称为元空间的区域所取代。元空间的本质和永久代类似。

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

因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入 java 堆中，这样可以加载多少类的元数据就不再由MaxPermSize 控制, 而由系统的实际可用空间来控制。

堆内存调优

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

生产上 -Xms 和 -Xmx必须一样

避免GC和运用程序争抢内存使内存忽高忽低, 产生停顿

IdeaJVM内存配置

解释了 物理上堆内存分为新生代和老年代
逻辑上分为 新生代老年代元空间

OOM

Exception in thread “main” java.lang.OutOfMemoryError: Java heap space

显示了先GC 再FullGC 若老年代执行FUllGC发现依然无法进行对象的保存, 就会产生OOM异常

十三 GC收集日志

[Full GC (Allocation Failure) 
[PSYoungGen: 0K->0K(2048K)]
[ParOldGen: 3829K->3809K(5632K)] 3829K->3809K(7680K),
[Metaspace: 3528K->3528K(1056768K)], 0.0105762 secs] 
[Times: user=0.02 sys=0.00, real=0.01 secs] 

十四 GC四大算法

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倍以上 (young区(三分之一)比Old区(三分之二)小 )

引用计数算法

package com.atguigu.jvm;
 
 
/**@Description:-verbose:gc*/
public class RefCountGC
{
  private byte[] bigSize = new byte[2 * 1024 * 1024];//这个成员属性唯一的作用就是占用一点内存
  Object instance = null;
 
  public static void main(String[] args)
  {
    RefCountGC objectA = new RefCountGC();
    RefCountGC objectB = new RefCountGC();
    objectA.instance = objectB;
    objectB.instance = objectA;
    objectA = null;
    objectB = null;
 
 	// 手动触发GC  GC线程处于就绪状态 没有直接执行
    System.gc();
  }
}
 

复制算法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 — 设置对象在新生代中存活的次数

HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和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线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。

主要进行两项工作，第一项则是标记，第二项则是清除。
标记：从引用根节点开始标记遍历所有的GC Roots， 先标记出要回收的对象。
清除：遍历整个堆，把标记的对象清除。
缺点：此算法需要暂停整个应用，会产生内存碎片

1、首先，它的缺点就是效率比较低（递归与全堆对象遍历），而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲
2、其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

标记整理Mark-Compact

在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

标记/整理算法不仅可以弥补标记/清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价

标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。
从效率上来说，标记/整理算法要低于复制算法。

混合版本

总结

内存效率：复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此）。
内存整齐度：复制算法=标记整理算法>标记清除算法。
内存利用率：标记整理算法=标记清除算法>复制算法。

可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记/整理算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记/清除多了一个整理内存的过程

没有最好的算法，只有最合适的算法 (java9以后出现了G1算法 很牛逼)

分代收集算法。
通过分析每一代的特性选择合适的算法

年轻代(Young Gen)
年轻代特点是区域相对老年代较小，对像存活率低

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

老年代(Tenure Gen)
老年代的特点是区域较大，对像存活率高。

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

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

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

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

基于上面的考虑，老年代一般是由标记清除或者是标记清除与标记整理的混合实现。以hotspot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对像的回收效率很高，而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器做为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用Serial Old执行Full GC以达到对老年代内存的整理。

十五

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

方法区 : 供各线程共享的运行时内存区域。它存储了每一个类的结构信息，例如运行时常量池（Runtime Constant Pool）、字段和方法数据、构造函数和普通方法的字节码内容。
Java栈区 : 8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。
栈帧中主要保存3 类数据：(java层面说的方法 在虚拟机内就是栈帧)

本地变量（Local Variables）:输入参数和输出参数以及方法内的变量；
栈操作（Operand Stack）:记录出栈、入栈的操作；
栈帧数据（Frame Data）:包括类文件、方法等等。

本地方法栈 : 内存中专门开辟了一块区域处理标记为native的代码 在Execution Engine 执行时加载native libraies。
PC寄存器(程序计数器) : 用来存储指向下一条指令的地址,也即将要执行的指令代码，由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
堆 : 类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息

堆分区的 Eden survivor(from to) 老年代 各自的特点

Eden

十六 JMM Java内存模型

JMM 本身是一种抽象的概念,并不真实存在, 他描述的是一组规则或者规范, 通过这组规范定义了程序的各个变量(包括实例字段, 静态字段和构成数组对象的元素)的访问方式

简单了解一下 volatile

volatile是Java虚拟机提供的轻量级的同步机制

JMM 的特点

1. 可见性
2. 原子性
3. 有序性

可见性的代码验证

package com.luyi.demo;

import java.util.concurrent.TimeUnit;

/**
 * 可见性(通知机制)volatile 保证了可见性
 * @author 卢意
 * @create 2021-01-13 20:04
 */

class MyNumber {
	volatile int num = 10;

	public void addTo1205() {
		this.num = 1205;
	}
}
public class T2 {
	public static void main(String[] args) {
		MyNumber myNumber = new MyNumber();

		// 模拟线程操作主物理内存的共享变量
		new Thread(() -> {
			try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
			myNumber.addTo1205();
			System.out.println(Thread.currentThread().getName() + "\t number = " + myNumber.num);
		}, "A线程").start();

		while (myNumber.num == 10) {
			// 需要有一种通知机制 告诉main线程num 已经修改成1205
			// num前面不加volatile且while里不加东西的话 就退不出来 因为A线程是在自己的工作空间修改num main内存谁不知道
		}
		System.out.println(Thread.currentThread().getName() + "\t 跳出循环");
	}
}