Java 虚拟机面试
JVM 主要组成部分
JVM 包含两个子系统和两个组件:
两个子系统
- Class loader(类装载):根据给定的全限定类名(如:java.lang.Object)来装载 class 文件到 Runtime data area 中的method area。
- Execution engine(执行引擎):执行 classes 中的指令。
两个组件
- Runtime data area(运行时数据区):这就是我们常说的 JVM 的内存。
- Native Interface(本地接口):与 Native libraries 交互,是其它编程语言交互的接口。
首先通过编译器(javac)把 Java 代码编译成字节码(.class)。类加载器(ClassLoader)再把字节码加载到内存中,将其放在运行时数据区(Runtime data area)的方法区内。而字节码文件只是 JVM 的一套指令集规范,并不能直接交给底层操作系统去执行,因此需要特定的命令解析器执行引擎(Execution Engine),将字节码翻译成底层系统指令,再交由 CPU 去执行,而这个过程中需要调用其他语言的本地库接口(Native Interface)来实现整个程序的功能。
JVM 运行时数据区
JVM 在执行 Java 程序的过程中会把它所管理的内存区域划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁的时间,有些区域随着虚拟机进程的启动而存在,有些区域则是依赖线程的启动和结束而建立和销毁。不同虚拟机的运行时数据区可能略微有所不同,但都会遵从 Java 虚拟机规范, JVM 规范规定的区域分为以下 5 个部分:
程序计数器(Program Counter Register):当前线程所执行的字节码的行号指示器,字节码解析器的工作是通过改变这个计数器的值,来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能,都需要依赖这个计数器来完成。
Java 虚拟机栈(Java Virtual Machine Stacks):用于存储局部变量表、操作 数栈、动态链接、方法出口等信息。
本地方法栈(Native Method Stack):与虚拟机栈的作用是一样的,只不过虚拟机栈是服务 Java 方法的,而本地方法栈是为虚拟机调用 Native 方法服务的。
Java 堆(Java Heap):Java 虚拟机中内存最大的一块,是被所有线程共享,几乎所有的对象实例都在这里分配内存。
方法区(Methed Area):用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。
对象创建的主要流程
虚拟机遇到一条 new 指令时,先检查常量池是否已经加载相应的类,如果没有,必须先执行相应的类加载(ClassLoader)。类加载通过后,接下来分配内存。若 Java 堆中内存是绝对规整的,使用指针碰撞方式分配内存;如果不是规整的,就从空闲列表中分配,叫做空闲列表方式。
划分内存时还需要考虑一个问题——并发,也有两种方式: CAS同步处理,或者本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。然后内存空间初始化操作,接着是做一些必要的对象设置(元信息、哈希码……),然后执行方法。
为对象分配内存
类加载完成后,接着会在 Java 堆中划分一块内存分配给对象。内存分配根据 Java 堆是否规整,有两种方式:
指针碰撞:如果 Java 堆的内存是规整,即所有用过的内存放在一边,而空闲的内存放在另一边。分配内存时将位于中间的指针指示器向空闲的内存移动一段与对象大小相等的距离,这样便完成分配内存工作。
空闲列表:如果 Java 堆的内存不是规整的,则需要由虚拟机维护一个列表来记录哪些内存是可用的,这样在分配的时候可以从列表中查询到足够大的内存分配给对象,并在分配后更新列表记录。
选择哪种分配方式是由 Java 堆是否规整来决定的,而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理的功能决定。
处理并发安全问题
对象的创建在虚拟机中是一个非常频繁的行为,哪怕只是修改一个指针所指向的位置,在并发情况下也是不安全的,可能出现正在给对象 A 分配内存,指针还没来得及修改,对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案:
对分配内存空间的动作进行同步处理(采用 CAS + 失败重试来保障更新操作的原子性);
把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在 Java 堆中预先分配一小块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。哪个线程要分配内存,就在哪个线程的 TLAB 上分配。只有 TLAB 用完并分配新的 TLAB 时,才需要同步锁。通过
-XX:+/-UserTLAB
参数来设定虚拟机是否使用 TLAB。
对象的访问定位
Java 程序需要通过 JVM 栈上的引用访问堆中的具体对象。对象的访问方式取决于 JVM 虚拟机的实现。目前主流的访问方式有句柄和直接指针两种方式。
直接指针:指向对象,代表一个对象在内存中的起始地址。
句柄:可以理解为指向指针的指针,维护着对象的指针。句柄不直接指向对象,而是指向对象的指针(句柄不发生变化,指向固定内存地址),再由对象的指针指向对象的真实内存地址。
句柄访问
Java 堆中划分出一块内存来作为句柄池,引用中存储对象的句柄地址,而句柄中包含了对象实例数据与对象类型数据各自的具体地址信息。
优点:引用中存储的是稳定的句柄地址,在对象被移动(垃圾收集时移动对象是非常普遍的行为)时只会改变句柄中的实例数据指针,而引用本身不需要修改。
直接指针
如果使用直接指针访问,引用中存储的直接就是对象地址,那么 Java 堆对象内部的布局中就必须考虑如何放置访问类型数据的相关信息。
优点:速度更快,节省了一次指针定位的时间开销。由于对象的访问在 Java 中非常频繁,因此这类开销积少成多后也是非常可观的执行成本。HotSpot 虚拟机中采用的就是这种方式。
内存溢出
内存泄漏是指不再被使用的对象或者变量一直被占据在内存中。理论上来说, Java 是有 GC 垃圾回收机制的,也就是说,不再被使用的对象,会被 GC 自动回收掉,自动从内存中清除。但是,即使这样,Java 也还是存在着内存泄漏的情况,Java 导致内存泄露的原因很明确:长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露,尽管短生命周期对象已经不再需要,但是因为 长生命周期对象持有它的引用而导致不能被回收,这就是 Java 中内存泄露的发生场景。
垃圾回收机制
垃圾回收,顾名思义就是释放垃圾占用的空间,从而提升程序性能,防止内存泄露。当一个对象不再被需要时,该对象就需要被回收并释放空间。
Java 内存运行时数据区域包括程序计数器、虚拟机栈、本地方法栈、堆等区域。其中,程序计数器、虚拟机栈和本地方法栈都是线程私有的,当线程结束时,这些区域的生命周期也结束了,因此不需要过多考虑回收的问题。而堆是虚拟机管理的内存中最大的一块,堆中的内存的分配和回收是动态的,垃圾回收主要关注的是堆空间。
调用垃圾回收器的方法
调用垃圾回收器的方法是gc
,该方法在System
类和Runtime
类中都存在。在Runtime
类中,方法gc
是实例方法,方法System.gc
是调用该方法的一种传统而便捷的方法。在System
类中,方法gc
是静态方法,该方法会调用Runtime
类中的gc
方法。其实,java.lang.System.gc
等价于java.lang.Runtime.getRuntime.gc
的简写,都是调用垃圾回收器。方法gc
的作用是提示Java
虚拟机进行垃圾回收,该方法由系统自动调用,不需要人为调用。该方法被调用之后,由Java
虚拟机决定是立即回收还是延迟回收。
finalize 方法
与垃圾回收有关的另一个方法是finalize
方法。该方法在Object
类中被定义,在释放对象占用的内存之前会调用该方法。该方法的默认实现不做任何事,如果必要,子类应该重写该方法,一般建议在该方法中释放对象持有的资源。
可回收对象判断
垃圾收集器在做垃圾回收的时候,首先需要判定的就是哪些内存是需要被回收 的,哪些对象是「存活」的,是不可以被回收的;哪些对象已经「死掉」了,需要被回收。一般有两种方法来判断:
引用计数器法:为每个对象创建一个引用计数,有对象引用时计数器加 1,引用被释放时计数减 1,当计数器为 0 时就可以被回收。它有一个缺点是不能解决循环引用的问题;
可达性分析算法:从 GC Roots 开始向下搜索,搜索所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连时,则证明此对象是可以被回收的。
在 Java 中,GC Roots 一般包含下面几种对象:
- 虚拟机栈中引用的对象
- 本地方法栈中的本地方法引用的对象
- 方法区中的类静态属性引用的对象
- 方法区中的常量引用的对象
四种引用类型
引用计数算法和根搜索算法都需要通过判断引用的方式判断对象是否可回收。
在 JDK 1.2 之后,Java 将引用分成四种,按照引用强度从高到低的顺序依次是:
- 强引用:在程序代码中普遍存在的引用。垃圾回收器永远不会回收被强引用关联的对象。
- 软引用:还有用但并非必需的对象。只有在系统将要发生内存溢出异常时,被软引用关联的对象才会被回收。在 JDK 1.2 之后,提供了
SoftReference
类实现软引用。 - 弱引用:非必需的对象,其强度低于软引用。被弱引用关联的对象只能存活到下一次垃圾回收发生之前,当垃圾回收器工作时,被弱引用关联的对象一定会被回收。在 JDK 1.2 之后,提供了
WeakReference
类实现弱引用。 - 虚引用:最弱的引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知。在 JDK 1.2 之后,提供了
PhantomReference
类实现虚引用。
垃圾回收算法
标记-清除算法
标记-清除算法分为“标记”和“清除”两个阶段,首先标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象。
- 优点:不需要复制对象进行移动,仅对垃圾对象进行处理。
- 缺点:
- 标记和清除的效率都不高。
- 会产生大量不连续的内存碎片,导致程序在之后的运行过程中无法为较大对象找到足够的连续内存。
复制算法
复制算法的将可用内存分成大小相等的两块,每次只使用其中的一块,当用完一块内存时,将存活的对象标记并复制到另外一块内存,然后把已使用过的内存空间一次清理掉。
- 优点:
- 标记和复制可以同时进行。
- 只需移动栈顶指针,按顺序分配内存。
- 不产生内存碎片。
- 缺点:内存使用率只有一半。
标记-整理算法
标记过程与标记-清除算法一样,但后续步骤不是直接回收被标记的对象,而是让所有存活的对象都向内存的一端移动,然后清理边界以外的内存。
- 优点:不产生内存碎片。
- 缺点:需要复制对象。
分代收集算法
分代收集算法根据对象的存活周期不同将内存划分为多个区域,对每个区域选用不同的垃圾回收算法。
一般把 Java 堆内存空间分为新生代和老年代。
新生代(Young Generation):新创建的对象都存放在新生代。
- 新生代内存按照 8:1:1 的比例分为一个 Eden 区和两个 Survivor(Survivor0,Survivor1)区。大部分对象在 Eden 区中生成。
- 当新对象生成,Eden 空间申请失败(因为空间不足等),则会发起一次 GC(Scavenge GC)。回收时先将 Eden 区存活对象复制到一个 Survivor0 区,然后清空 Eden 区,当这个 Survivor0 区也存放满了时,则将 Eden 区和 Survivor0 区存活对象复制到另一个 Survivor1 区,然后清空 Eden 和这个 Survivor0 区,此时 Survivor0 区是空的,然后将 Survivor0 区和 Survivor1 区交换,即保持 Survivor1 区为空, 如此往复。当 Survivor1 区不足以存放 Eden 和 Survivor0 的存活对象时,就将存活对象直接存放到老年代。
- 当对象在 Survivor 区躲过一次 GC 的话,其对象年龄便会加 1,默认情况下,如果对象年龄达到 15 岁,就会移动到老年代中。若是老年代也满了就会触发一次 Full GC,也就是新生代、老年代都进行回收。
- 新生代大小可以由-Xmn来控制,也可以用-XX:SurvivorRatio来控制 Eden 和 Survivor 的比例。
- 大对象直接进入老年代。所谓大对象是指需要大量连续内存空间的对象,频繁出现大对象是致命的,会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。新生代使用的是复制算法,如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。
- 长期存活对象将进入老年代。虚拟机采用分代收集的思想来管理内存,那么内存回收时就必须判断哪些对象应该放在新生代,哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器,如果对象在 Eden 区出生,并且能够被 Survivor 容纳,将被移动到 Survivor 空间中,这时设置对象年龄为 1。对象在 Survivor 区中每经过一次 Minor GC 未被回收则年龄加 1,当年龄达到一个阈值(默认 15)就会被晋升到老年代。
- 动态对象年龄判定。为了能更好地适应不同程序的内存状况,虚拟机并不总是要求对象的年龄必须达到阈值才能进入老年代。如果在
Survivor
区中相同年龄的所有对象的空间总和大于Survivor
区空间的一半,则年龄大于或等于该年龄的对象直接进入老年代。
老年代(Old Generation):
- 在新生代中经历了 N 次垃圾回收后仍然存活的对象,就会被放到年老代中。因此,可以认为年老代中存放的都是一些生命周期较长的对象。
- 内存比新生代也大很多(大概比例是 1:2),当老年代内存满时触发 Major GC 即 Full GC,Full GC 发生频率比较低,老年代对象存活时间比较长,存活率高。
- 一般来说,大对象会被直接分配到老年代。所谓的大对象是指需要大量连续存储空间的对象,最常见的一种大对象就是大数组。当然分配的规则并不是百分之百固定的,这要取决于当前使用的是哪种垃圾收集器组合和 JVM 的相关参数。
永久代被移除,移入元空间(MetaSpace)。
GC 的分类
- 新生代 GC(Minor GC / Scavenge GC):发生在新生代的垃圾收集动作。因为 Java 对象大多都具有朝生夕灭的特性,因此 Minor GC 非常频繁(不一定等 Eden 区满了才触发),一般回收速度也比较快。在新生代中,每次垃圾收集时都会发现有大量对象死去,只有少量存活,因此可选用复制算法来完成收集。
- 老年代 GC(Major GC / Full GC):发生在老年代的垃圾回收动作。Major GC 经常会伴随至少一次 Minor GC。由于老年代中的对象生命周期比较长,因此 Major GC 并不频繁,一般都是等待老年代满了后才进行 Full GC,而且其速度一般会比 Minor GC 慢10倍以上。另外,如果分配了 Direct Memory,在老年代中进行 Full GC 时,会顺便清理掉 Direct Memory 中的废弃对象。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清除”算法或“标记-整理”算法来进行回收。
垃圾回收器
Serial 收集器
新生代单线程垃圾收集器,标记和清理都是单线程,优点是简单高效;复制算法
ParNew 收集器
新生代并行垃圾收集器,是 Serial 的多线程 版本,在多核 CPU 环境下有着比 Serial 更好的表现;复制算法
Parallel Scavenge 收集器
新生代并行垃圾收集器,追求高吞吐量,高效利用 CPU。吞吐量 = 用户线程时间 / (用户线程时间 + GC 线程时间),高吞吐量可以高效率的利用 CPU 时间,尽快完成程序的运算任务,适合后台应用等对交互相应要求不高的场景;复制算法
Serial Old 收集器
老年代单线程垃圾收集器,Serial 的老年代版本;标记-整理算法
Parallel Old 收集器
老年代并行垃圾收集器,吞吐量优先,Parallel Scavenge 的老年代版本;标记-整理算法
CMS 收集器
Concurrent Mark-Sweep
老年代并行垃圾收集器,以获取最短回收停顿时间为目标的收集器,具有高并发、低停顿的特点,追求最短 GC 回收停顿时间。标记-清除算法
CMS 是英文 Concurrent Mark-Sweep 的简称,是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上,这种垃圾回收器非常适合。在启动 JVM 的参数加上-XX:+UseConcMarkSweepGC
来指定使用 CMS 垃圾回收器。CMS 使用的是标记-清除算法,所以在 GC 的时候会产生大量的内存碎片,当剩余内存不能满足程序运行要求时,系统将会出现 Concurrent Mode Failure,临时 CMS 会采用 Serial Old 回收器进行垃圾清除,此时的性能将会被降低。
G1 收集器
Garbage First
Java 堆并行垃圾收集器,G1 收集器是 JDK 1.7 提供的一个新收集器,G1 收集器基于“标记-整理”算法实现,也就是说不会产生内存碎片。此外,G1 收集器不同于之前的收集器的一个重要特点是:G1 回收的范围是整个 Java 堆(包括新生代和老年代)。标记-整理算法
Java 内存分配策略
对象的内存分配通常是在 Java 堆上分配(随着虚拟机优化技术的诞生,某些场景下也会在栈上分配),对象主要分配在新生代的 Eden 区,如果启动了本地线程缓冲(TLAB),将按照线程优先在 TLAB 上分配。少数情况下也会直接在老年代上分配(大对象)。总的来说分配规则不是百分百固定的,其细节取决于哪一种垃圾收集器组合以及虚拟机相关参数有关,但是虚拟机对于内存的分配还是会遵循以下几种「普世」规则:
- 对象优先在 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时,虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间,则将启用分配担保机制在老年代中分配内存。
- Minor GC:发生在新生代中的 GC,因为 Java 对象大多都是朝生夕死,所以 Minor GC 非常频繁,一般回收速度也非常快;
- Major GC/Full GC:发生在老年代的 GC,出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。
类加载机制
虚拟机把描述类的数据从 class 文件加载到内存,并对数据进行校验,解析和初始化,最终形成可以被虚拟机直接使用的 Java 类型。
JVM 加载 class 文件
Java 中的所有类,都需要由类加载器装载到JVM中才能运行。类加载器本身也 是一个类,而它的工作就是把class文件从硬盘读取到内存中。在写程序的时 候,我们几乎不需要关心类的加载,因为这些都是隐式装载的,除非我们有特殊的用法,像是反射,就需要显式的加载所需要的类。类装载方式,有两种:
隐式装载。程序在运行过程中当碰到通过 new 等方式生成对象时,隐式调用 类装载器加载对应的类到 JVM 中。
显式装载。通过
Class.forName()
等方法,显式加载需要的类。
Java 类的加载是动态的,它并不会一次性将所有类全部加载后再运行,而是保证程序运行的基础类(像是基类)完全加载到 JVM 中,至于其他类,则在需要的时候才加载。这当然就是为了节省内存开销。
类加载器
实现通过类的全限定名获取该类的二进制字节流的代码块叫做类加载器。 主要有一下四种类加载器:
启动类加载器(Bootstrap ClassLoader)用来加载 Java 核心类库,无法被 java程序直接引用。
扩展类加载器(extensions class loader): 它用来加载 Java 的扩展库。 Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
系统类加载器(system class loader):它根据 Java 应用的类路径 (CLASSPATH )来加载 Java 类。一般来说,Java 应用的类都是由它来 完成加载的。可以通过
ClassLoader.getSystemClassLoader()
来获取它。用户自定义类加载器,通过继承 java.lang.ClassLoader类的方式实现。
类装载的执行过程
类装载分为以下 5个步骤:
- 加载:根据查找路径找到相应的 class 文件然后导入;
- 验证:检查加载的 class 文件的正确性;
- 准备:给类中的静态变量分配内存空间;
- 解析:虚拟机将常量池中的符号引用替换成直接引用的过程。符号引用就理解为 一个标示,而在直接引用直接指向内存中的地址;
- 初始化:对静态变量和静态代码块执行初始化工作。
双亲委派模型
在介绍双亲委派模型之前先说下类加载器。对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性,每一个类加载器,都有一 个独立的类名称空间。类加载器就是根据指定全限定名称将 class 文件加载到 JVM 内存,然后再转化为 class 对象。
类初始化顺序
Java 中的静态变量和静态代码块是在类加载的时候就执行的,实例化对象时,先声明并实例化变量再执行构造函数。如果子类继承父类,则先执行父类的静态变量和静态代码块,再执行子类的静态变量和静态代码块。同样,接着在执行父类和子类非静态代码块和构造函数。
- 未创建对象(只执行一次)
- 加载类信息。
- 父类的静态属性和静态代码块,按顺序执行。
- 子类的静态属性和静态代码块,按顺序执行。
- 创建对象(每创建一个对象,执行一次)
- 父类的非静态属性和构造代码块,按顺序执行。
- 父类的构造方法。
- 子类的非静态属性和构造代码块,按顺序执行。
- 子类的构造方法。
当访问
static final
修饰的属性时,若属性是常量(基本类型或字符串),则在编译阶段通过常量传播优化,将常量存到调用类的常量池中。所以,访问该属性时直接从常量池中访问,而无需加载对应类。