JVM内存分布、类加载、GC

最新推荐文章于 2021-04-10 15:34:08 发布

珠穆朗玛峰上的珠穆朗玛峰

最新推荐文章于 2021-04-10 15:34:08 发布

阅读量236

点赞数

分类专栏： DeepThinking 文章标签： jvm java 类加载 GC

本文链接：https://blog.csdn.net/qq_44267206/article/details/106301318

版权

DeepThinking 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

JVM内存

线程私有的内存区域

程序计数器

一块比较小的内存空间，可以看做是当前线程执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能都需要依赖程序计数器来完成。为了线程切换后能恢复到正确的执行位置，每条线程有需要有一个独立的程序计数器，各个线程之间计数器互不影响，独立存储（线程私有）。

java虚拟机栈

Java虚拟机栈：

和线程相关，不同线程内，即使运行同一个方法，也是处于不同内存。
和方法有关，即使是同一个线程，递归调用某个方法，每次调用都会生成该次方法调用的方法栈帧。

每个方法执行的同时都会创建一个栈帧用于存储局部变量表，操作数栈，动态链接，方法出口等信息。每一个方法从调用直至执行完成的过程，就对应一个栈帧在虚拟机中出栈和入栈的过程。
此区域会产生2种异常：

如果线程请求的栈深度大于虚拟机所允许的深度（-Xss设置栈容量），将会抛出栈溢出异常（StackOverFlowError）
虚拟机在动态扩展时无法申请到足够的内存，会抛出OOM（OutOfMemoryError）异常

内存溢出和内存泄漏的区别

内存溢出（OutOfMemory）：是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。

内存泄漏（Memory Leak）：是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。

出现内存泄漏的情况：长生命周期存货的对象，内部持有不使用对象的引用，导致不使用的垃圾对象无法回收。
程序出现内存泄漏的例子：在使用长期存活的数据结构、数组时，都要考虑对象引用导致内存泄漏的问题。

实例：用户session数据结构的维护：用户很长时间没有操作，就应该清除掉用户的session，否则会出现内存泄漏的情况。

本地方法栈

本地方法栈与虚拟机栈的作用完全一样，区别是：本地方法栈为虚拟机使用的Native方法服务，而虚拟机栈为JVM执行的Java方法服务。

线程共享区域

Java堆

在JVM启动时创建，所有的对象实例以及数组都要在堆上分配。
如果在堆中没有足够的内存完成实例分配并且堆也无法再拓展时，将会抛出OOM。

方法区(JDK 1.7)/元数据区（JDK 1.8）

用于存储已被虚拟机加载的类信息，常量，静态变量，即使编译器编译后的代码等数据。
此区域的内存回收主要是针对常量池的回收以及对类型的卸载。当方法区无法满足内存分配需求时，将抛出OOM异常。

运行时常量池

编译器及运行期间产生的常量被放在运行时常量池中。
这里所说的常量包括：基本类型，包装类（包装类不管理浮点型，整型只会管理-128~127）和String。
类加载时，会查询字符串常量池，以保证运行时常量池所引用的字符串与字符串常量池中是一致的。

直接内存

JDK 1.4中新引加入NIO类，引入了一种基于通道与缓冲区的I/O方式，它介意使用Native函数库直接分配对外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引入进行操作。这样可以提高性能，因为避免了在java堆和Native堆中来回复制数据。
直接内存的分配不会受到java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存大小以及处理器寻址空纪检的先吃，也可能导致OutOfMemory异常出现。

常量池

Class文件常量池

Class文件中除了有类的版本，字段，方法，接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期间生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行时常量池

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，Java语言不要求常量一定只有编译期间在能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。

字符串常量池

存储字符串对象，或是字符串对象的引用。

类加载

类加载的时机

如果类没有进行过初始化，则需要先触发其初始化。
出现下列5种情况之一时，必须立即对类进行初始化。

