note

提前编译是相对于即时编译的概念，提前编译能带来的最大好处是 Java 虚拟机加载这些已经预编译成二进制库之后就能够直接调用，而无须再等待即时编译器在运行时将其编译成二进制机器码。理论上，提前编译可以减少即时编译带来的预热时间，减少 Java 应用长期给人带来的“第一次运行慢”的不良体验，可以放心地进行很多全程序的分析行为，可以使用时间压力更大的优化措施。
但是提前编译的坏处也很明显，它破坏了 Java“一次编写，到处运行”的承诺，必须为每个不同的硬件、操作系统去编译对应的发行包；也显著降低了 Java 链接过程的动态性，必须要求加载的代码在编译期就是全部已知的，而不能在运行期才确定，否则就只能舍弃掉已经提前编译好的版本，退回到原来的即时编译执行状态

可以这样理解，我们写的代码是 Java 代码，后缀为 .java，经过编译，打成 jar 包，jar 包内都是 .java 编译成的 .class 文件，把 jar 包放到不同的平台之后，再通过当前平台安装的 JVM 来解析 .class 文件，将其编译成平台对应的机器码，然后再被 JVM 执行，Java 的口号一次编译，到处运行，指的是将 .java 编译成的 .class 文件，然后 .class 文件是可以到处运行的。

这个问题，我们在学习 Python 的时候，在《基本概念》小节中学习过。其中有一部分内容讲得其实是 JVM，可以挪到这里来

Graal VM 支持 AOT，编译。

自己编译 JDK

这里以 JDK12 为例，

官网 jdk/jdk12: log

点击 browse 查看源码结构

点击 zip 下载源码为 zip，目标环境为 Linux，上传到 /opt/jdk_12 目录下，然后直接 unzip -d ./ jdk12-06222165c35f.zip。

安装 GCC

apt-get install build-essential

不过 Ubuntu 中一般都自带了 GCC

GCC（GNU Compiler Collection，GNU 编译器套件）是由 GNU 开发的编程语言译器。GCC 的初衷是为 GNU 操作系统专门编写的一款编译器。

GNU 编译器套件包括 C、C++、Objective-C、Fortran、Java、Ada 和 Go 语言前端，也包括了这些语言的库（如 libstdc++，libgcj 等。）

gcc 是拿来编译各种源代码的软件，比如在写代码的时候，需要编译才能运行。

gcc 的作用就是将在 linux 中的源代码软件进行编译后，然后变成可执行的运行程序，进行安装，就相当于 windows 下的 setup 安装程序一样。

如何查看是否安装了 gcc，输入 gcc -v，如果安装了会提示相关信息，如果没有安装会提示没有找到。

再安装 OpenJDK12 的依赖

sudo apt-get install libfreetype6-dev

sudo apt-get install libcups2-dev

sudo apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev

sudo apt-get install libasound2-dev

sudo apt-get install libffi-dev

sudo apt-get install autoconf

先安装一个老版本的 JDK

apt-get install openjdk-11-jdk

然后开始配置编译参数，在 JDK 的解压路径下有一个配置工具 configure，通过以下命令可以查看配置项

bash configure --help

简单配置，编译 FastDebug 版、仅含 Server 模式的 HotSpot 虚拟机，命令应为

bash configure --enable-debug --with-jvm-variants=server

最后两行提示

configure: error: Could not find required tool for ZIPEXE
configure exiting with result code 1

这是因为没有 zip 工具

apt install zip

再次执行，报错

configure: error: Could not find fontconfig! You might be able to fix this by running 'sudo apt-get install libfontconfig1-dev'.
configure exiting with result code 1

按照提示执行

apt-get install libfontconfig1-dev

然后输出

====================================================
A new configuration has been successfully created in
/opt/jdk_12/jdk12-06222165c35f/build/linux-x86_64-server-fastdebug
using configure arguments '--enable-debug --with-jvm-variants=server'.

