Kotlin/JVM 性能基础 on Dorkytiger 的小屋

四种执行形态：为什么必须预热

Mon, 01 Jan 0001 00:00:00 +0000

2.1 四种执行形态：为什么必须预热

上一节：无　|　下一节：2.2 JIT 的三大优化与去优化配套代码：02-jvm-performance-basics/01-execution-tiers

一句话结论

JVM 上的同一段代码，随着被调用的次数增加，会经历「解释执行 → C1 编译 → C2 编译」三种形态，性能台阶式提升。 所以你测前 100 次调用，测的其实是最慢的那种形态，它和线上稳态毫无关系。

一、用餐厅厨房理解分层编译

假设你开了一家餐厅，来了一个新厨师。看他怎么做菜：

阶段	厨师状态	类比 JVM
第 1 天	照着菜谱一步一步做，看一行做一步，很慢但立刻能上手	解释执行：逐条读取字节码并执行
做了几天后	熟练了，动作连贯，不用再看菜谱	C1 编译：编译成机器码，快，但只做简单优化
做了几百次之后	老师傅开始重新设计整个流程：提前备料、合并步骤、把常用的调料放在手边	C2 编译：做激进优化（内联、逃逸分析、循环展开）
正在做菜时被老师傅接手	这道菜做到一半，老师傅直接接手继续	OSR（栈上替换）：循环体被热点编译

关键点：

老师傅不会第一天就来。 他需要先观察你做了几百次，确认「这道菜真的是最常点的」，才值得花时间重新设计流程。
重新设计流程很费时间（编译耗时），所以只有足够热的代码才配得上 C2。
所以：前几十次调用的性能，和你线上跑了一小时之后的性能，完全是两回事。

二、三种形态的实际差异

形态	触发条件	相对速度	说明
解释执行	一开始	最慢（可能慢 5–20 倍）	逐条字节码执行，还要做类型检查
C1（客户端编译器）	调用几百次后	中等	编译快、优化少，目标是「尽快摆脱慢速解释」
C2（服务端编译器）	调用数千到上万次后	最快	编译慢、优化激进，会做基于运行时 profile 的推测性优化

具体阈值随 JDK 版本和运行情况变化（大致在数千到上万次调用 / 循环回边这个量级）。不要记具体数字，要记住「有台阶」这个事实。 需要精确数字时用 -XX:+PrintCompilation 观察自己的程序。

JIT 的三大优化与去优化

Mon, 01 Jan 0001 00:00:00 +0000

2.2 JIT 的三大优化与去优化

上一节：2.1 四种执行形态　|　下一节：2.3 微基准四大陷阱配套代码：02-jvm-performance-basics/02-jit-optimizations-and-deopt

一句话结论

C2 编译器会基于「运行时观察到的现象」做推测性优化——比如「这个调用点永远只有一种类型」。一旦推测被打破，它会撤销优化、退回慢速路径。 这就是「去优化」，也是性能无端抖动的常见来源。

一、先看三大优化（用厨房类比）

接着上一节的餐厅比喻。老师傅（C2）在观察了足够多次之后，会做三件事：

优化一：方法内联（Inlining）—— 把常用步骤直接展开

原来：每次要做「去冰箱拿鸡蛋」这个动作，都要走过去、打开冰箱、拿蛋、关门。厨师会把它写成一个标准动作反复执行。

老师傅的做法：既然每次都这样，那我干脆把这个动作直接展开到主流程里，不用来回跑（省掉「方法调用的开销」），而且展开之后还能看到更大的优化空间（比如发现「拿蛋之后马上要打蛋」，可以合并）。

技术含义：把被调用方法的字节码直接嵌入调用方，消除调用开销，并为后续优化（常量传播、死代码消除）创造条件。

这也是为什么火焰图会「丢帧」：内联之后，中间那个方法在调用栈上就不存在了。

优化二：逃逸分析（Escape Analysis）—— 只在内部用的东西，不用真造一个

原来：厨房要盛一份配菜，得专门洗一个盘子、装盘、用完再洗。

老师傅发现：这个盘子只在厨房内部用，端出去之前就被吃掉了……那我为什么还要真的拿一个盘子？直接在案板上处理完就行。

同理，还有两个衍生优化：

锁消除：如果一把锁只在内部用、不会被别的厨师碰到，那就没必要真锁。
标量替换：如果一个对象只在内部用，可以把它拆成几个局部变量，连对象都不分配。

技术含义：如果 JIT 能证明一个对象不会「逃逸」出当前方法/线程，就可以把它分配在栈上（甚至拆成标量），从而减少堆分配与 GC 压力。

