深入理解Java虚拟机笔记(1、2、3章)

 2019-12-22 10:42  阅读(577)
文章分类:JVM

自己絮絮叨叨的一些废话

这本书真是神作,很少读过国内作者写的如此精确易懂的技术书籍。
我感觉,作为一名Java程序员,是一定要知道、了解进而掌握JVM的,毕竟是Java知识体系的核心所在。然而,刚刚接触Java的时候,一听什么Java虚拟机,就感觉离自己好远好深奥好高大上,我等菜鸟应该是这辈子都不能懂这种东西了。所谓难者不会,想必就是这个道理。
入行了一年多,感觉如果整天都只能做那些CURD的东西,估计这辈子都成为不了一名真正的程序员了。所以便买了这本风评很好的书,准备硬着头皮去拜读一番。那曾料到,这本书是如此的通俗易懂,由浅入深,从Java虚拟机的发展史(第一章)讲起,介绍了Java的内存管理(第二章)、垃圾收集与内存分配(第三章)、Java虚拟机内存调优(第五章),随后介绍了类文件结构,也就是教你怎么看编译后的class文件(第六章)、虚拟机类加载机制(第七章)和字节码执行引擎(第八章),再到程序的编译与代码优化(第九、十章),最后讲解了一些高效并发的知识(第十二、十三章)。看了一遍之后,确实对于Java虚拟机有了一定的了解,让我感觉不是那么陌生,不过还谈不上书名所说的深入理解,更远远达不到会者不难的境界。不过这本书一刷也是收获颇丰的,因此决定二刷巩固一下知识点,并做好笔记,便于以后的复习和知识点搜索。也希望,自己能够尽量提炼出这本书的核心部分,如果能把知识提炼出来并能让其他人看懂,才是真正的掌握了知识点吧。

约定

正常字体为知识点总结
斜体为阅读指南,以及小白的解读
下划线为重点部分

引用则是原作者的大段文字引用

第一章 走进Java

本章主要讲述了Java的技术体系、Java发展历程以及Java虚拟机的发展历程,算是对Java虚拟机的背景了解。

Java技术体系

sun官方定义的Java技术体系包括:

  • Java程序设计语言
  • 各种硬件平台上的Java虚拟机
  • class文件格式
  • Java API类库
  • 来自商业机构和开源社区的第三方Java类库

JDK:Java编程语言、Java虚拟机、Java API类库三部分统称
JRE:Java虚拟机、Java SE API

Java发展史

本小结介绍了Java的发展史,简单阅读了解即可。

Java虚拟机发展史

本小结介绍了Java虚拟机的发展史,基本把大大小小的虚拟机都介绍了一遍,我们主要看看三大虚拟机吧

  • Sun HotSpot VM
    Sun JDK和Open JDK中所带的虚拟机,是当前最广泛应用的虚拟机
  • BEA JRockit
    号称世界上最快的虚拟机,专注于服务器端应用,不在意程序启动速度,因此内部不包含解析器实现,全部代码靠及时编译器编译后执行。
  • IBM J9 VM
    IBM主力发展的虚拟机,一款多用途虚拟机

展望Java技术的未来

  • 模块化
    解决应用系统与技术平台越来越复杂,越来越庞大问题的重要途径。未来的Java平台中,可能会对模块化提出语法层面的支持。比如Jigsaw
  • 混合语言
    单一的Java开发不能满足当前软件的复杂需求时,越来越多基于Java虚拟机的语言开发被应用到软件项目中。比如Python的Jython,Ruby的JRuby。实际上就是将这些语言的源代码也编译成class字节码,就可以再Java虚拟机里运行了。
  • 多核并行
    如Fork/Join模式;Lambda支持使Java更容易使用函数式编程,进而适合并行运行
  • 进一步丰富语法
    比如Java5的扩充,未来还会在大版本上进行扩充
  • 64位虚拟机

实战:自己编译JDK

有兴趣的朋友可以按照书上的教程自己编译一下,感受一下

第二章 Java内存区域与内存溢出异常

本章主要介绍了Java虚拟机内存的各个区域,这些区域的作用、服务对象以及其中可能产生的问题,从而让大家知道,虚拟机是怎么使用内存的

运行时数据区域

Java虚拟机在执行Java程序时的过程中,会把他管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途,以及创建和销毁时间,有的区域随着虚拟机进程的启动而存在,有些区域则依赖用户线程的启动和结束而建立和销毁。

1、程序计数器

