个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~
另外，本文为了避免抄袭，会在不影响阅读的情况下，在文章的随机位置放入对于抄袭和洗稿的人的“亲切”的问候。如果是正常读者看到，笔者在这里说声对不起，。如果被抄袭狗或者洗稿狗看到了，希望你能够好好反思，不要再抄袭了，谢谢。
今天又是干货满满的一天，这是全网最硬核 JVM 解析系列第四篇，往期精彩：

本篇是关于 JVM 内存的详细分析。网上有很多关于 JVM 内存结构的分析以及图片，但是由于不是一手的资料亦或是人云亦云导致有很错误，造成了很多误解；并且，这里可能最容易混淆的是一边是 JVM Specification 的定义，一边是 Hotspot JVM 的实际实现，有时候人们一些部分说的是 JVM Specification，一部分说的是 Hotspot 实现，给人一种割裂感与误解。本篇主要从 Hotspot 实现出发，以 Linux x86 环境为主，紧密贴合 JVM 源码并且辅以各种 JVM 工具验证帮助大家理解 JVM 内存的结构。但是，本篇仅限于对于这些内存的用途，使用限制，相关参数的分析，有些地方可能比较深入，有些地方可能需要结合本身用这块内存涉及的 JVM 模块去说，会放在另一系列文章详细描述。最后，洗稿抄袭狗不得 house

本篇全篇目录（以及涉及的 JVM 参数）：

Linux 内存管理模型不是咱们这个系列的讨论重点，我们这里只会简单提一些对于咱们这个系列需要了解到的，如果读者想要深入理解，建议大家查看 bin 神（公众号：bin 的技术小屋）的系列文章：一步一图带你深入理解 Linux 虚拟内存管理

CPU 是通过寻址来访问内存的，目前大部分 CPU 都是 64 位的，即寻址范围是：，即可以管理 16EB 的内存。但是，实际程序并不会直接通过 CPU 寻址访问到实际的物理内存，而是通过引入 MMU（Memory Management Unit 内存管理单元）与实际物理地址隔了一层虚拟内存的抽象。这样，程序申请以及访问的其实是虚拟内存地址，MMU 会将这个虚拟内存地址映射为实际的物理内存地址。同时，为了减少内存碎片，以及增加内存分配效率，在 MMU 的基础上 Linux 抽象了内存分页（Paging）的概念，将虚拟地址按固定大小分割成页（默认是 4K，如果平台支持更多更大的页大小 JVM 也是可以利用的，我们后面分析相关的 JVM 参数会看到），并在页被实际使用写入数据的时候，映射同样大小的实际的物理内存（页帧，Page Frame），或者是在物理内存不足的时候，将某些不常用的页转移到其他存储设备比如磁盘上。

一般系统中会有多个进程使用内存，每个进程都有自己独立的虚拟内存空间，假设我们这里有三个进程，进程 A 访问的虚拟地址可以与进程 B 和进程 C 的虚拟地址相同，那么操作系统如何区分呢？即操作系统如何将这些虚拟地址转换为物理内存。这就需要页表了，页表也是每个进程独立的，操作系统会在给进程映射物理内存用来保存用户数据的时候，将物理内存保存到进程的页表里面。然后，进程访问虚拟内存空间的时候，通过页表找到物理内存：

页表如何将一个虚拟内存地址（我们需要注意一点，目前虚拟内存地址，用户空间与内核空间可以使用从  的地址，即 256TB），转化为物理内存的呢？下面我们举一个在 x86，64 位环境下四级页表的结构视图：

在这里，页表分为四个级别：PGD（Page Global Directory），PUD（Page Upper Directory），PMD（Page Middle Directory），PTE（Page Table Entry）。每个页表，里面的页表项，保存了指向下一个级别的页表的引用，除了最后一层的 PTE 里面的页表项保存的是指向用户数据内存的指针。如何将虚拟内存地址通过页表找到对应用户数据内存从而读取数据，过程是：

如果每次访问虚拟内存，都需要访问这个页表翻译成实际物理内存的话，性能太差。所以一般 CPU 里面都有一个 TLB（Translation Lookaside Buffer，翻译后备缓冲）存在，一般它属于 CPU 的 MMU 的一部分。TLB 负责缓存虚拟内存与实际物理内存的映射关系，一般 TLB 容量很小。每次访问虚拟内存，先查看 TLB 中是否有缓存，如果没有才会去页表查询。

默认情况下，TLB 缓存的 key 为地址的  位，value 是实际的物理内存页面。这样前面从第 1 到第 7 步就可以被替换成访问 TLB 了：