这解释了一个反直觉的现象：有些看起来「创建了很多对象」的代码，实测非常快——因为那些对象根本没被真正创建。

优化三：基于 profile 的推测优化 —— 按「最常发生的情况」设计流程

老师傅观察到：来这里的客人99% 都点同一道招牌菜。于是他干脆把这道菜的料都提前备好放在手边。

风险：如果有一天来了个点别的菜的客人，他准备的料全用不上，还得临时找——比原来更慢。

技术含义：C2 会记录调用点的类型分布。如果它发现「这个接口调用永远指向同一个实现类」，就会把虚调用（间接跳转）优化成直接调用（甚至内联掉）。这叫 monomorphic（单态） 调用点。

如果后来出现了第二种类型，就叫 bimorphic（双态）；出现多种类型就是 megamorphic（巨态），此时 JIT 会放弃优化，退回慢速的虚调用。

二、去优化：优化被撤销的瞬间

什么是去优化

当 C2 的推测被打破时，它必须撤销已经生成的机器码，退回到解释执行或较低优化的版本，然后带着新信息重新编译。

① C2 假设「这个调用点只有 A 类型」→ 生成直接调用 A 的机器码（很快）
② 某次请求带来了 B 类型
③ 假设被打破 → 当前机器码作废（made not entrant）
④ 退回解释执行 / 重新走 C1、C2 编译
⑤ 期间性能明显下降（可能出现毫秒级甚至更长的抖动）

触发去优化的常见原因：

微基准四大陷阱

Mon, 01 Jan 0001 00:00:00 +0000

2.3 微基准四大陷阱

上一节：2.2 JIT 的三大优化与去优化　|　下一节：2.4 预热、稳态与冷启动配套代码：02-jvm-performance-basics/03-microbenchmark-traps

一句话结论

你写的基准测试，最大的对手不是机器噪声，而是优化器。 它会把你的计算整个删掉、提前算好、或者把你的分支预测喂得太好。四个陷阱里，任何一个都会让你的数字变成废纸。

一、陷阱一：死代码消除（DCE）—— 算了但没人用，那就不算

现象：测出 0.2 ns/op 这种物理上不可能的数字。

原因：计算的结果没有被使用，JIT 判断「这个计算没有副作用」，于是把整个循环删掉了。你测的是一个空循环。

// ❌ 结果没人用 → 整个计算被删除
repeat(100_000) {
    sumArray(data)          // 返回值丢掉了
}

// ✅ 结果被消费 → 计算保留
var sink = 0L
repeat(100_000) {
    sink += sumArray(data)
}
println(sink)               // 确保 sink 真的被使用，否则它也可能被优化掉

为什么难发现：代码看起来「明明在算」，而且跑得飞快——你会以为是好事。

判断方法：把数据规模改成 10 倍，如果耗时完全不变，说明计算被删了。

二、陷阱二：常量折叠 —— 输入是已知的，那就提前算好

现象：数字看起来合理，但与输入规模无关。

原因：输入在编译期就能确定（比如字面量、const），JIT 直接在编译时把结果算出来。

// ❌ 输入是编译期常量 → 结果被提前算好
val data = IntArray(4096) { it }          // 规律数据，JIT 能推导
repeat(100_000) { sink += sumArray(data) }

// ✅ 输入在运行时才确定
val rnd = Random(System.nanoTime())        // 真正的运行时随机
val data = IntArray(4096) { rnd.nextInt() }

注意：即使数据是「运行时生成的」，如果生成方式是 { it } 或 { it * 2 } 这类规律模式，JIT 仍可能利用这个规律（比如识别出等差数列直接套公式）。

预热、稳态与冷启动

Mon, 01 Jan 0001 00:00:00 +0000

2.4 预热、稳态与冷启动

上一节：2.3 微基准四大陷阱　|　下一节：2.5 内存与 GC 配套代码：02-jvm-performance-basics/04-warmup-steady-coldstart

一句话结论

同一份代码，在「刚启动」「跑了 30 秒」「跑了一小时」三个时刻，是三个不同的系统。 所以任何性能数字都必须标明它测的是哪一段——而判断「进入稳态」要靠数据（方差收敛），不是靠固定的秒数。

一、用运动员热身体理解三个阶段

你去跑 100 米：

阶段	状态	成绩
刚睡醒，直接跑	肌肉僵硬、心率没上来、动作不协调	15 秒
热身 10 分钟后跑	身体进入状态	12 秒
热身充分、连续跑几次	完全进入状态，成绩稳定	11.5 秒（波动很小）

关键洞察：