其实就像名字所说一样,他就是用于程序运行时计数的,记住字节码执行到了哪里
程序计数器是一块小的内存空间,可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型中,字节码解释器工作时,就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现,一个时刻一个处理器都只会执行一个线程的指令。因此,为了线程切换后能恢复到正确的执行位置,每一个线程都有一个独立的程序计数器,各个线程的计数器互不影响独立存储。
这类内存区域称为“线程私有”的内存。

2、Java虚拟机栈

一个栈,执行Java方法时将方法入栈,执行结束后就出栈。每一个栈帧保存一些信息,8.2小结有详细介绍
线程私有,生命周期与线程一致。
虚拟机栈描述的是Java方法执行的内存模型:

每个方法在执行的同时都会创建一个栈帧,用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

这个区域有两种异常状况:

  • 线程请求的栈深度大于虚拟机允许的深处,抛出StackOverflowError异常。
  • 虚拟机栈动态扩展时,无法申请到足够的内存,则抛出OutOfMemoryError异常

3、本地方法栈

与虚拟机栈类似,虚拟机栈是为执行Java方法服务,本地方法栈是为虚拟机使用到的Native方法服务。
也会抛出虚拟机栈的两个异常
什么是Native方法呢?一个Native Method是这样一个java的方法:该方法的实现由非java语言实现。具体可以看这个链接Java的native方法

4、Java堆

Java堆是Java虚拟机所管理的内存中最大的一块区域。Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。
此区域的唯一目的:存放对象实例,几乎所有的对象实例都在这里分配内存。
Java堆是垃圾收集器管理的主要区域,有时也被称为GC堆。从内存回收的角度看,由于现在收集器基本都采用分代收集算法,所以可以分为:新生代和老年代。垃圾收集器3.5节有详细介绍
Java堆可以处于物理上不连续的内存空间,只要逻辑上连续即可。堆可以固定大小也可以扩展的(通过-Xmx和Xms控制),如果堆中没有完成内存分配且无法继续扩展时,将会抛出OutOfMemoryError异常。

5、方法区

也是线程共享。
用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
方法区可以处于物理上不连续的内存空间,只要逻辑上连续即可。可以固定大小也可以扩展,还可以选择不实现垃圾收集。该区域的内存回收目标主要是针对常量池的回收和对类型的卸载。
方法区无法满足内存分配需求时,抛出OutOfMemoryError异常。

5.1、运行时常量池

方法区的一部分。类加载后进入方法区运行,class文件中的常量池信息将存在运行时常量池。另一个重要特征是具备动态性:运行期间也可以将常量放入池中。

X、直接内存

并不是虚拟机规范中定义的内存区域,但是这部分内存也会被频繁使用,也可以导致OutOfMemoryError异常。

HotSpot虚拟机对象

本节以常用的虚拟机HotSpot和常用的内存区域Java堆为例,深入探讨HotSpot虚拟机在Java对中对象分配、布局和访问的全过程

对象的创建

在语言层面上,创建对象仅仅是一个new关键字而已。
虚拟机里创建对象的过程如下:

第一步,检查是否已经加载

检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有,则必须先执行相应的类加载过程。第七章会有详细介绍

第二步,为新生对象分配内存,在Java堆划分一块内存

这里分为两种情况:

  1. 如果Java堆的内存是绝对规整的,则使用内存碰撞的分配方式,将指针向空闲部分方向移动一个对象大小的位置。
  2. 如果Java堆的内存不是规整的,则使用空闲列表分配凡是,即虚拟机必须维护一个列表,记录哪些内存块是可用的,在分配时找到一块足够大的空间划分给对象实例。
第三步,初始化零值

内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用。

第四步,对对象进行必要设置

例如这个对象是哪个类的实例、如何找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息,存放在对象的对象头中。

第五步,执行方法

对象的内存布局

对象在内存中存储的布局可以分为3块区域:对象头、实例数据和对其填充。

对象头

对象头包含两部分信息

  1. 存储对象自身的运行时数据。如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
  2. 类型指针,即对象指向他的类元数据的指针。虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都会在对象数据上保留类型指针。下文所说的使用句柄定位的方式的虚拟机就不需要保留类型指针。

其实对象头的这些信息,就应该是虚拟机创建对象过程中第四步生成的吧

实例数据

实例数据部分是对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。

对齐填充

这部分不是必然存在的,仅仅是起着占位符的作用。因为HotSpot的自动内存管理系统要求内存起始地址必须是8字节的整数倍,所以在没有对齐时就要用对齐填充来补全。

对象的访问定位

Java程序需要通过栈上的reference数据来操作堆上的具体对象。reference类型在Java虚拟机规范中之规定了一个指向对象的引用,对象的访问方式有两种,使用句柄和直接指针。

使用句柄

