hashcon

本系列会针对 Java 中高级开发人员以及 JVM 运维人员，帮助大家深入理解 JVM 原理并能学以致用定位线上瓶颈，线上性能问题以及长期持续监控 JVM 。本系列针对 OpenJDK 11 以后的版本，同时也会帮助用户升级到 OpenJDK 11。本专栏会从快速上手 JFR，可视化查看 JFR 引入，之后会详细分析每一个 JFR 事件对应的背后的 JVM 原理以及源码，并且结合 Java 测试代码生成这些 JFR 事件帮助大家更好的理解这些事件产生的原因，以及需要如何去优化，然后会给出一下通过 JFR 定

在之后的 JFR 事件学习以及调试的过程中，我们会经常用到 WhiteBox API 来触发 JVM 的一些机制或者临界点。例如强制 JVM 现在立刻进行 FullGC 等等。什么是 WhiteBox APIWhiteBox API 是 HotSpot VM 自带的白盒测试工具，将内部的很多核心机制的 API 暴露出来，用于白盒测试 JVM，压测 JVM 特性，以及辅助学习理解 JVM 并调优参数。WhiteBox API 是 Java 7 引入的，目前 Java 8 LTS 以及 Java 11 LT

全系列目录：通过 JFR 与日志深入探索 JVM - 总览篇上一篇我们详细的分析了 TLAB 的原理以及生命周期，并且提出 JFR 相关的两个事件：在线程分配对象时，如果 TLAB 不够，则根据最大允许浪费空间，决定是回收当前 TLAB 还是重新获取一个 TLAB 进行分配还是直接在堆上分配。jdk.ObjectAllocationOutsideTLAB 代表直接在堆上分配，jdk.ObjectAllocationInNewTLAB 代表回收+重新获取 TLAB 进行分配。我们也提到了，jdk.Ob.

全系列目录：通过 JFR 与日志深入探索 JVM - 总览篇我个人有个习惯，对于要用的一个新的框架，新的中间件等等，我一般不太信任它的官网“吹”的优点以及性能测试，我一般会一边使用一边自己测试，并且猜想其内部实现并结合源码搞清楚它的实现原理以及一些“坑”（这些“坑”并不是说这些框架或者中间件有什么毛病，而是因为官网浮夸的“吹”以及有些事情说一半留一半导致用户有误解），在这之后我才敢放心使用。所以呢，我想先将 JFR 实现的基本原理提前说明白，这样可以让大家先有个整体印象，搞明白为何这么配置就对线上 .

什么是 Java Flight Record我们都知道，黑匣子是用于记录飞机飞行和性能参数的仪器。在飞机出问题后，用于定位问题原因。JFR（Java Flight Record） 就是 Java 的黑匣子。JFR 是 Java Flight Record （Java飞行记录） 的缩写，是 JVM 内置的基于事件的JDK监控记录框架。这个起名就是参考了黑匣子对于飞机的作用，将 Java 进程比喻成飞机飞行。顾名思义，这个记录主要用于问题定位和持续监控。在线上出问题时，我们一般首要任务是快速恢复，而不是保

什么是 TLAB？TLAB（Thread Local Allocation Buffer）线程本地分配缓存区，这是一个线程专用的内存分配区域。既然是一个内存分配区域，我们就先要搞清楚 Java 内存大概是如何分配的。我们一般认为 Java 中 new 的对象都是在堆上分配，这个说法不够准确，应该是大部分 new 的对象在堆上分配。还有一部分可能在 栈上分配 或者是 TLAB 中分配。同时，对于一些的 GC 算法，还可能直接在老年代上面分配，例如 G1 GC 中的 humongous allocation