菜鸟笔记
提升您的技术认知

Java虚拟机

运行时数据区

前三个都是线程私有的(生命周期和线程相同),后两个是线程共享的。

1、程序计数器:是一块较小的内存空间,可以看做是当前线程所执行的字节码的行号指示器。通过程序计数器的值来选取下一条要执行的字节码指令。分支、循环、跳转、异常处理等都依赖于它实现。

2、虚拟机栈:虚拟机栈描述的是Java方法执行的线程内存模型:每个方法被执行时,Java虚拟机都会同步创建一个栈帧用于存放局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法被调用直到执行完成,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

3、本地方法栈:和虚拟机栈类似,只不过虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则是为虚拟机使用到的本地方法(native关键字修饰)服务。

4、堆:是虚拟机管理的在内存中最大的一块。此内存区域的唯一目的就是存放对象实例,Java世界几乎所有的对象实例都在这里分配。Java堆是垃圾收集器管理的内存区域。

5、方法区:用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。运行时常量池是方法区的一部分。Class文件中除了有类的版本,字段,方法,接口等描述信息外,还有一项信息就是常量池表,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放在方法去的运行时常量池中。

GC(发生在堆中)

1、几个基本概念

​ Minor GC:垃圾收集目标为整个新生代

​ Major GC:垃圾收集目标为整个老年代

​ Full GC:垃圾收集目标为整个Java堆

对象死亡判定算法

1、怎么判断对象死亡,需要被回收

​ A:引用计数算法:在对象中添加一个引用计数器,每当有一个地方引用它,计数器就加一,每当一个地方的引用失效时,计数器就减一。当一个对象的机计数器为0时,那么表示该对象不能再被使用。

​ 缺点:给每一个对象都分配一个引用计数器,那么会产生额外的内存空间开销。当对象是循环引用时判定复杂。

​ 优点:原理和实现简单,判定效率也高

​ B:可达性算法:通过一系列称为“GC Roots”的根对象作为起始节点集,从这些节点开始,根据引用关系向下搜索,如果某个对象到“GC Roots”之间没有任何引用链关联,则表明此对象不能继续被使用。

哪些对象可以被称为“GC Roots”?

​ 在虚拟机栈中引用的对象,譬如各个线程被调用的方法堆栈中使用到的参数,局部变量,临时变量等

​ 在方法区中类静态属性引用的对象,譬如Java类的引用类型静态变量

​ 在方法区中常量引用的对象,譬如字符串常量池里的引用

​ native方法引用的对象

​ 被同步锁(synchronized关键字)持有的对象

引用

强引用:指程序代码中普遍存在的引用赋值,即类似new 对象的引用关系。在任何情况下,只要强引用关系还在,垃圾收集器就永远不会回收掉被引用的对象。

软引用:用来描述一些还有用,但是非必要的对象。被软引用关联的对象,在系统将要发生内存溢出前,会把这些对象划为回收范围进行二次回收,如果回收之后仍没有足够的内存,才会抛出内存溢出异常

弱引用:也是用来描述哪些非必要对象,但是他的强度比软引用更弱一些。被弱引用关联的对象只能生存到下一次垃圾回收发生。当垃圾收集器开始工作,无论内存是否充足,都会回收掉这部分对象

虚引用:是最弱的一种引用关系,一个对象是否有虚引用的存在,完全不会对其生存时间造成影响,也无法通过虚引用来获取一个对象实例。该引用关系的存在只是为了能在这个对象被回收时收到一个系统通知。

垃圾回收算法

分代收集理论

​ 收集器应该将Java堆划分出不同的区域,然后将回收对象根据其年龄(年龄是指熬过收集过程的次数)分配到不同的区域中存储。

​ 如果一个区域中大多数对象都难以熬过垃圾收集过程,那么把他们收集在一起,每次回收只需要关注如何保留少量存活而不是去标记那些大量将要被回收的对象,能以将低代价回收大量的空间。

​ 如果一个区域大多数对象都是难以被垃圾回收机制回收的,把他们集中在一起,虚拟机就能以较低的频率回收这部分区域,同时兼顾了垃圾收集的时间开销和内存空间的有效利用

​ 设计者一般至少会把Java堆划分成新生代和老年代两部分。在新生代中,每一次垃圾回收都会有大量的对象死亡被回收,而每次回收之后存活下来的对象会逐步晋升到老年代中。

​ 如果一个新生代存在跨代引用,由于老年代对象难以消亡,该引用会使得新生代对象在收集时同样得以存活,进而在年龄增长之后晋升到老年代中,这时这种跨代引用也随之解除。

1、标记——清除算法

​ 该算法分为标记和清除两个阶段:首先标记出所有需要回收的对象,标记完成后,统一回收被标记的对象。或者反过来,标记存活的对象,统一回收未被标记的对象。

