Kotlin 中 crossinline 与 noinline 的区别

1. 概述

内联（Inlining）是编译器优化性能最经典的手段之一。为了提升执行效率并减少内存开销，Kotlin 也充分借用了这一机制。

本文将深入探讨 Kotlin 中 lambda 内联带来的两个关键修饰符：noinline 和 crossinline。它们看似相似，但在使用场景和底层行为上有本质区别。理解清楚可以避免踩坑，尤其是在高阶函数设计时。

2. 内联函数回顾

Kotlin 的内联函数（inline functions）主要用于消除 lambda 表达式带来的额外对象分配和方法调用开销。

举个简单的例子：

inline fun execute(action: () -> Unit) {
    action()
}

当调用这个函数时：

fun main() {
    execute {
        print("Hello ")
        print("World")
    }
}

Kotlin 编译器会将 execute 的调用以及其 lambda 主体直接“展开”到调用处，最终等效于：

fun main() {
    print("Hello ")
    print("World")
}

✅ 效果：

没有实际的 execute() 方法调用栈帧
lambda 本身也被完全内联，不生成 Function 实例

⚠️ 注意：这只是逻辑等价，实际生成的是字节码而非 Kotlin 源码。

这种机制显著提升了性能，尤其在频繁调用的高阶函数中效果明显。

3. noinline 的作用

默认情况下，inline 函数会将其所有 lambda 参数一并内联：

inline fun executeAll(action1: () -> Unit, action2: () -> Unit) {
    action1()
    action2()
}

上面代码中，action1 和 action2 都会被内联。

但有时我们希望 保留某个 lambda 不被内联，比如：

需要将 lambda 作为对象传递给非内联函数
要在多个地方引用同一个 lambda 实例
想避免过度内联导致代码膨胀

这时就可以使用 noinline 修饰符：

inline fun executeAll(action1: () -> Unit, noinline action2: () -> Unit) {
    action1()
    action2()
}

此时：

action1 被正常内联 ✅
action2 不会被内联，而是作为一个真正的 Function 对象存在 ❌

例如这段调用：

fun main() {
    executeAll({ print("Hello") }, { print(" World") })
}

逻辑上相当于编译为：

fun main() {
    print("Hello")
    val action2 = { print(" World") }
    action2()
}

虽然 executeAll 调用被内联了，但第二个 lambda 仍以独立对象形式存在。

3.1 字节码分析

前面说的“逻辑等价”只是为了帮助理解。真实情况要看字节码。

通过 kotlinc 编译后使用 javap 查看：

>> kotlinc Inlines.kt
>> javap -c -p com.baeldung.crossinline.InlinesKt

部分输出如下：

public static final void main();
    Code:
       0: getstatic     #41       // Field com/baeldung/crossinline/InlinesKt$main$2.INSTANCE:LInlinesKt$main$2;
       3: checkcast     #18       // class kotlin/jvm/functions/Function0
       6: astore_0               // 存储 lambda 实例
       7: iconst_0
       8: istore_1
       9:iconst_0
      10:istore_2
      11:ldc           #43       // String Hello
      13: astore_3
      14:iconst_0
      15:istore        4
      17:getstatic     #49       // Field java/lang/System.out:Ljava/io/PrintStream;
      20:aload_3
      21:invokevirtual #55       // Method java/io/PrintStream.print:(Ljava/lang/Object;)V
      24:nop
      25:aload_0                 // 加载 action2 lambda
      26:invokeinterface #22,  1 // InterfaceMethod Function0.invoke:()V
      31:pop
      32:nop
      33:return
InnerClasses:
static final #37; // class com.baeldung.crossinline/InlinesKt$main$2

关键点解读：

❌ 没有 invokestatic 调用 executeAll → 方法已被内联
✅ print("Hello") 直接出现在字节码中 → action1 被内联
✅ getstatic 获取了一个静态实例 InlinesKt$main$2 → 这是 { print(" World") } 编译后的单例对象
🔗 最终通过 invokeinterface 调用该对象的 invoke() 方法 → 即执行未内联的 lambda

📌 结论：noinline 真正阻止的是 lambda 的内联展开，但它仍然参与了外层函数的内联过程。

4. crossinline 的意义