「热身多久」没有标准答案。 有人 5 分钟就够，有人要 20 分钟。唯一的判断标准是「成绩是否稳定了」，而不是「跑了多久」。
你不会把「刚睡醒那次 15 秒」算进你的成绩统计。 那是一次热身，不是测量。

JVM 完全一样，而且有三个阶段。

二、三个阶段分别是什么在变慢

阶段一：冷启动（进程刚起来）

正在发生	影响
JVM 启动、类加载	大量类需要从磁盘读取、验证、链接
所有代码在解释执行	最慢的执行形态
连接池是空的	需要建立数据库/Redis 连接
缓存是冷的	缓存穿透到数据库
线程池刚创建	线程创建开销
配置/密钥/证书加载	可能涉及网络

表现：第一个请求可能需要几百毫秒到几秒，而稳态是几十毫秒。

阶段二：预热期（跑了十几秒到几分钟）

正在发生	影响
热点方法升到 C1、C2	性能台阶式改善（第 1 节）
连接池填满	不用再等建连
JIT 的 profile 逐渐稳定	类型分布、分支走向被摸清
本地缓存逐渐升温	命中率上升

表现：数字不稳定，仍在下降。

内存与 GC：分配速率才是关键

Mon, 01 Jan 0001 00:00:00 +0000

2.5 内存与 GC：分配速率才是关键

上一节：2.4 预热、稳态与冷启动　|　下一节：2.6 并发原语成本与伪共享配套代码：02-jvm-performance-basics/05-memory-and-gc

一句话结论

决定 GC 压力的是「每秒产生多少垃圾」，不是「堆有多大」。 所以 JVM 上的优化目标不是「零分配」，而是降低分配速率和减少对象存活时间。这两件事的效果，比调堆大小大得多。

二、用办公室垃圾桶理解 GC

假设一个办公室，每个人都在往垃圾桶里扔废纸：

概念	类比	技术含义
扔废纸	分配对象	`new` / 创建对象
垃圾桶容量	堆大小	`-Xmx`
扔废纸的速度	分配速率	MB/s——最关键
保洁员来倒垃圾	GC	回收不可达对象
倒垃圾时全员停手	GC 停顿	Stop-The-World
有些文件不能扔，要归档	对象晋升	从年轻代到老年代
每人一个自己的小垃圾桶	TLAB	线程本地分配缓冲，避免排队领纸
一个巨大的纸箱	Humongous 对象	塞不进普通桶，触发特殊处理

从这个类比能推出三个关键结论：

垃圾桶越大，倒的次数越少，但每次倒的时间越长。 → 堆不是越大越好。
如果大家扔得飞快，保洁员就要频繁来倒，全员频繁停手。 → 分配速率是核心指标。
每人有自己的小垃圾桶（TLAB），所以「扔纸」这个动作本身几乎不花时间。 → 分配本身很便宜，代价在 GC。

第 3 条是最反直觉的：从 C++ 过来的人会本能地认为「分配很贵，要尽量少分配」。在 JVM 上，分配一个普通对象就是「在一个线程私有区域里移动一下指针」（TLAB 里的指针碰撞），比一次内存访问还快。真正贵的是这些对象累积起来导致的 GC。

并发原语成本与伪共享

Mon, 01 Jan 0001 00:00:00 +0000

2.6 并发原语成本与伪共享

上一节：2.5 内存与 GC　|　下一节：2.7 协程的真实开销模型配套代码：02-jvm-performance-basics/06-concurrency-primitives

一句话结论

无竞争的锁很便宜（几十纳秒），有竞争的锁非常贵（可能几百纳秒到微秒级）——差距是数量级的。 而且加线程数超过某个点后，吞吐会下降：因为上下文切换、缓存失效和锁竞争的成本超过了并行带来的收益。

一、用共享打印机理解并发成本

办公室里有一台打印机，你和同事都要用：

情况	你的体验	技术含义
没人在用，你直接印	走过去就能印，几秒钟	无竞争锁：几十纳秒
同事正在印，你等他打完	排队等待	有竞争锁：排队时间可能很长
你们都想改同一份文档	用「先检查版本，再提交」的方式，冲突就重试	CAS（比较并交换）
你刚坐下准备干活，又被叫去开会，回来还得重新进入状态	效率损失	上下文切换：还要付出「缓存失效」的代价
你和同事的笔记本放在同一个抽屉里，他每次开抽屉你都得停一下	明明没共享数据，却互相干扰	伪共享（false sharing）

注意最后一条：这就是伪共享——你们没有共享任何数据，但因为数据在内存里离得太近，硬件层面的缓存同步把你们绑在了一起。

二、各种操作的成本量级