Configuration summary:
* Debug level: fastdebug
* HS debug level: fastdebug
* JVM variants: server
* JVM features: server: 'aot cds cmsgc compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc'
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
* Version string: 12-internal+0-adhoc.root.jdk12-06222165c35f (12-internal)

Tools summary:
* Boot JDK: openjdk version "11.0.22" 2024-01-16 OpenJDK Runtime Environment (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1) OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1, mixed mode, sharing) (at /usr/lib/jvm/java-11-openjdk-amd64)
* Toolchain: gcc (GNU Compiler Collection)
* C Compiler: Version gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (at /usr/bin/gcc)
* C++ Compiler: Version g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (at /usr/bin/g++)

Build performance summary:
* Cores to use: 15
* Memory limit: 15858 MB

The following warnings were produced. Repeated here for convenience:
WARNING: C and C++ compiler have different version numbers, gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vs g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE..
WARNING: This typically indicates a broken setup, and is not supported
WARNING: You are using gcc older than 4.8. This is not a supported configuration.
WARNING: C and C++ compiler have different version numbers, gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. vs g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE..
WARNING: This typically indicates a broken setup, and is not supported

可以开始编译了，

make images

但是报错，

Ubuntu 22.04 64 位编译 OpenJDK12 - 掘金

修改

DependOnVariableHelper =
$(strip
$(eval $1_filename := $(call DependOnVariableFileName, $1, $2))
$(if $(wildcard $($1_filename)), $(eval include $($1_filename)))
$(if $(call equals, $(strip $($1)), $(strip $($1_old))),,
$(call MakeDir, $(dir $($1_filename)))
$(if $(findstring $(LOG_LEVEL), trace),
$(info NewVariable $1 :>$ (strip $($1))<)
$(info OldVariable $1 :>$ (strip $($1_old))<))
$(call WriteFile, $1_{o} l d :=$ (call DoubleDollar, $(c a l l E s c a p e H a s h,$ ($1))),
$($1_filename)))
$($1_filename)
)

再次编译即可，依然报错，TODO

编译结果清理命令

make clean

make dist-clean

编译始终不成功，拉倒，不再在这里浪费时间，Ubuntu 22.04 64 位编译 OpenJDK12 - 掘金这篇博客的环境跟我一模一样，也是 Ubuntu 22.04 64 位编译 OpenJDK12，按照这篇博客中的修改环境，应该就能编译成功，我懒得搞了。

后面还有安装 CLion 来调试 OpenJDK 的源码的操作，我这里也懒得搞了

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

对于 Java 程序员来说，在虚拟机自动内存管理机制的帮助下，不再需要为每一个 new 操作去写配对的 delete/free 代码，不容易出现内存泄漏和内存溢出问题，看起来由虚拟机管理内存一切都很美好。不过，也正是因为 Java 程序员把控制内存的权力交给了 Java 虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那排查错误、修正问题将会成为一项异常艰难的工作。

以上这个图标代表的是 Java 虚拟机的运行时数据区域，更多的是一种概念设计，具体实现还得看具体的 jvm 虚拟机，实际上，不同的虚拟机实现，在各个区域的具体实现可能不同，

Java 虚拟机说白了就是一个操作系统进程，在创建这个进程的时候，会在内存中分配一部分空间给这个进程，然后 Java 虚拟机把这个分配给他的内容空间分成以上几个部分

记住这个图。

多线程下的

程序计数器（Program Counter Register）

在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

之前我们在多线程里学 Lock 接口的时候，学习了 await、notify 方法，线程在 await 了之后再次被 notify 唤醒。会从上一次 await 的地方继续往后执行。实际上就运用到了程序计数器。

Java 虚拟机栈（Java Virtual Machine Stack）

虚拟机栈描述的是 Java 方法执行的线程内存模型：每个方法被执行的时候，Java 虚拟机都会同步创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