4.1 问题背景：非局部返回（Non-local Return）

在 Kotlin 中，普通 return 只能在以下三种情况下使用：

命名函数
匿名函数
内联函数中的 lambda

为什么？因为 lambda 中的 return 默认指向最外层函数（非局部返回），而普通函数不允许这样做。

反例：

fun foo() {
    val f = {
        println("Hello")
        return // ❌ 编译错误！不能从 lambda 中 return 外部函数
    }
}

但在内联函数中允许：

inline fun foo(f: () -> Unit) {
    f()
}

fun main() {
    foo { 
        println("Hello World")
        return // ✅ 合法！因为 f 被内联到 main 中
    }
    println("Never reached")
}

✅ 成功的原因：f() 被内联展开后，return 实际作用于 main() 函数，等效于：

fun main() {
    println("Hello World")
    return
    println("Never reached")
}

4.2 陷阱：跨层级传递 lambda

如果我们在内联函数中把 lambda 传给一个非内联函数，会发生什么？

inline fun foo(f: () -> Unit) {
    bar { f() } // 把 f 传给了非内联函数 bar
}

fun bar(f: () -> Unit) {
    f()
}

❌ 上面代码无法通过编译！

原因在于：
假设它能编译，那么调用处就可以这样写：

fun main() {
    foo {
        println("Hello World")
        return // 想从 main 返回
    }
}

经过内联后逻辑变为：

fun main() {
    bar {
        println("Hello World")
        return // ❌ 问题来了：这里 return 试图跳出 main，但 bar 不是 inline！
    }
}

这违反了 Kotlin 规则 —— 非内联函数的 lambda 不能包含非局部返回。

所以编译器必须提前禁止这种情况。

4.3 解决方案：使用 crossinline

如果我们既想保留内联优势，又需要将 lambda 传递给非内联函数，怎么办？

答案就是 crossinline：

inline fun foo(crossinline f: () -> Unit) {
    bar { f() }
}

fun bar(f: () -> Unit) {
    f()
}

✅ 使用 crossinline 后，代码可以顺利编译。

但是 ⚠️：你不能再使用非局部 return：

fun main() {
    foo {
        println("Hello World")
        return // ❌ 编译错误！crossinline 禁止非局部返回
    }
}

📌 总结 crossinline 的核心作用：

允许 lambda 被安全地传递到另一个作用域（如非内联函数），同时保持其父函数的内联特性，但代价是禁用非局部控制流（如 return、break 等）。

4.4 noinline vs crossinline：关键对比

特性	`noinline`	`crossinline`
是否保留内联效率	❌ 所有 non-inlined lambda 失去内联好处	✅ 仅限制控制流，不影响其他内联优化
是否可传递 lambda 给非内联函数	✅ 可以	✅ 可以
是否支持非局部 `return`	❌ 不支持（本来就没内联）	❌ 显式禁止
底层是否生成 `Function` 实例	✅ 是	✅ 是（但上下文受保护）
推荐使用场景	不希望某 lambda 被内联	需跨层级传递 lambda 且仍需内联优化

🚨 特别提醒：
有人可能会尝试用 noinline 来解决同样的问题：

inline fun foo(noinline f: () -> Unit) {
    bar { f() }
}

虽然能编译，但 Kotlin 会发出警告：

warning: expected performance impact from inlining is insignificant...

意思是：如果你把所有 lambda 都标记为 noinline，那还声明 inline 干嘛？基本失去了内联的意义。

因此，在需要传递 lambda 到非内联上下文时，优先选择 crossinline。

5. 总结

✅ noinline：用于排除特定 lambda 参数的内联，使其成为真正的函数对象，适用于不需要内联的参数。
✅ crossinline：用于允许 lambda 被传递到非内联上下文，同时保留函数的内联优势，但禁止非局部返回。
⚠️ 两者都能实现“跨作用域传递 lambda”，但 crossinline 更高效，是更优解。
💡 记住一句话：**要用 return 就别传出去；要传出去就用 crossinline，放弃 return**。

示例代码已托管至 GitHub：https://github.com/Baeldung/kotlin-tutorials/tree/master/core-kotlin-modules/core-kotlin-advanced

Persistence

REST

Security