https://www.jianshu.com/p/9e6841a895b4

JVM架构图

JVM体系结构概序

JVM位置

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

JVM体系结构概览

注意:

  1. 亮色
    1. 所有线程共享
    2. 存在垃圾回收
  2. 灰色
    1. 线程私有

      类装载器ClassLoader

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

Car Class 是加载 方法区

类装载器ClassLoader2

jre : Java Runtime Environment

双亲委派机制(我爸是李刚,有事找我爹),往上找

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

沙箱安全

本地接口 Native Interface

native

private native void start0();
调用操作系统功能

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

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

方法区(Method Area)

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

stack 栈管运行,堆管存储

程序 = 算法 + 数据结构
程序 = 框架 + 业务逻辑
队列(FIFO)
先进先出
栈(FILO)
先进后出
栈也叫栈内存,主管Java程序的运行,是在线程创建时创建,它的生命周期是跟随线程的生命周期,线程结束栈内存也就释放,对于栈来说不存在垃圾回收问题,只要线程一结束该栈就over,生命周期和线程一致,是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

栈存储什么?

栈帧中主要保存3类数据:
本地变量(Local Variables) : 输入参数和输出参数以及方法内的变量
栈操作(Operand Stack) : 记录出栈、 入栈的操作
栈帧数据(Frame Data) : 包括类文件、 方法等等。方法 = 栈帧

image.png

StackOverflowError是 错误 是Error子类

学术范:传值
口语化:传值,传引用
一个面试题:值引用还是传值,作用域
基本类型传复印件,
image.png

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

说明

  1. HotSpot是使用指针的方式访问对象。
  2. Java堆中会存放访问类元数据(类的结构信息)的地址
  3. reference存储的就直接是对象的地址

方法区 栈 = new 堆;
Person p = new Person();

堆体系结构概序

静态堆垃圾回收机制

口语形式

Eden 满了 开启 GC (Garbage Collection) = YGC = 轻GC
Eden 基本全部清空
S0 = from
to 区 与 from 区 交换 ?
from区 和 to区 ,他们的位置和名分,不是固定的,每次GC后 会交换GC 之后有交换,谁空谁是to

Old 养老区 满了 ,开启
Full GC = FGC
Full GC 多次,发现养老区空间没办法腾出来, 出现 错误 OOM(java.lang.OutOfMemoryError)

新生区

新生区是类的诞生、成长、消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。新生区分为两个部分:伊甸园区(Eden Space) 和幸存者区(Survivor Space)所有的类都是伊甸园区被new 出来的。幸存者区有两个:0区 (Survivor 0 Space )和 1区(Survivor 1 Space)。 当伊甸园区的空间用完时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC), 将伊甸园区只能够的不再被其他对象所引用的对象进行销毁。然后将伊甸园区中的剩余对象移动到幸存者0区。若幸存者0区也满了,再对该区进行垃圾回收,然后移动到1区,若1区也满了,在进行GC 将剩余的对象移动到养老区,若养老区也满了,则进行 Major GC(FullGC) ,如果 FGC 还是不能保存对象,就会产生OOM(OutOfMemoryError)异常 ;

产生OOM异常的原因有二

一:Java虚拟机的堆内存设置不够,可以通过参数-Xms 、-Xmx 调整
二:代码中引用大量对象,并且长时间不能被垃圾回收器收集(存在被引用)
??? 什么样的代码长时间被引用

下图中 伊甸区应为 伊甸园区
image.png

Heap堆(Java7之前)

一个JVM实例只存在一个堆内存,堆内存的大小是可以调节的。类加载器读取了类文件后,需要把类、方法、常量放到堆内存中,保存所有引用类型的真实信息,以方便执行器执行。
堆内存逻辑上分为 三部分 : 新生+养老+永久

Heap堆(Java8之后)

堆内存逻辑上分为 三部分 : 新生+养老+元空间

JVM基础 - 图4

垃圾回收机制过程

Java堆从GC的角度还可以细分为:新生代(Eden 区、From Survivor 区 和 To Survivor 区) 和老年区

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

  1. eden、SurviorFrom 复制到SurvivorTo ,年龄+1;

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

  1. 清空eden、SurvivorFrom

然后,清空Eden 和SurvivorFrom 中的对象,也即复制之后有交换,谁空谁是to

  1. SurvivorTo和 SurvivorFrom互换

