内存与垃圾回收
一、JVM与JAVA体系结构
1.1 概述
JAVA虚拟机:
- 含义:
- Java虚拟机是一台执行Java字节码的虚拟计算机,它拥有独立的运行机制,其运行的Java字节码也未必由Java语言编译而成。
- JVM平台的各种语言可以共享Java虚拟机带来的跨平台性、优秀的垃圾回器,以及可靠的即时编译器。
- Java技术的核心就是Java虚拟机(JVM,Java virtual Machine因为所有的Java程序都运行在Java虚拟机内部。
- 作用:
- Java虚拟机就是二进制字节码的运行环境,负责装载字节码到其内部,解释/编译为对应平台上的机器指令执行。每一条Java指令,Java虚拟机规范中都有详细定义,如怎么取操作数,怎么处理操作数,处理结果放在哪里。
- 特点:
- 一次编译,到处运行
- 自动内存管理
- 自动垃圾回收功能
1.2 jvm整体结构
HotSpot结构图
简略图:
详细图:

1.3 java代码执行流程
- 源文件被java编译器编译成字节码文件
- 字节码文件在java虚拟机中被执行
- 类加载器
- 字节码校验器
- 解释执行与及时编译并存
- 操作系统执行指令
1.4 栈的指令集和寄存器的指令集
Java编译器输入的指令流基本上是一种基于栈的指令集架构,另外一种指令集架构则是基于寄存器的指令集架构。
具体来说:这两种架构之间的区别:
-
基于栈式架构的特点
- 设计和实现更简单,适用于资源受限的系统;
- 避开了寄存器的分配难题:使用零地址指令方式分配。
- 指令流中的指令大部分是零地址指令,其执行过程依赖于操作栈。指令集更小,编译器容易实现。
- 不需要硬件支持,可移植性更好,更好实现跨平台
-
基于寄存器架构的特点
- 典型的应用是x86的二进制指令集:比如传统的Pc以及Android的Davlik虚拟机。
- 指令集架构则完全依赖硬件,可移植性差
- 性能优秀和执行更高效;
- 花费更少的指令去完成一项操作。
- 在大部分情况下,基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主,而基于栈式架构的指令集却是以零地址指令为主。
总结:
**由于跨平台性的设计,Java的指令都是根据栈来设计的。**不同平台cPU架构不同,所以不能设计为基于寄存器的。优点是跨平台,指令集小,编译器容易实现,缺点是性能下降,实现同样的功能需要更多的指令。
基于栈:跨平台性、指令集小、指令多;执行性能比寄存器差
1.5 jvm生命周期
虚拟机的启动
- Java虚拟机的启动是通过引导类加载器(bootstrap class loader)创建一个初始类(initial class)来完成的,这个类是由虚拟机的具体头现指疋的。
虚拟机的执行
- 一个运行中的Java虚拟机有着一个清晰的任务:执行Java程序。
- 程序开始执行时他才运行,程序结束时他就停止。
- 执行一个所谓的Java程序的时候,真真正正在执行的是一个叫做Java虚拟机的进程。
虚拟机的退出
- 程序正常执行结束
- 程序在执行过程中遇到了异常或错误而异常终止由于操作系统出现错误而导致Java虚拟机进程终止
- 某线程调用Runtime类或system类的exit方法,或 Runtime类的halt方法,并且Java安全管理器也允许这次exit或halt操作。
二、类加载子系统
2.1 类加载子系统的几个阶段


2.1.1 Loading阶段
加载:
- 通过一个类的全限定名获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.class对象,作为方法区这个类的各种数据的访问入口
2.1.2 Linking阶段
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6Tf0ngr6-1637148184497)(jvm-上篇-内存与垃圾回收.assets/image-20211101201749364.png)]
2.1.3 Initialization阶段
初始化:
- 初始化阶段就是执行类构造器方法()的过程。
- 此方法不需定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
- 构造器方法中指令按语句在源文件中出现的顺序执行。
- ()不同于类的构造器。(关联:构造器是虚拟机视角下的 ( ))·若该类具有父类,JVM会保证子类的()执行前,父类的()已经执行完毕。
- 虚拟机必须保证一个类的 ()方法在多线程下被同步加锁。
2.2 类加载器的分类
2.2.1 介绍
在Loading阶段使用了不同的类加载器来加载字节码文件
JVM支持两种类型的类加载器,分别为引导类加载器(BootstrapclassLoader)和自定义类加载器(User-Defined ClassLoader)。
从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类classLoader的类加载器都划分为自定义类加载器。
无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个,如下所示:

下面是一段关于类加载器的测试:
说明了
- 我们平时自己写的类默认会被SystemClassLoader系统类加载器所加载
- 引导类加载器输出null是因为它是由c语言写的
- String被输出的是null说明他是引导类加载器加载的 => 系统的核心类是由引导类加载器加载的
public class ClassLoaderTest {
public static void main(String[] args) {
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader);
//jdk.internal.loader.ClassLoaders$AppClassLoader@3fee733d
ClassLoader extentClassLoader = systemClassLoader.getParent();
System.out.println(extentClassLoader);
//jdk.internal.loader.ClassLoaders$PlatformClassLoader@10f87f48
ClassLoader bootstrapClassLoader = extentClassLoader.getParent();
System.out.println(bootstrapClassLoader);
//null
ClassLoader curClassLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(curClassLoader);
//jdk.internal.loader.ClassLoaders$AppClassLoader@3fee733d
ClassLoader stringClassLoader = String.class.getClassLoader();
System.out.println(stringClassLoader);
//null
}
}
2.2.2 类加载器
虚拟机自带的加载器
-
启动类加载器(引导类加载器,Bootstrap classLoader)
- 这个类加载使用C/C++语言实现的,嵌套在JVM内部。
- 它用来加载Java的核心库(JAVA_ HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类
- 并不继承自java.lang.classLoader,没有父加载器。
- 加载扩展类和应用程序类加载器,并指定为他们的父类加载器。
- 出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax
-
扩展类加载器(Extension classLoader)
- **Java语言编写,**由sun.misc.Launcher$ExtClassLoader实现。
- 派生于classLoader类
- 父类加载器为启动类加载器
- 从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。
-
应用程序类加载器(系统类加载器,AppclassLoader)
- java语言编写,由sun.misc.Launcher$AppclassLoader实现
- 派生于classLoader类
- 父类加载器为扩展类加载器
- 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载是程序中默认的类加载器,一般来说,Java应用的类都是由它来完成加载
- 通过classLoader#getsystemclassLoader ()方法可以获取到该类加载器
2.2.3 自定义类加载器
用户自定义类加载器实现步骤:
- 开发人员可以通过继承抽象类java.lang.classLoader类的方式,实现自己的类加载器,以满足一些特殊的需求
- 在JDK1.2之前,在自定义类加载器时,总会去继承classLoader类并重写loadclass ()方法,从而实现自定义的类加载类,但是在JDK1.2之后已不再建议用户去覆盖loadclass ()方法,而是建议把自定义的类加载逻辑写 在findclass ()方法中
- 在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己去编写findclass ()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
ClassLoader
ClassLoader类,它是一个抽象类,其后所有的类加载器都继承自ClassLoader (不包括启动类加载器)
常用方法:

获取方法:

2.3 双亲委派机制
介绍:
Java虚拟机对class文件采用的是按需加载的方式,也就是说当需要使用该类时才会将它的class文件加载到内存生成class对象。而且加载某个类的class文件时,Java虚拟机采用的是双亲委派模式,即把请求交由父类处理,它是一种任务委派模式。
工作原理:
-
如果一个类加载器收到了类加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行;
-
如果父类加载器还存在其父类加载器,则进一步向上委托,依次递归,请求最终将到达顶层的启动类加载器;
-
如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,子加载器才会尝试自己去加载,这就是双亲委派模式。
优势:
- 避免类的重复加载
- 保护程序安全,防止核心A斑被随意篡改
- 自定义类:java. lang.String
- 自定义类: java . lang.shkstart
沙箱安全机制:
我们自定义string类,但是在加载自定义string类的时候会率先使用引导类加载器加载,而引导类加载器在加载的过程中会先加载jdk自带的文件(rt.jar包中java\lang\string.class),报错信息说没有main方法,就是因为加载的是rt.jar包中的string类。这样可以保证对java核心源代码的保护,这就是沙箱安全机制。
2.4 其他
判断对象是否是同一类
相同必须同时满足:
- 同一包名和类名
- 同一类加载器
对类加载器的引用
如果一个类是由用户类加载器加载的,那么JVM会将该加载器的一个引用作为类型信息放到方法区中。
类的主动使用和被动使用
- 主动使用,又分为七种情况:
- 创建类的实例
- 访问某个类或接口的静态变量,或者对该静态变量赋值
- 调用类的静态方法
- 反射(比如:class.forName ( “com.king.Test”) )
- 初始化一个类的子类
- Java虚拟机启动时被标明为启动类的类
- JDK 7开始提供的动态语言支持:java . lang .invoke.MethodHandle实例的解析结果REF_getstatic、REF_putstatic、REF_invokestatic句柄对应的类没有初始化,则初始化
- 除了以上七种情况,其他使用Java类的方式都被看作是对类的被动使用,都不会导致类的初始化。
三、运行时数据区概述及线程
3.1 运行时数据区内存结构
内存是非常重要的系统资源,是硬盘和cPU的中间仓库及桥梁,承载着操作系统和应用程序的实时运行。JVM内存布局规定了Java在运行过程中内存申请、分配、管理的策略,保证了JVM的高效稳定运行。
不同的JVM对于内存的划分方式和管理机制存在着部分差异。
经典运行时数据区结构:


详细结构:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ULEMV6Um-1637148184510)(https://gitee.com/auroranb/cloudimage/raw/master/img/202111171916321.png)]
其中堆区和方法区是随着JVM创建和销毁,而本地方法区、程序计数器、虚拟机栈与线程一一对应。

进程:Heap、Method Area(永久代/元空间)
线程:JVM Stacks、Navtive Method Stacks、 Program Counter Register
3.2 线程说明
- 线程是一个程序里的运行单元。JVM允许一个应用有多个线程并行的执行。
- 在Hotspot JVM里,每个线程都与操作系统的本地线程直接映射。
- 当一个Java线程准备好执行以后,此时一个操作系统的本地线程也同时创建。Java线程执行终止后,本地线程也会回收。
- 操作系统负责所有线程的安排调度到任何一个可用的CPU上。一旦本地线程初始化成功,它就会调用Java线程中的run ()方法。
3.3 程序计数器(PC寄存器)
3.3.1 简介
JVM中的程序计数寄存器(Program counter Register)中, Register 的命名源于CPU的寄存器,寄存器存储指令相关的现场信息。CPU只有把数据装载到寄存器才能够运行。
这里,并非是广义上所指的物理寄存器,或许将其翻译为ec计数器(或指令计数器)会更加贴切(也称为程序钩子),并且也不容易引起一些不必要的误会。JVM中的PC寄存器是对物理PC寄存器的一种抽象模拟。
作用:
PC寄存器用来存储指向下一条指令的地址,也即将要执行的指令代码。由执行引擎读取下一条指令。
3.3.2 使用

程序计数器实际就是存储了程序的运行位置,为了让CPU在切换线程后再次执行线程的指令是恢复到正确的位置
3.3.3 面试问题
- 使用PC寄存器存储字节码指令地址有什么用、为什么使用PC寄存器记录当前线程的执行地址呢?
因为CPU需要不停的切换各个线程,这时候切换回来以后,就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值来明确下一条应该执行什么样的字节码指令。
- PC寄存器为什么会被设定为线程私有?
我们都知道所谓的多线程在一个特定的时间段内只会执行其中某一个线程的方法,CPU会不停地做任务切换,这样必然导致经常中断或恢复,如何保证分毫无差呢?为了能够准确地记录各个线程正在执行的当前字节码指令地址,最好的办法自然是为每一个线程都分配一个pc寄存器,这样一来各个线程之间便可以进行独立计算,从而不会出现相互千扰的情况。
3.4 虚拟机栈
3.4.1 概述
背景:
由于跨平台性的设计,Java的指令都是根据栈来设计的。不同平台CPU架构不同,所以不能设计为基于寄存器的。
优点是跨平台,指令集小,编译器容易实现,缺点是性能下降,实现同样的功能需要更多的指令。
栈和堆:
栈是运行时的单位,而堆是存储的单位。
即:栈解决程序的运行问题,即程序如何执行,或者说如何处理数据。堆解决的是数据存储的问题,即数据怎么放、放在哪儿。
栈的基本内容:
-
java虚拟机栈是什么
Java虚拟机栈(Java virtual Machine stack),早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈,其内部保存一个个的栈帧(stack Frame),对应着一次次的Java方法调用。
-
生命周期
与线程的生命周期一直
-
作用
主管Java程序的运行,它保存方法的局部变量、部分结果,并参与方法的调用和返回。
-
优点
- 快速有效,访问速度仅次于程序计数器
- JVM对虚拟机栈只有进栈和出站的操作,操作简单
- 不存在垃圾回收问题
-
栈中可能出现的异常
Java虚拟机规范允许Java栈的大小是动态的或者是固定不的。
- 如果采用固定大小的Java虚拟机栈,那每一个线程的Java虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量,Java虚拟机将会抛出一个stackoverflowError异常。
- 如果Java虚拟机栈可以动态扩展,并且在尝试扩展的时候无法申请到足够的内存,或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈,那Java虚拟机将会抛出一个outOfMemoryError异常。
-
如何设置虚拟机栈的
通过 -Xss 参数设置
3.4.2 存储单位-栈帧
每个线程都有自己的栈,栈中的数据都是以栈帧(stack Frame)的格式存在。
在这个线程上正在执行的每个方法都各自对应一个栈帧(stack Frame) 。
栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息。
栈的运行原理
- 在一条活动线程中,一个时间点上,只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧(栈顶栈帧)是有效的,这个栈帧被称为当前栈帧(current Frame),与当前栈帧相对应的方法就是当前方法(currentMethod),定义这个方法的类就是当前类(current class) 。
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作。
- 如果在该方法中调用了其他方法,对应的新的栈帧会被创建出来,放在栈的顶端,成为新的当前帧。
- 不同线程中所包含的栈帧是不允许存在相互引用的,即不可能在一个栈帧之中引用另外一个线程的栈帧。
- 如果当前方法调用了其他方法,方法返回之际,当前栈帧会传回此方法的执行结果给前一个栈帧,接着,虚拟机会丢弃当前栈帧,使得前一个栈帧重新成为当前栈帧。
- Java方法有两种返回函数的方式,**一种是正常的函数返回,使用return指令;另外一种是抛出异常。**不管使用哪种方试,都会导致栈帧被弹出。
栈帧的内部有如下结构:
- 局部变量表
- 操作数栈(表达式栈)
- 动态链接(指向运行时常量池的引用)
- 方法返回地址
- 一些附加信息
3.4.3 局部变量表
简介:
- 局部变量表也被称之为局部变量数组或本地变量表
- 定义为一个数字数组,主要用于存储方法参数和定义在方法体内的局部变量,这些数据类型包括各类基本数据类型、对象引用(reference),以及returnAddress类型。
- 由于局部变量表是建立在线程的栈上,是线程的私有数据,因此不存在数据安全问题
- 局部变量表所需的容量大小是在编译期确定下来的,并保存在方法的code属性的maximum local variables数据项中。在方法运行期间是不会改变局部变量表的大小的。
局部变量表是影响栈帧大小的主要因素:
- **方法嵌套调用的次数由栈的大小决定。**一般来说,栈越大,方法嵌套调用次数越多。对一个函数而言,它的参数和局部变量越多,使得局部变量表膨胀它的栈帧就越大,以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间,导致其嵌套调用次数就会减少。
- **局部变量表中的变量只在当前方法调用中有效。**在方法执行时,虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后随着方法栈帧的销毁,局部变量表也会随之销毁。

局部变量表存储了:起始的行号,作用的长度,调用的索引(第几个slot),变量名,类型描述的信息
局部变量表的基本单位(Slot):
- 参数值的存放总是在局部变量数组的index0开始,到数组长度-1的索引结束。
- 局部变量表,最基本的存储单元是slot(变量槽)
- 局部变量表中存放编译期可知的各种基本数据类型(8种),引用类型( reference) ,returnAddress类型的变量。
- 在局部变量表里,32位以内的类型只占用一个slot(包括returnAddress类型),64位的类型(long和double)占用两个slot。
- byte . short . char在存储前被转换为int,boolean也被转换为int,0表示false ,非0表示true
- long和doubl

最低0.47元/天 解锁文章
2743

被折叠的 条评论
为什么被折叠?