与程序计数器一样，Java 虚拟机栈（Java Virtual Machine Stack）也是线程私有的，它的生命周期与线程相同。

虚拟机栈中局部变量表部分

局部变量表存放了编译期可知的各种 Java 虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）和 returnAddress 类型（指向了一条字节码指令的地址）。

我们在 IDEA 中调试的时候，可以看到完整的调用栈，切换到指定的栈之后，可以看到在这一层中的局部变量，这些信息实际上都是保存在 Java 虚拟机栈（Java Virtual Machine Stack）中。

本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务

由于 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此对于 HotSpot 来说，-Xoss 参数（设置本地方法栈大小）虽然存在，但实际上是没有任何效果的，栈容量只能由 -Xss 参数来设定

Java 堆

对于 Java 应用程序来说，Java 堆（Java Heap）是虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java 世界里“几乎”所有的对象实例都在这里分配内存。

Java 堆是垃圾收集器管理的内存区域，因此一些资料中它也被称作“GC 堆”（Garbage CollectedHeap，幸好国内没翻译成“垃圾堆”）

垃圾收集（GC）仅针对 Java 堆

GC：Garbage Collection 垃圾收集。这里所谓的垃圾指的是在系统运行过程当中所产生的一些无用的对象，这些对象占据着一定的内存空间，如果长期不被释放，可能导致 OOM(堆溢出)。

内存区域中的程序计数器、虚拟机栈、本地方法栈这 3 个区域随着线程而生，线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈的操作，每个栈帧中分配多少内存基本是在类结构确定下来时就已知的。在这几个区域不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了。而Java 堆和方法区则不同，一个接口中的多个实现类需要的内存可能不同，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，GC 关注的也是这部分内存，如果涉及到“内存”分配与回收也仅指着一部分内存。

从回收内存的角度看，由于现代垃圾收集器大部分都是基于分代收集理论设计的，所以 Java 堆中经常会出现“新生代”“老年代”“永久代”“Eden 空间”“From Survivor 空间”“To Survivor 空间”等名词，这些概念在本书后续章节中还会反复登场亮相，在这里笔者想先说明的是这些区域划分仅仅是一部分垃圾收集器的共同特性或者说设计风格而已，而非某个 Java 虚拟机具体实现的固有内存布局，更不是《Java 虚拟机规范》里对 Java 堆的进一步细致划分。

这一点很重要

不过无论从什么角度，无论如何划分，都不会改变 Java 堆中存储内容的共性，无论是哪个区域，存储的都只能是对象的实例，将 Java 堆细分的目的只是为了更好地回收内存，或者更快地分配内存。

确定基调

Java 堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的，这点就像我们用磁盘空间去存储文件一样，并不要求每个文件都连续存放。但对于大对象（典型的如数组对象），多数虚拟机实现出于实现简单、存储高效的考虑，很可能会要求连续的内存空间。

Java 堆既可以被实现成固定大小的，也可以是可扩展的，不过当前主流的 Java 虚拟机都是按照可扩展来实现的（通过参数 -Xmx 和 -Xms 设定）。如果在 Java 堆中没有内存完成实例分配，并且堆也无法再扩展时，Java 虚拟机将会抛出 OutOfMemoryError 异常

动态拓展实际上就是我们定义的 jvm 内存参数中，设置了一个起始内存大小和最大内存大小，当起始内存大小不够用了，再扩展内存，但是不能超过最大内存大小。

方法区

方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

说到方法区，不得不提一下“永久代”这个概念，尤其是在 JDK 8 以前，许多 Java 程序员都习惯在 HotSpot 虚拟机上开发、部署程序，很多人都更愿意把方法区称呼为“永久代”（PermanentGeneration），或将两者混为一谈。本质上这两者并不是等价的，

原则上如何实现方法区属于虚拟机实现细节，不受《Java 虚拟机规范》管束，并不要求统一。JDK 8 中终于完全废弃了永久代的概念，改用在本地内存（Native Memory）中实现的元空间（Metaspace）来代替