Java堆需要划分出一块内存作为句柄池,reference中存储的就是对象的句柄地址,句柄中包含了对象实例数据与类型数据各自的具体地址信息。其实就是一种间接的访问方式
优点:reference中存储的是稳定的句柄地址。

直接指针

Java堆对象的布局中要考虑如何防止访问类型数据的相关信息,reference中存储的直接就是对象地址。然后可以通过对象头中的类型指针找到方法区的类型数据。
优点:直接访问速度快。

OutOfMemoryError异常

Java堆溢出

只要不断创建对象,并且避免垃圾回收机制,对象数据达到最大堆容量限制后就会产生。抛出异常后会进一步提示“Java heap space”。
解决方式:对Dump出来的堆转储快照进行分析(通过参数-XX:HeapDumpOnOutOfMemoryError设置成出现内存溢出则Dump出),确认内存中的对象是否为必要的,也就是要区分是内存泄露还是内存溢出。
内存泄露:内存未释放活无法释放,所以要查看泄露对象到GC Roots的引用链,找到是如何关联导致垃圾收集器无法自动回收。
内存溢出:没有足够的内存,对象确实都必须存活,则需要检查虚拟机的堆参数(堆的最大值-Xmx与堆的最小值-Xms)。

虚拟机栈和本地方法栈溢出

-Xss参数设定虚拟机栈容量,-Xoss设定本地方法栈容量,但是HotSpot虚拟机并不区分虚拟机栈和本地方法栈,所以只设置-Xss即可。

  • 线程请求的栈深度大于虚拟机所允许的最大深度,则抛出StackOverflowError异常
  • 虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常

单个线程下,抛出的都是StackOverflowError异常。如果不断的建立线程则可以产生内存溢出异常。
多线程导致的内存溢出,之鞥通过减少最大堆和减少栈容量获取更多的线程。

方法区和运行时常量池溢出

通过-XX:PermSize=10m —XX:MaxPermSize=10m限制方法区大小。
运行时常量池溢出会跟随“PermGen space”信息。

本机直接内存溢出

通过-XX:MaxDirectMemorySize指定。一个明显的特征是Dump文件中不会看到明显的异常。

第三章 垃圾收集器与内存分配策略

概述

程序计数器、Java虚拟机栈、本地方法栈三个区域随进程而生,随进程而灭。每一个栈帧分配的内存大小在类结构确定时就已经确定了。即内存的分配和回收都具备确定性,不需要过多考虑。而Java堆和方法区内存的分配和回收都是动态的,只有程序处于运行状态期间才会知道要创建哪些对象,所以垃圾收集器关注的是这部分。

对象已死吗?

垃圾收集器在对堆进行回收之前,要确定哪些对象是存活的,哪些是死去的。实际上就是看这些对象是不是还会被用到,本节介绍几种判断对象是否存活的方法

引用计数法

并不是主流虚拟机使用的方法
给对象中添加一个引用计数器,每当有一个地方引用他时,计数器就加1,当引用失效时,计数器就减1,任何时刻计数器为0的对象就是不可能再被使用的。
引用计数法实现简单,判定效率也高,之所以没有被主流虚拟机使用,是因为很难解决对象之间相互循环引用的问题。如果两个对象相互引用对方,而没有其他对象引用,但是也会使计数器不为0

可达性分析算法

基本思路:通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链,当一个对象到GC Roots没有任何引用链相连(GC Roots到这个对象不可达),则证明此对象是不可用的。

可作为GC Roots节点的对象包括以下几种:

  • 虚拟机栈中引用的对象
  • 方法区中类静态属性引用的对象
  • 方法去中常量引用的对象
  • 本地方法栈中JNI(Native方法)引用的对象

引用的四种类型

两种判断对象是否存活的方式,实际上都是看对象是否被引用。JDK1.2之后,引用根据引用强度被分为以下四种:

  • 强引用:程序中普遍存在的如Object obj = new Object()的这类引用,只要强引用存在,垃圾回收器永远不会回收掉被引用的对象。
  • 软引用:描述还有用但是非必须的对象。在系统将要发生内存溢出异常之前,将会吧这些对象列进回收范围之中进行第二次回收。
  • 弱引用:描述非必须的对象,垃圾收集器工作时,无论当前内存是否足够,都会回收掉只被弱引用关联的对象。
  • 虚引用:其实一点存在感都没有。为一个对象设置为虚引用的唯一目的是在这个对象被收集器回收时收到一个系统通知。

生存还是死亡