​ 缺点:执行效率不稳定,当堆中有大量对象并且大部分都需要被回收时,那么标记和清除两个过程的执行效率会随着对象数量的增长而降低

​ 清除之后会产生大量的不连续的内存碎片,空间碎片太多可能会导致以后程序运行时需要分配较大对象而无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2、标记——复制算法

​ 该算法是将可用内存按容量分为大小相等的两块,每次只使用其中的一块,当其中一块的内存用完之后,将存活的对象复制到另一块内存当中,然后把使用过的内存空间一次性清理掉。

​ 优点:分配内存时不用考虑有空间碎片的复杂情况,只需要移动堆顶指针,按顺序分配即可,实现简单

​ 缺点:将可用内存缩小为了原来的一半,空间浪费严重

实现原理:把新生代划分为较大的Eden空间和两块大小相等的Survivor空间(空间大小为8:1:1),每次分配内存只使用Eden和其中一块,发生垃圾收集时,将Eden和Survivor中仍然存活的对象复制到另一块空间,然后直接清理掉Eden和Survivor。当Survivor空间不足以存放上一次新生代收集下来的存活对象,这些对象将通过分配担保机制直接进入老年代。

3、标记——整理算法

​ 标记过程和标记——清楚算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向内存空间一端进行移动,然后直接清理掉边界以外的内存。

垃圾收集器

1、Serial收集器

​ 这个收集器是一个单线程工作的收集器。他在进行垃圾收集的时候,必须暂停其他所有工作线程,直到他收集结束。这个收集器在新生代采用复制算法,老年代采用整理算法。

​ 优点:相比于其他单线程操作的收集器而言简单高效,对于资源受限的环境,他是所有收集器中额外内存消耗最小的。没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程手机效率。

​ 运用场景:在用户桌面或者部分微服务应用中,分配给虚拟机管理的内存一般不会特别大,收集几十兆的新生代垃圾收集的停顿时间可以控制在十几或者即使毫秒,只要不是频繁发生收集,这点停顿时间用户时可以接受的。

2、ParNew收集器

​ 该收集器实质上是Serial收集器的多线程并行版本。这个收集器在新生代采用复制算法,老年代采用整理算法。他运用比较多的原因是除了Serial收集器外,只有他能与CMS收集器配合工作。

​ 特点:在单核心处理器的环境中绝对不会比Serial收集器有更好的效果,甚至因为存在线程交互的开销,在伪双核处理器环境中都不能百分百保证超越Serial收集器。

3、Parallel Scavenge收集器

​ 该垃圾收集器也是一款新生代收集器,同样基于标记——复制算法实现的,能并行收集的多线程收集器。他的目标是达到一个可控制的吞吐量

​ 吞吐量 = 运行用户代码时间 / (运行用户代码时间+运行垃圾收集时间)

​ 停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序,良好的响应速度能提升用户的体验。而高吞吐量则可以最高效率的利用处理器资源,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的分析任务。

4、Serial Old收集器

​ 该收集器是Serial 收集器的老年代版本,同样是一个单线程收集器,使用标记——整理算法。主要供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下,他可能有两种用途:一种是在JDK5版本及以前的版本中与Parallel Scavenge收集器配合使用。另一种就是作为CMS收集器发生失败时的后备预案,在并发收集发生Concurrent Mode Failure时使用

5、Parallel Old收集器

​ 该收集器是Parallel Scavenge收集器的老年代版本,支持多线程并发收集,基于标记——整理算法实现

6、CMS收集器(并发收集,低停顿)

​ 该收集器是一种以获取最短回收停顿时间为目标的收集器。适合于比较关注服务的响应速度,希望停顿时间尽可能短的程序。

​ CMS全称Concurrent Mark Sweep,是基于标记——清除算法实现的。整个过程可分为四个步骤:

​ 1)初始标记

​ 2)并发标记

​ 3)重新标记

​ 4)并发标记

​ 其中初始标记、重新标记这两个步骤仍然需要“Stop The World”,即暂停其他线程。初始标记仅仅只是标记一下GC Roots能直接关联到的对象,速度很快;并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时比较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行;重写标记阶段则是为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部份对象的标记记录,这个阶段的停顿时间通常比初始标记阶段长一些,但也远比并发标记阶段的时间短;最后是并发清除阶段,清理删除标记阶段判断的已经死亡的对象,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的。

​ 缺点:对处理器资源敏感,在并发阶段虽然不会导致用户线程停顿,但是会因为占用一部分线程(或者说处理器的计算能力)而导致应用程序变慢,降低总吞吐量。

​ 由于CMS收集器无法处理“浮动垃圾”,有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC 的产生.。

​ 因为该收集器是基于标记——清除算法实现的,意味着收集结束时会有大量空间碎片产生。

7、Garbage First收集器

​ 该收集器(简称G1)是垃圾收集器技术发展史上里程碑式的成果,开创了收集器面向局部收集的设计思路和基于Region的内存形式。