运行时常量池

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

直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是《Java 虚拟机规范》中定义的内存区域。但是这部分内存也被频繁地使用，而且也可能导致 OutOfMemoryError 异常出现，所

以我们放到这里一起讲解。

在 JDK 1.4 中新加入了 NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆里面的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据。

NIO 快的原因

但是这部分数据用多了，也会造成内存不足，具体原因看原文。

看到

HotSpot 虚拟机对象探秘

基于实用优先的原则，笔者以最常用的虚拟机 HotSpot 和最常用的内存区域 Java 堆为例，深入探讨一下 HotSpot 虚拟机在 Java 堆中对象分配、布局和访问的全过程。

一个经典面试题，当我们在执行 new XXX() 的时候，到底做了什么

当 Java 虚拟机遇到一条字节码 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程，本书第 7 章将探讨这部分细节。（第 7 章虚拟机类加载机制）

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定（如何确定将在 2.3.2 节中介绍），为对象分配空间的任务实际上便等同于把一块确定大小的内存块从 Java 堆中划分出来。

Java 堆内存的分配方式，一般有两种，一种是指针碰撞（bump the pointer），一种是空闲列表（free list）

指针碰撞：假设 Java 堆中内存是绝对规整的，所有被使用过的内存都被放在一边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump ThePointer）。

如果 Java 堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”（Free List）

其实空闲列表是一种更加灵活的内存管理方式，在我们学习 linux0.11 版本的操作系统的时候，操作系统也是用一个数组（也叫位图 bitmap）来标记每一块大小为 4K 的内存的使用次数，0 为未被使用过，1 为使用了一次。当我们想要找到空闲的内存空间的时候，只需要找到值为 0 的位置，然后将这个位置分配给请求内存的程序。

除如何划分可用空间之外，还有另外一个需要考虑的问题：对象创建在虚拟机中是非常频繁的行为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象 A 分配内存，指针还没来得及修改，对象 B 又同时使用了原来的指针来分配内存的情况。解决这个问题有两种可选方案：

一种是对分配内存空间的动作进行同步处理——实际上虚拟机是采用CAS 配上失败重试的方式保证更新操作的原子性；（CAS 真的是无处不在）

另外一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local AllocationBuffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完了，分配新的缓存区时才需要同步锁定。虚拟机是否使用 TLAB，可以通过 -XX：+/-UseTLAB 参数来设定。

这种为每个线程预先分配一段内存空间的做法真的很妙

内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值，如果使用了 TLAB 的话，这一项工作也可以提前至 TLAB 分配时顺便进行。这步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。

这一步其实是必须的，因为这块内存之前可能被别的对象使用过，上面有一些历史数据，因此为了避免历史数据的印象，将内存空间都初始化为零值是非常有必要的。

接下来，Java 虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码（实际上对象的哈希码会延后到真正调用 Object::hashCode() 方法时才计算）、对象的 GC 分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。关于对象头的具体内容，稍后会详细介绍。

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但是从 Java 程序的视角看来，对象创建才刚刚开始——构造函数，即 Class 文件中的 <init>() 方法还没有执行，所有的字段都为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。一般来说（由字节码流中 new 指令后面是否跟随 invokespecial 指令所决定，Java 编译器会在遇到 new 关键字的地方同时生成这两条字节码指令，但如果直接通过其他方式产生的则不一定如此），new 指令之后会接着执行 <init>() 方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。

总结如下就是

首先检查在方法区的常量池中是否能根据类名定位到一个类的符号引用，并且检查类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程
在 Java 堆中为对象分配固定大小的空间。
将分配出来的空间（不包括对象头）都初始化为零值，一个二进制位只有 0 和 1，这里强制设置为二进制的 0
设置对象的对象头信息，包括所属的类，对象的哈希码，GC 分代年龄等等。
以上就是 new 指令做的事情，new 执行完之后，开始执行类的构造函数，即 Class 文件中的 <init>() 方法