真正宣告一个对象的死亡,至少需要经历两次标记过程。
第一次:可达性分析后,发现没有与GC Roots相连接的引用链,则会被第一次标记并且进行一次筛选,看此对象是否有必要执行finalize()方法。如果对象没有覆盖finalize()方法,或者该方法已经被虚拟机调用,则虚拟机会认定没有必要执行finalize方法。如果被判定有必要执行finalize方法,则这个对象会被放置在一个叫做F-Queue的队列中,并在稍后由一个虚拟机自动建立的、低优先级的finalizer线程去执行(触发这个方法)。稍后GC将会对F-Queue中的对象进行第二次小规模的标记,然后进行回收。所以finalize()方法是对象逃脱死亡命运的最后一次机会,只要在finalize()方法中重新与引用链上的任一一个对象建立关联即可。这样第二次标记时便会将其移除即将回收的集合。任何一个对象的finalize方法只能执行一次。

回收方法区

Java虚拟机规范中说可以不对方法区进行垃圾回收,而且方法区中的垃圾回收效率比较低。
永久代的垃圾收集主要走啊回收两个部分:废弃常量和无用的类。

回收废弃常量

与Java堆中的回收对象类似,没有其他地方引用这个字面量,则会被系统清理出常量池。

判断是否为无用的类

需要满足三个条件:

  • 该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例
  • 加载该类的ClassLoader已经被回收
  • 该类对应的java.lang.Class对象没有在任何地方呗引用,无法在任何地方通过反射访问该类的方法

即便是满足以上几点,也不一定是必然会回收

垃圾收集算法

主要介绍集中算法的思想和发展过程

1、标记-清除算法

最基础的算法,之所以说是最基础的是因为其他的算法都是基于这个思路并对其不足进行改进。分为标记和清除两个部分。

  1. 首先标记所有需要回收的对象
  2. 标记完成后统一回收

主要不足:

  1. 效率问题,标记和清除的效率都不高
  2. 空间问题,会产生大量的内存碎片,导致以后程序需要分配较大对象时找不到合适的空间。从而不得不提前出发一次GC

2、复制算法

将可用内存划分为大小相同的两块,每次只用一块。当这一块用完后,将存活的对象复制到另一块,然后将已使用过的内存一次清理掉。这样每次对整个半区进行回收,不用考虑内存碎片的问题。
不足:将内存缩小为原来的一半,代价较高。
现代的商业虚拟机都使用这种算法回收新生代,不同之处在于,是将内存分为一块较大的Eden空间和两块较小的survivor空间,每次使用Eden和一块survivor。GC时,将Eden和survivor中存活的对象复制到另一块survivor上,然后清理掉之前的Eden和survivor。当survivor空间不够时,需要依赖其他内存进行分配担保,即这些对象直接进入老年代。后面的章节会讲到
HotSpot默认Eden与survivor空间比为8:1

3、标记-整理算法

对象存活率较高的时候,将会进行较多的复制操作,这样会降低效率。
该算法第一步也是标记需要回收的对象,之后让所有存活的对象都向内存一端移动,然后直接清理掉端边界以外的内存。

4、分代收集算法

当前商业虚拟机都是采用分代收集。
根据对象存活周期的不同将内存分为几块:新生代和老年代。这样可以根据各个年代的特点采用最适当的收集算法。

  • 新生代:大批对象死去,少量存活,所以使用复制算法。
  • 老年代:对象存活率高,没有额外空间进行分配担保,所以使用标记-清理或标记-整理算法。

HotSpot的算法实现

枚举根节点

例子:可达性分析从GC Roots节点找引用链。
如果在方法区中逐个检查引用,则会消耗很多的时间。另外,可达性分析对执行时间的敏感性还体现在GC停顿上:这项分析工作必须在一个能确保一致性的快照中进行。
一致性:整个分析期间整个执行系统看起来就像冻结在某一个时间点上,不可以出现分析过程中对象的引用关系还在不断变化的情形。这是导致GC进行时必须停顿所有Java执行线程(stop the world)的重要原因。
目前主流的Java虚拟机都是使用的准确式GC。HotSpot使用一组称为OopMap的数据结构保存哪些地方存在着对象引用,从而避免系统检查所有执行上下文和全局的引用位置。在类加载完成的时候,HotSpot吧对象内什么偏移量上是什么类型的数据计算出来,在JIT编译过程中也会特定位置记录下栈和寄存器中哪些位置是引用。

安全点

线程到达安全点才可以GC
HotSpot没有为每一条指令都生成OopMap,而是在特定的位置记录了这个信息,这些位置称为安全点。程序只有到达了安全点才可以暂停。

