📚 课程目录第3章高频技术面试题（Java/Kotlin）

第3章：Java/Kotlin内存模型、并发编程、协程与高阶函数

本章聚焦大厂面试中 Java/Kotlin 底层机制的三大高频板块：内存模型与可见性、协程挂起/恢复原理、高阶函数与内联优化。每道题均给出“考察点→回答框架→示例→追问→避坑”完整闭环，并附实战项目模板，助你建立体系化应答能力。

面试问题	解释 Java 内存模型（JMM）中的可见性问题，并说明 volatile 如何保证可见性。
考察点	对 JMM 主存-工作内存交互的理解；happens-before 规则；volatile 读写语义及底层实现（内存屏障）。
回答框架	① JMM 定义：每个线程有工作内存，修改先写工作内存再同步主存 → 导致不可见；② volatile 写-读建立 happens-before 关系：写后立即刷新主存，读前强制从主存加载；③ 底层通过 lock 前缀指令 + 内存屏障禁止重排序。
示例回答	“JMM 中线程对共享变量操作在自己的工作内存完成，其他线程不可见。volatile 写操作插入 StoreStore 和 StoreLoad 屏障，强制刷入主存；读操作插入 LoadLoad 和 LoadStore 屏障，强制从主存重新读取，从而保证一个线程的写对另一个线程立即可见。”
可能追问	volatile 能保证原子性吗？内存屏障的具体类型？x86 中 volatile 实现用了什么指令？
避坑提醒	❌ 错误说法“volatile 加锁了”；❌ 混淆 volatile 与 synchronized 的语义；✅ 强调 volatile 只保证可见性和有序性，不保证原子性。

面试问题	Kotlin 协程的挂起和恢复是如何实现的？与线程阻塞有何区别？
考察点	协程状态机；Continuation 传递；挂起函数的 CPS 变换；切点调度（Dispatchers）。
回答框架	① 协程编译为状态机，每个挂起点对应一个状态；② 挂起函数在调用时多传递一个 Continuation 回调，执行完成后通过 resume 恢复；③ 挂起不会阻塞线程，仅保存栈帧到堆中，线程可执行其他任务；④ Dispatchers 决定恢复时在哪个线程执行。
示例回答	“挂起本质是编译器将协程体转为状态机，每次遇到 suspend 函数保存局部变量到 Continuation 对象并 return；恢复时调用 Continuation.resume，状态机从对应状态继续执行。整个过程无需阻塞线程，比线程切换更轻量。”
可能追问	协程与线程的开销对比？如何自定义 Dispatcher？协程在 Android 中如何避免内存泄漏？
避坑提醒	❌ 误以为挂起就是让线程让出 CPU；✅ 挂起是释放线程资源，由调度器决定后续执行；❌ 在 Main 线程大量挂起导致雪崩，需结合 withContext 合理切换。

面试问题	Kotlin 高阶函数的性能开销有哪些？inline 关键字如何优化？什么场景不应使用 inline？
考察点	Lambda 表达式生成的匿名类；对象分配与栈帧；inline 函数内联展开机制；noinline 与 crossinline 差异。
回答框架	① 普通高阶函数每次调用生成匿名内部类对象，增加 GC 压力；② inline 把函数体直接复制到调用处，消除对象创建和调用栈开销；③ 但 inline 可能增大代码体积，且不能用于递归/大函数；④ noinline 阻止特定参数内联；crossinline 禁止非局部 return。
示例回答	“高阶函数如果接收 lambda 作为参数，非 inline 时每次调用都会创建一个 Function 对象。inline 让编译器将 lambda 体直接嵌入调用点，彻底消除对象分配。但 inline 会复制代码，大函数或递归调用时需避免，否则导致包体积膨胀。”
可能追问	crossinline 为什么不能使用 return？inline 函数如何影响非局部返回行为？实战中哪些场景必写 inline？
避坑提醒	❌ 对所有高阶函数加 inline 导致方法区溢出；✅ 仅对 lambda 频繁调用的工具函数使用 inline；注意 inline 函数不能访问 private 成员（因为会展开到调用处）。

项目名称	直播弹幕 & 礼物推送模块重构
业务背景	日活 5000 万直播间，弹幕延迟从 200ms 突增到 5s，用户大量投诉。
规模指标	平均 QPS 15 万，峰值 50 万；弹幕合并后每秒写入 10 万条；内存常驻 300MB。
技术栈	Kotlin + Kotlinx.coroutines + Channel + Flow + RxJava (迁移中) + 自定义 Dispatchers
核心难点	① 大量协程创建导致线程池资源耗尽；② 弹幕数据竞争引发 ConcurrentModificationException；③ 消息合并窗口使用原 synchronized 锁粒度太大。④ 挂起函数内调用了阻塞 I/O 导致线程挂起效率低下。
面试高频追问	1. 协程如何实现流量整形？使用 Channel 还是 Flow？请具体说明。2. 如何用 JMM 可见性原理解释 ObservableList的并发问题？3. 在高 QPS 下 inline 高阶函数是否造成方法区溢出？怎么监控？4. 如果让你用协程实现一个带反压的滑动窗口，你会怎么设计？
可迁移回答话术	“直播间消息推送是典型的 high-throughput + low-latency 场景。我采用协程 Channel 作为生产-消费缓冲区，使用 conflict-free replicated data type 合并弹幕，并利用 AtomicReference + volatile 保证计数器可见性。关键优化点是将阻塞 I/O 替换为异步回调，配合 Dispatchers.IO 限流。最终延迟降至 80ms 以内，且内存抖动减少 70%。”

💡 进阶提示： 面试官通常会追问“如果使用协程 Flow 的 backpressure 策略，你会怎样选择？” 建议准备两份对比话术：一是 buffer + conflate 处理突发峰值，二是使用 channelFlow 自定义反压，视场景选择。

⚠️ 避坑重点： 不要只讲理论没有数据。上述项目案例中“延迟降至 80ms”需要给出具体对比值；同时准备协程与 RxJava 的优劣对比，突出协程在 Android 端取消可控性和代码简洁度。