其实还会执行代码块，静态代码块之类的东西，而且这些代码块是在构造函数之前执行的。

对象的内存布局

看到现在位置感觉还好，接受度还挺高的，能看下去，哈哈哈。

一个 Java 对象，在内存中保存的什么内容？

任何软件，任何编程语言，甚至操作系统，搞清楚其内存结构，基本上就抓住了本质

在 HotSpot 虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

对象头部分包括两类信息。

第一类是用于存储对象自身的运行时数据，如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等，这部分数据的长度在 32 位和 64 位的虚拟机（未开启压缩指针）中分别为 32 个比特和 64 个比特，官方称它为“Mark Word”。

其实对象运行时的数据很多，从上面提到的这些来看，如果全都存储下来，分分钟超过 64 个比特，但是，对象运行时的数据跟对象的实例数据是无关的，是为了方便我们管理内存而产生的额外的内存成本，就跟 HTTP 的消息头一样，太大了的话，就有点得不偿失，因此考虑到虚拟机的空间效率，Mark Word 被设计成一个有着动态定义的数据结构，以便在极小的空间内存储尽量多的数据，根据对象的状态复用自己的存储空间。

关于对象头中的信息如何体现锁的变化，请看 Java 对象头：理解锁升级_java对象头的锁干啥用的-CSDN博客，这个其实挺复杂的

Java 对象头中还保存 GC 算法标记清除算法（CMS）对对象的标记，CMS 会根据对象头中的 GC 状态判断是否清除对象

关于 GC 的通俗易懂的解释：JVM的GC理论详解 - wade&luffy - 博客园
对象头的另外一部分是类型指针，即对象指向它的类型元数据的指针，Java 虚拟机通过这个指针来确定该对象是哪个类的实例。不过，并不是所有的虚拟机实现都必须在对象数据上保留类型指针

下一个小节 对象的访问定位 中提到，HotSpot 虚拟机采用的是直接指针访问的方式来访问对象类型数据，这个对象类型数据就通过对象头中的类型指针访问

类信息保存在方法区中
此外，如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的信息推断出数组的大小。

接下来实例数据

实例数据部分是对象真正存储的有效信息，即我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的字段都必须记录起来。这部分的存储顺序会受到虚拟机分配策略参数（-XX：FieldsAllocationStyle 参数）和字段在 Java 源码中定义顺序的影响。

对象的第三部分是对齐填充，

这并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于 HotSpot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍（也就是 64 位），换句话说就是任何对象的大小都必须是 8 字节的整数倍。对象头部分已经被精心设计成正好是 8 字节的倍数（也就是 1 倍或者 2 倍），因此，如果对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

32 位 HotSpot 虚拟机的对象头中存储自身运行时数据的大小是 32 位的，也就是 4 字节啊，再加上（开启指针压缩后）4 字节的类信息指针，就是 8 字节。如果是 64 位虚拟机，那自身运行时数据就有 8 字节，如果未开启压缩指针，那类信息指针也有 8 字节，总之，对象头至少是 8 字节的。

我发现这种 header+body 的设计非常地常见，Linux0.11 的文件系统，还有 HTTP 协议的 header 和 body，都是一段元数据（header）加上实际的有效数据（body），为了保证存储效率，元数据不能太长，一般是固定长度的 bitmap 位图，

可以画图如下

上面这段文字对对象的内存布局的描述还是很浅显的，更深刻的理解请参考博客：

JOL：Java 对象内存布局

Java对象内存布局(JOL) | Wilson Blog

对象的访问定位

还记得我们之前学习 Java 虚拟机的运行时数据区域的时候学习到 Java 虚拟机栈中保存着局部变量表、操作数栈、动态连接、方法出口等信息，其中局部变量如果是自定义对象（非原始数据类型），那么就会保存到 Java 堆中。