最后,SurvivorTo和SurvivorFrom互换,原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From 和 To 区域中复制来复制去,如此交换15次(由JVM 参数MaxTenuringThreshold 决定,这个参数默认是15),最终如果还还活着,就存入到老年代

Sun HotSpot 内存管理

分代管理:

Why?

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

永久区(jdk1.7前有)

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

堆参数调优入门

Java1.7

Java1.8

JDK1.8之后将最初的永久代取消了,由元空间取代

元空间与永久代之间最大的区别在于:

永久代使用的JVM的堆内存,但是Java1.8以后的元空间并在于虚拟机中而是使用本机物理内存
因此,默认情况下,元空间的大小仅受本地内存限制。类的元数据放入native memory ,字符串池和类的静态变量放入Java堆中,这样可以加载多少的类的元数据就不再由MaxPermSize 控制,而由系统的实际可用空间来控制。

堆内存调优简介01

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

-Xmx : Max_Memory :1029177344 字节、981.5MB, 0.95849609375GB
-Xms : Total_Memory :1029177344 字节、981.5MB, 0.95849609375GB

Heap
PSYoungGen total 305664K, used 20971K [0x00000007aab00000, 0x00000007c0000000, 0x00000007c0000000)
eden space 262144K, 8% used [0x00000007aab00000,0x00000007abf7afb8,0x00000007bab00000)
from space 43520K, 0% used [0x00000007bd580000,0x00000007bd580000,0x00000007c0000000)
to space 43520K, 0% used [0x00000007bab00000,0x00000007bab00000,0x00000007bd580000)
ParOldGen total 699392K, used 0K [0x0000000780000000, 0x00000007aab00000, 0x00000007aab00000)
object space 699392K, 0% used [0x0000000780000000,0x0000000780000000,0x00000007aab00000)
Metaspace used 3077K, capacity 4556K, committed 4864K, reserved 1056768K
class space used 315K, capacity 392K, committed 512K, reserved 1048576K

说明

(Java 8)堆内存 逻辑上 : PSYoungGen + ParOldGen + Metaspace
(Java 8)堆内存 物理上 : PSYoungGen + ParOldGen
证明: 305664/ 1024 + 699392 / 1024 = 981.5

OOM

[GC (Allocation Failure) [PSYoungGen: 241042K->26054K(305664K)] 241042K->26062K(1005056K), 0.0181085 secs] [Times: user=0.04 sys=0.01, real=0.02 secs] [GC (Allocation Failure) [PSYoungGen: 264455K->544K(305664K)] 264463K->51237K(1005056K), 0.0345841 secs] [Times: user=0.12 sys=0.02, real=0.03 secs]
[GC (Allocation Failure) [PSYoungGen: 261296K->496K(305664K)] 514734K->355305K(1005056K), 0.0778944 secs] [Times: user=0.33 sys=0.03, real=0.08 secs]
[GC (Allocation Failure) [PSYoungGen: 101867K->560K(305664K)] 659421K->558113K(1005056K), 0.0033648 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
[GC (Allocation Failure) [PSYoungGen: 560K->480K(305664K)] 558113K->558033K(1005056K), 0.0027343 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 480K->0K(305664K)] [ParOldGen: 557553K->304533K(699392K)] 558033K->304533K(1005056K), [Metaspace: 3031K->3031K(1056768K)], 0.0477929 secs] [Times: user=0.18 sys=0.01, real=0.05 secs]
[GC (Allocation Failure) [PSYoungGen: 0K->0K(325120K)] 304533K->304533K(1024512K), 0.0037470 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [PSYoungGen: 0K->0K(325120K)] [ParOldGen: 304533K->304516K(699392K)] 304533K->304516K(1024512K), [Metaspace: 3031K->3031K(1056768K)], 0.0067151 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
Heap
PSYoungGen total 325120K, used 8583K [0x00000007aab00000, 0x00000007c0000000, 0x00000007c0000000)
eden space 299520K, 2% used [0x00000007aab00000,0x00000007ab361fe0,0x00000007bcf80000)
from space 25600K, 0% used [0x00000007be700000,0x00000007be700000,0x00000007c0000000)
to space 24064K, 0% used [0x00000007bcf80000,0x00000007bcf80000,0x00000007be700000)
ParOldGen total 699392K, used 304516K [0x0000000780000000, 0x00000007aab00000, 0x00000007aab00000)
object space 699392K, 43% used [0x0000000780000000,0x00000007929610c8,0x00000007aab00000)
Metaspace used 3063K, capacity 4556K, committed 4864K, reserved 1056768K
class space used 314K, capacity 392K, committed 512K, reserved 1048576K
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:674)
at java.lang.StringBuilder.append(StringBuilder.java:208)
at com.wujing.jvm.memory.MemoryTest.test2(MemoryTest.java:53)
at com.wujing.jvm.memory.MemoryTest.main(MemoryTest.java:16)
Disconnected from the target VM, address: ‘127.0.0.1:58724’, transport: ‘socket’