⚠️ 下面都是量级参考，随 CPU、JDK 版本、竞争程度变化很大。请用配套代码在自己的机器上测一遍——这个练习的价值远大于记住数字。

操作	量级	说明
一次 L1 缓存访问	~1 ns	基准
无竞争的 `synchronized`	十几到几十 ns	现代 JVM 的偏向锁/轻量级锁优化得很好
CAS 操作	十几 ns	`AtomicInteger.incrementAndGet()` 无竞争时
有竞争的锁	几百 ns ~ 微秒级	差距是数量级的，且有排队
volatile 写	几十 ns	需要内存屏障
线程创建	几十微秒	比一次普通操作贵 1000 倍
一次上下文切换	1–5 微秒	加上缓存失效的间接成本会更多
协程挂起/恢复	纳秒到数百纳秒	比线程切换便宜几个数量级
伪共享导致的额外延迟	可达百纳秒级	取决于访问模式与竞争强度

从这张表能读出三个结论：

协程的真实开销模型

Mon, 01 Jan 0001 00:00:00 +0000

2.7 协程的真实开销模型

上一节：2.6 并发原语成本与伪共享　|　下一节：2.8 JMH 与 kotlinx-benchmark 配套代码：02-jvm-performance-basics/07-coroutines-cost-model

一句话结论

协程把「线程」和「并发任务」解耦了，但它不是免费的、也不是无限的。 Dispatchers.Default 的并行度约等于 CPU 核数——一旦被阻塞调用占满，所有使用它的协程会一起卡住。这是 Kotlin 后端最高频、也最难排查的性能故障。

一、用餐厅服务理解协程

一家餐厅有 8 个服务员（= CPU 核数）：

线程模型（传统）

一个服务员负责一桌客人：点单 → 等厨房做菜 → 上菜 → 结账，全程守着这桌。等菜的时候他什么都不干，也不能服务别的桌。

结果：8 个服务员最多同时服务 8 桌。第 9 桌客人要等有人结账。

协程模型

一个服务员可以这样干：给 1 号桌点单 → 把单子交给厨房 → 在等菜的时间里，去 2 号桌点单 → 再去 3 号桌 → 菜好了就上菜。

结果：8 个服务员可以同时服务几百桌，因为他们不「死等」。

这就是协程的核心价值：在等待 IO 的时候，让出线程去处理别的任务。

但协程有一个致命限制

假设某个服务员被派去做一件必须亲自守着的事——比如「站在菜市场等摊主称菜」（这就是阻塞调用）。

他离开了餐厅。现在只剩 7 个服务员在店里。如果 8 个人都被派去菜市场了呢？

餐厅里一个服务员都没有了。所有客人的请求全部卡住。

这就是「阻塞调用污染调度器」，也是本节最重要的一件事。

二、协程本身的成本

2.1 `suspend` 是怎么实现的

suspend fun fetchUser(id: String): User {
    val cached = cache.get(id)        // 可能挂起
    return cached ?: api.get(id)      // 可能挂起
}

编译器会把上面这个函数改造成一个状态机：

JMH 与 kotlinx-benchmark：标准化的基准工具

Mon, 01 Jan 0001 00:00:00 +0000

2.8 JMH 与 kotlinx-benchmark：标准化的基准工具

上一节：2.7 协程的真实开销模型　|　下一节：2.9 Lab 2 配套代码：02-jvm-performance-basics/08-jmh-and-kotlinx-benchmark

一句话结论

前面七节讲的每一个陷阱和坑，JMH 都替你处理好了。 它不是一个「更好用的计时器」，而是一套防止你自己骗自己的框架。代价是它的配置比你想象的啰嗦——但每一条配置都在防一个具体的错误。

一、为什么必须用框架

回顾前七节，自己写基准要同时防住这些：

风险	自己写要做什么	JMH 的做法
死代码消除	手动消费结果	`Blackhole.consume()`
常量折叠	运行时生成输入	`@State` + `@Setup`
未消费结果	同上	同上
预热不足	手动预热并判断稳态	`@Warmup` + `@Iterations`
上一轮的 profile 污染下一轮	手动开新 JVM	`@Fork(N)`
计时精度	手动 `nanoTime`	`@BenchmarkMode` + 框架自己的计时循环
统计	手动算均值/分布	自动算 `Score ± Error`
分配测量	手动监控	`-prof gc`，直接给 `gc.alloc.rate`

一句话：自己写，就是把这些坑重新踩一遍。

二、JMH 注解速查

