Kotlin协程：非内联库函数传挂起Lambda死锁解决方案

调用非内联库函数时，传入自定义函数f，该函数需要从通道接收数据，必须支持挂起。调用库函数时仅需要在当前协程上下文等待执行完成即可。
已知该库函数的固定执行逻辑：

• 先执行pre前置逻辑
• 调用传入的f
• 执行post后置逻辑

f必然在pre和post之间执行，逻辑上这个库函数完全可以设计为内联函数，但实际实现是非内联的，导致f内部无法访问外层协程上下文。
最初尝试用runBlocking包裹挂起调用，但是触发死锁：当调度器只有单个可用线程时，线程会被阻塞直到receive执行完成，生产者协程根本没有机会调度执行。

问题复现代码如下：

import kotlinx.coroutines.*
import kotlinx.coroutines.channels.*

// 非内联库函数，会立即调用传入的f，入参为库内部生成的值
fun libraryFunction(f: (Int) -> Int) =
    f(5)

fun main() {
    // 外层调度器，部分场景下可能只有1个工作线程
    runBlocking(newSingleThreadContext("thread")) {
        // 已存在的通道
        val channel = produce {
            send("whatwewant")
        }
        // 业务代码
        libraryFunction { libraryProvidedValue ->
            println(libraryProvidedValue)
            runBlocking {
                println(channel.receive())
            }
            // 返回库需要的结果值
            7
        }
    }
}

• 该场景的最优解决方案是什么？
• 是否可以去掉内层的runBlocking？
• 有没有办法向编译器保证，传入的Lambda内部实际仍然处于同一个协程作用域中？

如果手动把库函数的逻辑内联到调用处，代码可以正常执行，不存在死锁问题：

import kotlinx.coroutines.*
import kotlinx.coroutines.channels.*

// 非内联库函数，会立即调用传入的f，入参为库内部生成的值
fun libraryFunction(f: (Int) -> Int) =
    f(5)

fun main() {
    // 外层调度器，部分场景下可能只有1个工作线程
    runBlocking(newSingleThreadContext("thread")) {
        // 已存在的通道
        val channel = produce {
            send("whatwewant")
        }
        // <手动内联库函数开始> 此处拿到库生成的入参libraryProvidedValue
        // 业务代码
        println(5)
        println(channel.receive())
        // <手动内联库函数结束>
    }
}

更新：该场景的核心矛盾是编译器无法识别传入Lambda的执行时机与外层协程的关系——但只要编译器能识别Lambda是在库函数调用栈内同步执行的，代码完全可以正常运行，手动内联的示例已经验证了这一点。本质上这段代码的执行逻辑没有问题，问题出在编译器无法推导「库函数会在自身方法体内同步调用传入Lambda」这个执行保证。
runBlocking虽然可以通过编译，但存在明确的副作用：最典型的就是嵌套阻塞问题，外层runBlocking可能占满唯一可用线程，导致协程间通信完全受阻。

目前临时可行的规避方案是把相关逻辑全部重构为Deferred风格，在顶层统一调用await，替代原有的suspend函数直接调用写法。这种写法不符合Kotlin协程的常规编码惯例，还存在资源泄漏等潜在风险，但在特定场景下可以正常运行。

注意：该规避方案没有从根本上解决上述问题，仅作为遇到同类问题的开发者的可选实现思路参考。

内容的提问来源于stack exchange，提问作者Infima