我们的 Java 程序会通过栈上的 reference 数据（对象引用）来操作堆上的具体对象。由于 reference 类型在《Java 虚拟机规范》里面只规定了它是一个指向对象的引用，并没有定义这个引用应该通过什么方式去定位、访问到堆中对象的具体位置，所以对象访问方式也是由虚拟机实现而定的，主流的访问方式主要有使用句柄和直接指针两种

句柄访问

Java 堆中将可能会划分出一块内存来作为句柄池，reference 中存储的就是对应的对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息

类型信息在方法区中

直接指针访问

Java 堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息（比如前面提到的放到对象头中），reference 中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问的开销

这两种对象访问方式各有优势，使用句柄来访问的最大好处就是 reference 中存储的是稳定句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而
reference 本身不需要被修改。

使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问在 Java 中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本，

就本书讨论的主要虚拟机 HotSpot 而言，它主要使用第二种方式记直接指针的方式进行对象访问（有例外情况，如果使用了 Shenandoah 收集器的话也会有一次额外的转发，具体可参见第 3 章）

其实我觉得句柄来访问的话效果更好，从设计的角度来看应该这样设计

OutOfMemoryError 异常

我们在工作中遇到实际的内存溢出异常时，能根据异常的提示信息迅速得知是哪个区域的内存溢出，知道怎样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何处理。

Java 堆溢出

Java 堆用于储存对象实例，我们只要不断地创建对象，并且保证 GC Roots 到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。

GC Roots 时 GC 算法根搜索算法中的概念，根搜索算法：设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的。

在 JAVA 语言中，可以当做 GC roots 的对象有以下几种：

栈（栈帧中的本地变量表）中引用的对象。

方法区中的静态成员。

方法区中的常量引用的对象（全局变量）

本地方法栈中 JNI（一般说的 Native 方法）引用的对象。

关于 GC 的通俗易懂的解释：JVM的GC理论详解 - wade&luffy - 博客园

测试代码

/**
 * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 *
 * @author zzm
 */
public class HeapOOM {
    static class OOMObject {
    }

    public static void main(String[] args) {
        List<OOMObject> list = new ArrayList<OOMObject>();
        while (true) {
            list.add(new OOMObject());
        }
    }
}

编辑 main 方法对应的 Run/Debug Configurations，首先点击 Modify options，勾上 Add VM options，然后再 VM options 输入框中输入 -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError

在《JVM 常见参数》中，我们已经了解过 -Xms20m -Xmx20m 命令的作用是设置堆初始大小和堆最大大小

在《JVM 性能调优笔记》中，我们也了解过 -XX:+HeapDumpOnOutOfMemoryError 的作用是在出现 OutOfMemory 的时候输出堆日志

在限制对内存大小的情况下，不停地创建对象，最终让堆内存溢出。

开始执行代码，一段时间之后控制台输出

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid26864.hprof ...
Heap dump file created [28158103 bytes in 0.041 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3210)
    at java.util.Arrays.copyOf(Arrays.java:3181)
    at java.util.ArrayList.grow(ArrayList.java:265)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:239)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:231)
    at java.util.ArrayList.add(ArrayList.java:462)
    at xyz.xiashuo.HeapOOM.main(HeapOOM.java:19)

同时在工作目录下，也就是 E:\IDEAProject\JVM 下多出了堆内存快照文件 java_pid26864.hprof，在 IDEA 中可直接打开这个文件

hprof 格式：Hprof文件解析 - Wxy的个人博客

要解决 Java 堆溢出，常规的处理方法是首先通过内存映像分析工具对 Dump 出来的堆转储快照（也就是我们上面提到的 java_pid26864.hprof）进行分析。第一步首先应确认内存中导致 OOM 的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。