@State(Scope.Benchmark)              // 状态的作用域：Benchmark（共享）/ Thread（每线程）/ Group
@BenchmarkMode(Mode.Throughput)      // 模式：Throughput / AverageTime / SampleTime / SingleShotTime
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 3, time = 1)    // 预热 3 轮，每轮 1 秒
@Measurement(iterations = 5, time = 1)  // 测量 5 轮，每轮 1 秒
@Fork(2)                             // 跑在 2 个独立 JVM 里
@Threads(1)                          // 线程数
open class MyBenchmark {

    private lateinit var data: IntArray

    @Setup(Level.Trial)              // 每个 fork 前执行一次
    fun setup() {
        val rnd = Random(42)
        data = IntArray(4096) { rnd.nextInt() }    // 运行时输入，防常量折叠
    }

    @TearDown(Level.Trial)
    fun tearDown() { /* 清理 */ }

    @Benchmark
    fun myMethod(bh: Blackhole) {                  // Blackhole 消费结果
        var sum = 0L
        for (v in data) sum += v
        bh.consume(sum)
    }

    @Benchmark
    @OperationsPerInvocation(1000)                 // 一次调用做了 1000 次操作，自动摊薄
    fun bulkOperation(bh: Blackhole) { /* ... */ }

    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)   // 诊断：禁止内联某方法
    fun diagnostic(bh: Blackhole) { /* ... */ }
}

四个最常被忽略的参数：

Lab 2：三份基准与一个坏基准

Mon, 01 Jan 0001 00:00:00 +0000

2.9 Lab 2：三份基准与一个坏基准

上一节：2.8 JMH 与 kotlinx-benchmark　|　下一节：第 3 章测试分层配套代码：02-jvm-performance-basics/09-lab2 预计时长：90 分钟

一、这个 Lab 的目标

前八节讲了理论，这个 Lab 让你亲手把每一节的结论验证一遍。

做完之后，你应该对「一个性能数字可不可信」有肌肉记忆——而不是靠回忆规则清单。

二、任务清单

#	任务	产出	时长
1	同一个算法三种测法对比	三组数字 + 差异解释	30 min
2	故意写一个坏基准	荒谬数字 + 原因分析	15 min
3	测你自己的「并发成本表」	6 个操作的量级	25 min
4	调度器饥饿实验	观察到全局卡顿	20 min
5	建实验档案	`docs/experiments/E02-.../README.md`	—

三、任务 1：三份基准对比

被测对象：一个「有点计算量」的纯函数。建议用其中一个：

对 IntArray 求和 / 求最大值
字符串拼接 1000 次
Regex 匹配一段文本
对一组数据做排序

三种测法：

Kotlin/JVM 性能基础 on Dorkytiger 的小屋

四种执行形态：为什么必须预热

2.1 四种执行形态：为什么必须预热

一句话结论

一、用餐厅厨房理解分层编译

二、三种形态的实际差异

JIT 的三大优化与去优化

2.2 JIT 的三大优化与去优化

一句话结论

一、先看三大优化（用厨房类比）

优化一：方法内联（Inlining）—— 把常用步骤直接展开

优化二：逃逸分析（Escape Analysis）—— 只在内部用的东西，不用真造一个

优化三：基于 profile 的推测优化 —— 按「最常发生的情况」设计流程

二、去优化：优化被撤销的瞬间

什么是去优化

微基准四大陷阱

2.3 微基准四大陷阱

一句话结论

一、陷阱一：死代码消除（DCE）—— 算了但没人用，那就不算

二、陷阱二：常量折叠 —— 输入是已知的，那就提前算好

预热、稳态与冷启动

2.4 预热、稳态与冷启动

一句话结论

一、用运动员热身体理解三个阶段

二、三个阶段分别是什么在变慢

阶段一：冷启动（进程刚起来）

阶段二：预热期（跑了十几秒到几分钟）

内存与 GC：分配速率才是关键

2.5 内存与 GC：分配速率才是关键

一句话结论

二、用办公室垃圾桶理解 GC

并发原语成本与伪共享

2.6 并发原语成本与伪共享

一句话结论

一、用共享打印机理解并发成本

二、各种操作的成本量级

协程的真实开销模型

2.7 协程的真实开销模型

一句话结论

一、用餐厅服务理解协程

线程模型（传统）

协程模型

但协程有一个致命限制

二、协程本身的成本

2.1 suspend 是怎么实现的

JMH 与 kotlinx-benchmark：标准化的基准工具

2.8 JMH 与 kotlinx-benchmark：标准化的基准工具

一句话结论

一、为什么必须用框架

二、JMH 注解速查

Lab 2：三份基准与一个坏基准

2.9 Lab 2：三份基准与一个坏基准

一、这个 Lab 的目标

二、任务清单

三、任务 1：三份基准对比

2.1 `suspend` 是怎么实现的