创建类的实例时（new ），访问某个类或接口的静态变量（被final修饰，已在编译器把结果放入常量池的静态字段除外），或者对该静态变量赋值，调用类的静态方法（类.***调用），这些使用场景会生成new,getstatic ,putstatic或invokestatic这4条字节码指令
使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发其初始化。
初始化某个类的子类，若其父类没有被初始化，则辉县触发其父类的初始化。
java虚拟机启动时被标明为启动类的类会先被初始化。直接使用java.exe命令来运行这个主类（包含main方法的那个类）
当使用JDK1.7的动态余元支持时。
这5中情况的行为被称为对一个类进行主动引用。除此之外，所有引用类的方法都不会触发其实画，称为被动引用。
被动引用的例子：
（1）通过子类引用父类的静态字段，不会导致其子类初始化。对于静态字段，只有直接定义这个字段的类才会被初始化。
（2）通过数组定义来引用类，不会触发此类的初始化
（3）常量在编译阶段会存入调用类的常量池，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

类的生命周期

包括7个阶段

加载
验证
准备
解析
初始化
使用
卸载

验证、准备、解析3个部分统称为连接
加载、验证、准备、解析、初始化5部分为类的加载全过程
在这里插入图片描述
其中解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持java语言运行时的动态绑定。

类加载的全过程

加载

通过一个类的全限定名来获取定义此类的二进制字节流。
将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表此类的java.lang.Class对象，作为方法区这个类的各种数据的访问接口。

验证

这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
假设一个类变量的定义为：

public static int value = 123;

那变量value在准备阶段完成后的初始值是0，而不是123。
因为这时候还未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后存放于类构造器**( )**方法中，所以把value赋值为123指令将会在初始化阶段才会执行。

解析

虚拟机将常量池内的符号引用替换为直接引用的过程

符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
直接引用：直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是根据执行类构造器《clinit》（）方法的过程。

《clinit》（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问：

public class Test{
	static{
	   i = 0;
	   System.out.println(i);//编译器会提示“非法向前引用错误”
	}
	static int  i = 2;
}

《clinit》（）方法与类的构造函数（或者为实例构造器《clinit》( )方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的《clinit》（）方法执行之前，父类的《clinit》方法已经执行完毕。因此在虚拟机中第一个被执行的《clinit》方法的类肯定是java.lang.Object。
《clinit》( )方法对于类或接口来说并不是必要的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成《clinit》( )方法。
接口中定义的变量使用时，接口才会初始化：接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成《clinit》( )方法。单接口与类不同的是：执行接口的《clinit》( )方法不需要先执行父接口的《clinit》( )方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的《clinit》( )方法。-
虚拟机会保证一个类的《clinit》( )方法在多线程环境中被正确加锁、同步，如果多个多线程同时去初始化一个类，那么只会有一个线程去执行这个类的《clinit》方法，其他线程都需要阻塞等待，知道活动线程执行《clinit》方法完毕。如果在一个类的《clinit》方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中郑重阻塞往往是很隐蔽的。

类加载器

类加载可以分为：启动加载器、扩展类加载器、应用程序类加载器、自定义类加载器。关系如下。
在这里插入图片描述

启动类加载器

它负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中，启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，纳智捷使用null指定父类加载器即可：
根据《深入理解Java虚拟机》整理

扩展类加载器

这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载**< JAVA_HOME >\lib\ext**目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器

这个类加载器由sun.misc.Launcher $App-ClassLoader 实现。由于这个类加载器是ClassLoader中的getSystemClassLoader( )方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
问题：
（1）怎么理解类加载？

类加载的阶段：加载、验证、准备、解析、初始化
类加载器：
（2）类加载机制：双亲委派机制
（3）是否能自定义一个Object/String类，使用自定义加载器加载（或 java.lang.Object如果自己写一个，会不会存在安全问题？）？
（4）如果类加载不同，类对象是否相同？
（5）Tomcat类加载架构

类加载机制——双亲委派机制

在这里插入图片描述

工作过程