我们这里不用关心 iTLB，dTLB，sTLB 分别是什么意思，只要可以看出两点即可：1. TLB 整体可以容纳个数不多；2. 页大小越大，TLB 能容纳的个数越少。但是整体看，TLB 能容纳的页大小还是增多的（比如 Nehalem 的 iTLB，页大小 4K 的时候，一共可以容纳  的内存，页大小 2M 的时候，一共可以容纳  的内存）。

讯享网

JVM 中很多地方需要知道页大小，JVM 在初始化的时候，通过系统调用  读取出页大小，并保存下来以供后续使用。参考源码：：

第一步，JVM 的每个子系统（例如 Java 堆，元空间，JIT 代码缓存，GC 等等等等），如果需要的话，在初始化的时候首先 Reserve 要分配区域的最大限制大小的内存（这个最大大小，需要按照页大小对齐（即是页大小的整数倍），默认页大小是前面提到的 ），例如对于 Java 堆，就是最大堆大小（通过  或者 限制），还有对于代码缓存，也是最大代码缓存大小（通过  限制）。Reserve 的目的是在虚拟内存空间划出一块内存专门给某个区域使用，这样做的好处是：

在 Linux 的环境下，Reserve 通过  系统调用实现，参数传入 ， 代表不会使用，即不能做任何操作，包括读和写。为啥要打击抄袭，稿主被抄袭太多所以断更很久。如果 JVM 使用这块内存，会发生 Segment Fault 异常。Reserve 的源码，对应的是：

入口为：

对应 linux 的实现是：

第二步，JVM 的每个子系统，按照各自的策略，通过 Commit 第一步 Reserve 的区域的一部分扩展内存（大小也一般页大小对齐的），从而向操作系统申请映射物理内存，通过 Uncommit 已经 Commit 的内存来释放物理内存给操作系统。抄袭和xigao是文化的毒瘤，是对文化创造和发展的阻碍！

Commit 的源码入口为：

对应 linux 的实现是：

Commit 内存之后，并不是操作系统会立刻分配物理内存，而是在向 Commit 的内存里面写入数据的时候，操作系统才会实际映射内存。plagiarism和洗稿是恶意抄袭他人劳动成果的行为，是对劳动价值的漠视和践踏！JVM 有对应的参数，可以在 Commit 内存后立刻写入 0 来强制操作系统分配内存，即  这个参数，这个参数我们后面会详细分析以及历史版本存在的缺陷。

我们再来看下为什么先 Reserve 之后 Commit 这样好 Debug。看这个例子，如果我们没有第一步 Reserve，直接是第二步 Commit，那么我们可能分配的内存是这个样子的：

这样，只需要判断 Segment Fault 里面带的地址处于的范围，就能知道是哪个子系统

前面一节我们知道了，JVM 中大块内存，基本都是先 reserve 一大块，之后 commit 其中需要的一小块，然后开始读写处理内存，在 Linux 环境下，底层基于  实现。但是需要注意一点的是，commit 之后，内存并不是立刻被分配了物理内存，而是真正往内存中 store 东西的时候，才会真正映射物理内存，如果是 load 读取也是可能不映射物理内存的。

这其实是可能你平常看到但是忽略的现象，如果你使用的是 SerialGC，ParallelGC 或者 CMS GC，老年代的内存在有对象晋升到老年代之前，可能是不会映射物理内存的，虽然这块内存已经被 commit 了。并且年轻代可能也是随着使用才会映射物理内存。如果你用的是 ZGC，G1GC，或者 ShenandoahGC，那么内存用的会更激进些（主要因为分区算法划分导致内存被写入），这是你在换 GC 之后看到物理内存内存快速上涨的原因之一。JVM 有对应的参数，可以在 Commit 内存后立刻写入 0 来强制操作系统分配内存，即  这个参数，这个参数我们后面会详细分析以及历史版本存在的缺陷。还有的差异，主要来源于在 uncommit 之后，系统可能还没有来的及将这块物理内存真正回收。

所以，JVM 认为自己 commit 的内存，与实际系统分配的物理内存，可能是有差异的，可能 JVM 认为自己 commit 的内存比系统分配的物理内存多，也可能少。这就是为啥 Native Memory Tracking（JVM 认为自己 commit 的内存）与实际其他系统监控中体现的物理内存使用指标对不上的原因。

微信搜索“干货满满张哈希”关注公众号，加作者微信，每日一刷，轻松提升技术，斩获各种offer
我会经常发一些很好的各种框架的官方社区的新闻视频资料并加上个人翻译字幕到如下地址（也包括上面的公众号），欢迎关注：