输出详细GC收集日志信息

YoungGC

[GC (Allocation Failure) [PSYoungGen: 241042K->26054K(305664K)] 241042K->26062K(1005056K), 0.0181085 secs] [Times: user=0.04 sys=0.01, real=0.02 secs]
image.png

FullGC

[Full GC (Allocation Failure)
[PSYoungGen: 496K->0K(305664K)]
[ParOldGen: 562414K->307184K(699392K)] 562910K->307184K(1005056K),
[Metaspace: 3031K->3031K(1056768K)], 0.0440490 secs] [Times: user=0.20 sys=0.02, real=0.04 secs]

image.pngimage.png

image.png

GC四大算法

GC算法总体概述

image.png

说明

JVM在进行GC时,并非每次都对上面三个内存区域一起回收的,大部分时候回收的都是指新生代,因此GC按照回收的区域又分为了两种类型,一种是普通GC(minor 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 倍以上。

引用计数算法

是什么

原理

优缺点

image.png

复制算法(Copying)

是什么

使用在年轻代,YoungGC 中,

  1. eden、SurviorFrom 复制到SurvivorTo ,年龄+1;

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

  1. 清空eden、SurvivorFrom

然后,清空Eden 和SurvivorFrom 中的对象,也即复制之后有交换,谁空谁是to

  1. SurvivorTo和 SurvivorFrom互换

最后,SurvivorTo和SurvivorFrom互换,原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From 和 To 区域中复制来复制去,如此交换15次(由JVM 参数MaxTenuringThreshold 决定,这个参数默认是15),最终如果还还活着,就存入到老年代

原理

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

GC 之后谁空,谁是To

优缺点

优点

复制算法不会产生内存碎片。
没有标记和清除的过程,效率高
没有内存碎片,可以利用bump-the-pointer实现快速内存分配

缺点

耗空间:需要双份空间

image.png

image.png
image.png
image.png

标记清除(Mark-Sweep)

是什么

老年代一般是由标记清除或者是标记清除与标记整理的混合实现

原理

image.pngimage.png

优缺点

image.png

标记压缩(Mark-Compact)

原理

image.png
image.png

优缺点

image.png

总结

image.png
image.png
image.png

面试题:
四种算法那个好
Answer:没有那个算法是能一次性解决所有问题的,因为JVM垃圾回收使用的是分代收集算法,没有最好的算法,只有根据每一代他的垃圾回收的特性用对应的算法。
新生代使用复制算法,老年代使用标记清除和标记整理算法。没有最好的垃圾回收机制,只有最合适的。
面试题:请说出各个垃圾回收算法的优缺点
内存效率:复制算法>标记清除算法>标记整理算法(此处的效率只是简单的对比时间复杂度,实际情况不一定如此)。
内存整齐度:复制算法=标记整理算法>标记清除算法。
内存利用率:标记整理算法=标记清除算法>复制算法。 可以看出,效率上来说,
复制算法是当之无愧的老大,但是却浪费了太多内存,而为了尽量兼顾上面所提到的三个指标,标记/整理算法相对来说更平滑一些,但效率上依然不尽如人意,它比复制算法多了一个标记的阶段,又比标记/清除多了一个整理内存的过程 难道就没有一种最优算法吗?Java 9 之后出现了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以达到对老年代内存的整理。

JMM(Java Memory Model)

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

JMM关于同步的规定:

  1. 线程解锁前,必须把共享变量的值刷新回主内存
  2. 线程加锁前,必须读取主内存的最新值到自己的工作内存
  3. 加锁解锁是同一把锁

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