如果一个类收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的累加扎起都是如此，因此所有的加载请求最终都传送到顶层的启动类加载器中，只有当父加载器返回自己无法完成这个加载请求时（它的搜索范围没有找到所需的类）时，子加载器才会尝试自己去加载。
使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都是委派给除以模型最顶层的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为就无法保证了，应用程序就会变得混乱。
双亲委派模型对java程序的稳定运行起到了重要的作用。
实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass( )方法之中：

先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundExceptipn异常后，在调用自己的findClass()方法进行加载。
类加载器让用户可以通过动态的路径进行类的加载操作。
比较两个类相等的前提：必须是有同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。

垃圾回收

Object类finilize( )作用：对象进行垃圾回收之前，标记对象的可回收状态

垃圾回收机制（可达性分析算法）

在这里插入图片描述

可以作为GC Root 引用点的是：

JavaStack中的引用的对象。
方法区中静态引用指向的对象。
方法区中常量引用指向的对象。
Native方法中JNI引用的对象。

GC如何判断一个对象是垃圾对象？

引用计数算法（已淘汰）
给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器值就减1;任何时刻计数器为0的对象就是不可能再被使用的
可达性分析算法
算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(用图论的话来说,就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。

垃圾回收的过程

在这里插入图片描述

堆的GC

新生代GC：Eden区和使用S区（s0或s1）中的存活对象复制到留空的S区（s0/s1区）。GC前后s1和s0的角色会发生转变。（GC一次年龄增大一岁，直到大于15j进入老年代）
- Eden:
  - 进入对象的条件：创建对象时，优先分配的区域——空间不足时，触发Minor GC（新生代GC）
- Survivor区：一块保存对象，一块留空。
  - 进入对象的条件：触发Minor GC时，留空的S区，会进入GC存活的对象——空间不足时，存放不下的对象进入老年代。
老年代GC：——空间不足，触发Major GC（老年代GC）
- 进入对象的条件
  - 大对象直接进入（字符串，数组等）
  - 长期存活的对象进入老年代——对象年级>阈值
  - MinorGC时，留空S区空间不足存放GC后的存活对象，所有存活对象，进入老年代。
- 触发Major GC条件：空间不足

Minor GC

步骤：

复制存活对象到Suvivor区另一块（Minor Gc 一次，对象年龄+1）
清空Eden区和前一块的S区的垃圾对象
给需要创建的对象分配内存

异常情况：若留空的S空间不足以存放存活的对象，则所有存活对象，通过分配担保机制，进入老年代。

当对象年龄>15时，对象也会进入老年代。
在这里插入图片描述

垃圾回收算法

标记-清除算法（Mark-Sweep）老年代算法

（1）标记、清除
（2）老年代的回收算法
（3）缺点：

效率不足
产生大量不完整的内存碎片——导致：在进入大对象是，如果没有足够大的连续空间，就会触发Major GC

复制算法（Copying）

（1）新生代的回收算法
（2）对内存使用率不高——50%
（3）优点：实现简单、运行高效、不存在内存碎片问题

标记-整理算法

（1）老年代的回收算法

（2）标记、整理（移动存活对象到一段内存，清理另一端）

STW-Stop The World

GC导致的用户线程暂停
（1）原因：用户线程和GC线程并发、并行的执行，标记可回收的对象，在用户线程并发执行时，可能重新有引用指向该对象
（2）GC时，什么情况下会STW？

新生代GC：都会STW，造成的影响：因为Minor GC时间非常快，几乎忽略不计，影响很小。
老年代GC：根据阶段来看是否会STW——造成的影响：非常大。（老年代空间大，需要回收的对象多，耗时也多）。

Full GC一般指影响很大（会造成STW），所以一般会包含MajorGC，可能出现Minor GC.

垃圾回收（GC）、用户线程、垃圾回收线程、垃圾回收算法、垃圾收集器关系
垃圾回收线程的任务：GC
（1）若果是新生代GC，使用新生代垃圾收集器。
（2）如果是老年代GC，使用老年代垃圾收集器。

垃圾收集器是做垃圾回收工作的任务，对于不同的区域有多种具体实现的垃圾收集器，可能采取不同的垃圾回收算法。

垃圾收集器的使用场景：
并行：指的是多条垃圾收集线程并行工作，用户线程仍处于等待状态。
并发：指的是用户线程与垃圾收集器同时执行（不一定并行，可能会交替执行），用户程序继续执行，而垃圾收集器程序在另外一个CPU上。

评价垃圾收集器的指标

1.考虑内存区域：新生代采取复制算法，老年代采取标记清除算法、标记整理算法。
2.吞吐量、用户体验

用户体验：指标为单词STW时间，时间越长体验越差。
吞吐量：指标和STW的总时间。越长吞吐量越低。
一般，（1）在固定时间内，单次STW时间越长，STW总时间可能越少。
（2）用户体验和吞吐量的好和差成反比关系。

垃圾收集器种类

新生代收集器

1.Serial收集器

新生代垃圾收集器
单线程
复制算法
Stop The World
2.ParNew收集器
多线程
复制算法
Stop The World
和CMS收集器在用户体验优先的程序中搭配使用
3.Parallel Scanvenge收集器：
多线程
STW
复制算法
自适应的调节策略：当JVM设置UseAdaptiveSizePolicy这个参数为true，JVM可以监控性能，并动态的设置内存相关参数（年龄阈值，新生代大小、Eden和S区比例）

老年代收集器

1.Serial Old

单线程
标记整理算法
是CMS收集器并发操作失败时作为备用垃圾回收方案。

2.Parallel Old

多线程
标记整理算法
STW
吞吐量优先（搭配Parallel Scannvenge使用）

3.CMS（Concurrent Mark Sweep）

标记清除算法
用户体验优先
各个阶段
- 初始标记：标记GC Roots 能直接关联的对象，速度很快，STW（标记objects）
- 并发标记：GC Roots Tracting（标记objects7）
- 重新标记：STW
  - 为了解决第二阶段用户线程并发执行，导致已经标记的对象（可回收）被重新引用（有GCRoots变量指向给对象），这时就不能回收。
- 并发清除：并发清除对象
在以上阶段中：
- 1和3执行速度快，消耗时间少。（暂停用户线程时间少）
- 2和4，执行时间相对较慢，但是可以和用户线程并发执行
- 总体来看，CMS垃圾回收的工作是和用户线程一起执行的（所以称之为Concurrent Mark Sweep）
缺陷

CMS垃圾回收线程会抢占CPU资源，导致用户线程总的执行时间变少
浮动垃圾问题
1. 产生原因：CMS第四个阶段，用户线程并发执行又可能导致有对象进入老年代，而老年代也可能剩余空间不足，触发Major GC——Concurrent Mode Failure
2. 解决方案：使用Serial Old 来进行垃圾回收
3. 标记清除算法会导致老年代空间碎片，如果进入的对象没有连续的可用空间，会触发Major GC。

全堆的垃圾收集器

整体看甚于标记整理算法，局部看基于复制算法。
用户体验优先
内存划分：堆内存划分为很多region，每个region都是动态指定为E区，S区，T区。
原理/实现：
- （1）初始标记：可以和Major GC（新生代GC）同时执行，STW
- （2）并发标记：Garbage First，清理老年代
- （3）最终标记：STW，和CMS第3个阶段算法不同
- （4）筛选回收：因为和CMS算法不同，采取clean up/copy和新生代类似的整理工作，可一个MinorGC(新生代GC）同时执行，STW

珠穆朗玛峰上的珠穆朗玛峰

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM内存分布、类加载、GC

JVM内存线程私有的内存区域程序计数器一块比较小的内存空间，可以看做是当前线程执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能都需要依赖程序计数器来完成。为了线程切换后能恢复到正确的执行位置，每条线程有需要有一个独立的程序计数器，各个线程之间计数器互不影响，独立存储（线程私有）。java虚拟机栈Java虚拟机栈：和线程相关，不同线程内，即使运行同一个方法，也是处于不同内存。和方法有关，即使是
复制链接

扫一扫

专栏目录