内存泄露指的是对象已经没有地方使用了，但是对象对应的内存无法被回收，如果是内存泄漏，可进一步通过工具查看泄漏对象到 GC Roots 的引用链，找到泄漏对象是通过怎样的引用路径、与哪些 GC Roots 相关联，才导致垃圾收集器无法回收它们，根据泄漏对象的类型信息以及它到 GC Roots 引用链的信息，一般可以比较准确地定位到这些对象创建的位置，进而找出产生内存泄漏的代码的具体位置。
如果不是内存泄漏，换句话说就是内存中的对象确实都是必须存活的，那就应当检查 Java 虚拟机的堆参数（-Xmx 与 -Xms）设置，与机器的内存对比，看看是否还有向上调整的空间。再从代码上检查是否存在某些对象生命周期过长、持有状态时间过长、存储结构设计不合理等情况，尽量减少程序运行期的内存消耗。

在 IDEA 中直接双击 hrof，然后 IDEA 可以解析 hrof 文件，我们可以看到哪种类型的对象所占的空间最大，可以看到指定类型的对象的个数，以及每个对象所占的大小

在 Biggest Objects 这里，第一行的对象数组实际上是 List 集合内部的数组（我们用的是 ArrayList 实现，所以内部是数组），这里也直接展示了这个对象的 GC Root，展开第一行，可以看到内部正是我们在循环里 new 的 OOMObject 对象，光着一个对象数组，总共就占用了 19.45MB 的空间，确实接近我们设置的 Java 堆空间的上限了，因此最终报错：java.lang.OutOfMemoryError: Java heap space 也就很合理了

还有一个小细节。我们在前面的 对象的内存布局 小节中学习过，HotSpot 虚拟机的自动内存管理系统要求任何对象的大小都必须是 8 字节的整数倍，而在 64 位系统中，对象头就为 64 位，即为 8 个字节，再加上 4 个字节的类信息类信息指针，因此，一个对象的最小大小是 16 字节。我们创建的 OOMObject 对象确实也是一个不包含任何字段的空对象，因此其大小就是 16 字节。实际情况如上图所示。也是如此。

查看 GC Roots 这一个 tab

可以看到这个最大的对象：Object 数组的 GC Root 是我们在 main 方法中创建的 OOMObject

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

由于 HotSpot 虚拟机中并不区分虚拟机栈和本地方法栈，因此对于 HotSpot 来说，-Xoss 参数（设置本地方法栈大小）虽然存在，但实际上是没有任何效果的，栈容量只能由 -Xss 参数来设定

关于虚拟机栈和本地方法栈，在《Java 虚拟机规范》中描述了两种异常：

如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出 StackOverflowError 异常。
如果虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出 OutOfMemoryError 异常。

《Java 虚拟机规范》明确允许 Java 虚拟机实现自行选择是否支持栈的动态扩展，而 HotSpot 虚拟机的选择是不支持扩展，所以除非在创建线程申请内存时就因无法获得足够内存而出现 OutOfMemoryError 异常，否则在线程运行时是不会因为扩展而导致内存溢出的，只会因为栈容量无法容纳新的栈帧而导致 StackOverflowError 异常。

虽然规定是这样规定的，但是 hotspot 虚拟机却简化了这个逻辑，在 Hotspot 虚拟机中，我们只设置堆大小，爆出 StackOverflowError 的原因不是大于一个固定设置的栈最大深度，而是栈内存用完无法分配更多的栈了，也就是把虚拟机规范中的 StackOverflowError 和 OutOfMemoryError 混为一谈了。

当我们增加参数，就会增加栈帧的大小，此时整个栈能容纳的栈的个数就会变少。

Java最大栈深度有多大？-从一道面试题开始学习JVM - xuxh120 - 博客园

在多线程环境下，每个线程都会去申请栈空间，因此，栈空间太小也会限制线程总数

虚拟机栈的组成部分

局部变量表
操作数栈
动态连接
方法返回地址

看到虚拟机的第二个例子 ToDo

本章还没开始实践，TODO