​ 在以前的垃圾收集器的设计理念中,包括GMS在内,垃圾收集的目标范围要么是整个新生代,要么是整个老年代,要么是整个Java堆。而G1收集器可以面向堆内存的任何部分来组成回收集进行回收,衡量标准不再是它属于哪个分代,而是那一块内存中存放的垃圾最多,回收收益最大,这就是G1收集器的Mixed GC模式。

​ G1不再坚持固定大小以及固定数量的分代区域划分,而是把连续的Java堆划分成多个大小相等的独立区域(Region),每一个Region都可以根据需要,扮演新生代的Eden空间、Survivor空间,或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理,这样不论是新创建的对象还是熬过多次收集的就对象都有较好的收集效果。

​ Region中还有一个特殊的区域Humongous,专门用来存储大对象。大对象是指该对象的大小超过Region容量的一半。G1大部分情况下都是把Humongous区域作为老年代来看待。

​ G1收集器将Region作为单次回收的最小单元,即每次收集到的内存空间都是Region大小的整数倍,这样可以有计划的避免在整个Java堆中进行全区域的垃圾回收。更具体的思路是让G1收集器去跟踪各个Region里面的垃圾堆积的价值大小,价值即回收所获得的空间大小以及回收所需时间的经验值,然后在后台维护一个优先级列表,每次根据用户设定允许的收集停顿时间(使用参数-XX:MaxGCPauseMillis指定,默认是200毫秒),优先处理回收价值最大的那些Region,这也就是"Garbage First"名字的由来。

类加载过程

​ 虚拟机把描述类的数据从Class文件加载到内存,并对数据进行校验、转化解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的类加载机制。

​ 整个生命周期包括:加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中准备、验证、解析3个部分统称为连接。其中加载、验证、准备、初始化和卸载的执行顺序是确定的,解析阶段则在某些情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)。

加载阶段

在加载阶段虚拟机会完成三件事:

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

​ 其中获取二进制字节流可以通过Class文件、ZIP包、网络、运行时(动态代理)、JSP生成、数据库等途径获取。

​ 需要注意的是数组类的加载,数组类并不通过类加载器加载,而是由Java虚拟机直接创建,但数组类的元素还是要依靠类加载器进行加载。

​ 这些二进制字节流加载完成之后,按照指定的格式存放于于方法区内(Java7及以前方法区位于永久代,Java8位于Metaspace)。然后在方法区生成一个比较特殊的java.lang.Class对象,用来作为程序访问方法区中这些类型数据的外部接口。

验证阶段

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

​ 文件格式验证:验证字节流是否符合Class文件格式的规范;比如,是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。只有验证通过才会进入方法区进行存储。

​ 元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求;比如,是否有父类(除Object类)、父类是否为final修饰、是否实现抽象方法或接口、重载是否正确等。

​ 字节码验证:通过数据流和控制流分析,确定程序语义是合法的、符合逻辑的。比如,保证数据类型与指令正常配合工作、指令不会跳转到方法体外的字节码上,方法体中的类型转换是有效的等。

​ 符号引用验证:在虚拟机将符号引用转化为直接引用的时候进行验证,可以看做是对类自身以外的信息(常量池中的各种符号引用)进行匹配性的校验。常见的异常比如:java.lang.NoSuchMethdError、java.lang.NoSuchFiledError等。

准备阶段

准备阶段主要是正式为类变量分配内存并设置类变量初始值,变量所使用的内存都将在方法区中进行分配。

此处的类变量指的是被static修饰的变量,不包含实例变量,实例变量在对象实例化阶段分配在堆中。并且,变量的初始化值并不是类中定义的值,而是该变量所属类型的默认值。当然,也有特殊情况,比如当变量被final修饰时,此时,该字段属性是ConstantValue时,会在准备阶段初始化为指定的值。

解析阶段

​ 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化阶段

初始化阶段才是真正执行类中定义的Java程序代码(字节码)。在此阶段会根据代码进行类变量和其他资源的初始化,或者可以从另一个角度来表达:初始化阶段是执行类构造器()方法的过程。

()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static语句块)中的语句合并生成的,编译器收集的顺序是由语句在源文件中出现的顺序决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句块中可以赋值,但是不能访问。

双亲委派机制

1、在我们的java中,有四大类加载器,分别为启动加载器,扩展类加载器,引用程序类加载器和自定义类加载器。

2、工作过程:如果一个类加载器收到一个类加载的请求,它首先不会自己加载,而是把这个请求委派给父类加载器。只有父类无法完成时子类才会尝试加载。这样就能保证类的安全性,比如说我们自定义了一个String类,那么我们加载时不会加载我们自定义的String类,而是会不断向上委派加载,在上层加载器中有一个String类,那么就会加载Java自带的String,而不会加载我们自定义的类,这样就可以防止恶意修改我们的类信息。