晴空霹雳小哪吒很多人第一次接触 inline、noinline、crossinline 这三个关键字，是在 IDE 的红色波浪线提示里。编译器逼着你加 crossinline，你就加；文档说 inline 能省掉 lambda 对象创建的开销，你就到处标。但真正让我把这些关键字彻底搞明白的，是我某次手痒用 javap 反编译了一段 Kotlin 代码，看到调用处堆了一堆 new MainKt$caller$1 之类的指令时，突然意识到：高阶函数的开销不是一句“会创建对象”就能概括的，而这三个关键字也不是简单的性能开关，它们本质上是在控制“一段代码到底从哪里来、到哪里去”。这篇文章我想从字节码层面把 inline、noinline、crossinline 的来龙去脉讲清楚，包括它们各自解决什么问题、带来了什么限制，以及实战中到底该怎么选。
1. 别急着用关键字：先看 JVM 眼里你的 lambda 是什么
1.1 非内联调用的字节码现场
先写一个再普通不过的高阶函数：
kotlin复制fun repeatAction(times: Int, action: () -> Unit) {
for (i in 1..times) {
action()
}
}
fun caller() {
repeatAction(3) {
println("tick")
}
}
这段代码没有任何关键字修饰，但它背后发生的事情比看起来多得多。我把这段 Kotlin 用 javap -c 反编译之后，caller() 的字节码大概长这样（我做了简化，去掉了一些不影响理解的细节）：
java复制public static final void caller();
Code:
0: iconst_3
1: new #12 // class MainKt$caller$1
4: dup
5: invokespecial #14 // Method MainKt$caller$1."<init>":()V
8: invokestatic #20 // Method repeatAction:(ILkotlin/jvm/functions/Function0;)V
11: return
那段 println("tick") 的逻辑，被编译器装进了一个叫 MainKt$caller$1 的类，这个类实现了 Function0 接口。每次执行到 caller() 的调用点，JVM 都要先 new 一个这样的函数对象出来，再把它传给 repeatAction。而 repeatAction 内部拿到这个对象后，每次循环执行 action()，实际对应的字节码是 invokeinterface Function0.invoke()。
这里就是第一层开销的来源：函数对象的分配 + 一次接口方法的分派。
1.2 每个高阶函数调用都有这些隐形开销
很多人知道高阶函数会创建 lambda 对象，但不知道这个对象创建到底发生在什么粒度上。我来拆一下一次非内联高阶函数调用的完整链路：
- 对象分配：调用点创建了
Function0的实例。Kotlin 1.5+ 在 JVM 上默认会走invokedynamic+LambdaMetafactory，但本质上仍然是生成函数对象。如果一个 lambda 捕获了外部变量，那么这个对象通常无法被复用，每次调用点都会做一次分配。 - 接口方法分派：调用
action()对应invokeinterface，JVM 需要查接口方法表；相比invokevirtual或者更直接的指令，多了一层间接性。 - 额外的栈帧：
repeatAction本身是一个方法调用，在 JVM 栈上要建立新的栈帧；如果 lambda 内部还有调用，栈的深度还会继续涨。
当然，现代 JIT 的能力很强，逃逸分析后也许能把对象分配消除，甚至把整段调用内联成机器码。但如果运行在 Android 的 ART 上，或者代码路径特别多，这些优化并不是每次都能成立。这不是说我们用高阶函数就一定是错的，而是说：这种开销是存在的、需要被意识到的，而不是可以当作“反正编译器会优化”就无视掉的东西。
1.3 顺带一提：inline hook 和内联其实是一类思路
聊到“把一段逻辑搬到调用点去执行”，我发现一个很有意思的类比：汇编层面的 inline hook。做逆向或者性能分析时，inline hook 做的事情是把目标函数开头的几条指令替换成跳转指令，让执行流跳转到我们自己的代码里；本质上是“在你的执行路径上插入/替换一段代码”。Kotlin 的 inline 也是类似的思想—