safepoint的选定,既不能太少以至于让GC等待时间台城,也不能过于频繁以至于过分增大运行时的负荷,所以安全点的选定基本上是以“是否具有让程序长时间执行的特征”为标准选定的。

如何在GC发生是让所有的线程都跑到安全点?这里有两个方案:

  1. 抢先式中断:GC发生时,中断全部线程,如果有线程没有到安全点则放开他让他到安全点。现在已经没有虚拟机使用这种方式了。
  2. 主动式中断:GC需要中断时,不直接对线程操作,而是设置一个标志,各个线程主动轮询这个标识,发现中断标识为真时就自己中断挂起。轮训标志的地方和安全点是重合的。

安全区域

当程序“不执行”,即没有分配CPU时间,比如处于sleep和Blocked状态,这时候线程就无法响应JVM的中断请求,这种问题需要安全区域解决。
安全区域是指在一段代码中,引用关系不会发生变化,可以看做为扩展的安全点。
线程执行到安全区域时,首先标识自己进入了安全区域,当发生GC时,JVM就不会管这部分线程。当线程离开安全区域时,要检查系统是否完成了根节点枚举,完成了就继续执行,否则要等待可以安全离开的信号。

垃圾收集器

1、Serial收集器

  • 单线程、新生代
  • 最基本、发展历史最悠久,JDK1.3之前的唯一选择
  • 进行垃圾收集时,必须暂停其他所有工作线程,知道收集结束
  • client模式下的默认新生代收集器
  • 优点:简单高效

2、ParNew收集器

  • Serial的多线程版本、新生代
  • Server模式下首选的新生代收集器

3、Parallel Scavenge收集器

  • 多线程、新生代
  • 特点:关注点与其他收集器不同,关注吞吐量。其他收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge目标是达到一个可控制的吞吐量。吞吐量:运行用户代码时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾回收时间)
  • 适合后台运算而不需要太多交互的任务

4、Serial Old收集器

  • 单线程、老年代
  • Serial的老年代版本

5、Parallel Old收集器

  • 多线程、老年代
  • Parallel Scavenge的老年代版本

6、CMS收集器

  • 获取最短回收停顿时间为目标的收集器

  • 基于“标记-清除”算法实现

  • 四个步骤

    • 初始标记:只是标记一下GC Roots能直接关联到的对象
    • 并发标记:GC Root Tracing的过程
    • 重新标记:修正并发标记期间因用户程序继续运行导致标记变动的那一部分
    • 并发清除
  • CMS收集器的内存回收过程是与用户线程一起并发执行

  • 缺点:1、对CPU资源非常敏感。2、无法处理浮动垃圾,即伴随程序运行时会产生的新的垃圾,这些垃圾出现在标记过程之后,只能下次GC处理。3、标记清除的本身问题

7、G1收集器

当今收集器技术发展的最前沿成果
特点:

  • 并行与并发:充分利用多CPU多核环境
  • 分代收集
  • 空间整合:整体看是“标记-整理”,各部分是复制算法
  • 可预测的停顿

将整个Java堆分为多个大小相等的独立区域,并保留新生代和老年代的概念。
运作步骤:

  • 初始标记
  • 并发标记
  • 最终标记
  • 筛选回收

理解GC日志

后续找一个日志来分析吧

内存分配与回收策略

Java体系中提倡的自动管理内存可以归结为自动化的解决两个问题:

  1. 给对象分配内存
  2. 回收分配给对象的内存

对象优先在Eden分配

大多数情况下,对象在新生代Eden区分配。如果Eden区没有足够空间进行分配,则将进行一次GC。

  • 新生代GC(Minor GC):发生在新生代的GC,非常频繁
  • 老年代GC(Major GC/Full GC):发生在老年代的GC,速度比Minor GC慢十倍以上

大对象直接进入老年代

大对象:需要大量连续内存空间的对象。可以避免大对象在Eden区和两个Survivor区来回复制。

长期存活的对象将进入老年代

虚拟机给每一个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活,则移动到Survivor区,年龄设为1。之后每熬过一次Minor GC都会成长一岁,当年龄到达一定程度(默认15岁),便会晋升老年代。

动态对象年龄判定

如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代。

空间分配担保

发生Minor GC之前,虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果成立则Minor GC确保安全。如果不成立,则虚拟机查看HandlePromotionFailure设置值是否允许担保失败。如果允许则继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小(这是一种动态概率的手段),如果大于则尝试进行一次Minor GC,这是有风险的。如果小于,则改为进行一次Full GC。

点赞(0)
版权归原创作者所有,任何形式转载请联系作者; Java 技术驿站 >> 深入理解Java虚拟机笔记(1、2、3章)

相关推荐