Scala Native 与 GraalVM：AOT 编译、互操作与部署

JIT（JVM 默认）：
□ 字节码 → 解释执行 → 热点方法被 C1/C2 JIT 编译
□ 优点：动态优化（profile-guided）、反射/动态特性天然支持
□ 代价：启动慢（先解释再优化）、内存大（编译器常驻）
AOT（native-image / Scala Native）：
□ 源码/字节码 → 直接编译成机器码（可执行文件）
□ 优点：毫秒级启动、内存小、无 JIT 编译器驻留
□ 代价：编译期决定一切（封闭世界）、动态特性受限
关键 trade-off：
□ 峰值性能：JIT 长期跑可达更高（profile 优化）
□ 冷启动/内存：AOT 完胜（Serverless/CLI 场景关键）
□ 两者不互斥：GraalVM 支持 PGO（profile 引导 AOT 再优化）

适用判断：
□ 启动敏感 + 内存敏感 → AOT（CLI、Serverless、边缘）
□ 长生命周期 + 峰值性能 → JVM（服务端常驻）
□ 混合：AOT 做入口，热点库仍可 JIT（GraalVM 混合模式）

技术栈：
□ Scala 源码 → NIR（中间表示）→ LLVM IR → 机器码
□ 运行时：自带的原生运行时（非 JVM）
□ GC：默认 Immix（分代、非阻塞、可关闭）
  → 可选用无 GC / 手动内存（critical 场景）
□ 无 JVM：无 JIT、无反射、无动态类加载
定位差异：
□ 产物：单一可执行文件（静态链接 C 库）
□ 生态：支持 Scala 标准库子集 + 部分库
  → 纯 Scala 代码多可用，JVM 特性（反射/动态代理）受限
□ 与 Scala.js 对比：Scala Native 编译到 LLVM（机器码），
  Scala.js 编译到 JS（浏览器/Node）
何时用 Scala Native：
□ 需要毫秒启动 + 小体积的 CLI/工具
□ 需要直接调用 C 库（LLVM/系统 API）
□ 嵌入式/资源受限环境（无 JVM 可装）

// build.sbt：启用 Scala Native
import scala.scalanative.build.*
enablePlugins(ScalaNativePlugin)
scalaVersion := "3.3.1"
nativeConfig := nativeConfig.value
  .withGC(GC.immix)          // 默认分代 GC
  .withLTO(LTO.thin)         // 链接时优化
  .withMode(Mode.releaseFast) // 发布模式

互操作核心：
□ @extern：把 C 函数声明成 Scala 方法
□ C 类型映射：int/long/char* → Int/Long/CString
□ CString：C 字符串（fromCString/toCString 互转）
□ Zone：作用域内存分配（自动释放）
□ 结构体/联合：用 CStructN 布局
链接 C 库：
□ 用 cquill 或 @link 注解声明外部库
□ 编译时链接系统库 / 静态库
□ 也可用 sbt 配置 libraryDependencies 里的原生库
安全要点：
□ 原生指针是 unsafe：包在 Zone 里用，避免裸指针泄漏
□ 跨边界数据拷贝（把 C 数据拷进 Scala 结构再处理）
□ C 回调：用 CFuncPtr 声明函数指针

import scala.scalanative.unsafe.*
import scala.scalanative.libc.stdlib
@extern
object libc:
  def strlen(s: CString): CSize = extern
// 在 Zone 里安全使用 C API
def cDemo(): Unit = Zone.acquire { z =>
  val msg = toCString("hello native")(z)
  val len = libc.strlen(msg)
  println(s"len = $len")
}

native-image 流程：
① 静态分析（Points-to Analysis）：从入口出发
   追踪所有「可达代码」（封闭世界假设）
② 堆快照：把初始堆对象也编译进镜像（毫秒启动的关键）
③ SubstrateVM：精简版 JVM 运行时（无 JIT/无类加载）
④ 生成：一个可执行文件（含应用 + 运行时 + GC）
封闭世界假设：
□ 编译期必须「看得见」所有可达代码
□ 反射/动态代理/序列化需显式登记（reachability metadata）
□ 做不到的：运行时类加载、动态代理、反射的任意调用
支持现状：
□ Scala：Scala 3 的 native-image 兼容性已较好
□ 常用库：需 reflection-config 文件配合
□ Akka/http4s 等框架：有官方/社区 native 配置

# 编译原生镜像（需要 Scala 的 reflection 配置）
native-image -cp "target/scala-3.3.1/classes:..." \
  --no-fallback -H:ReflectionConfigurationFiles=reflect-config.json \
  -o myapp com.example.Main

Truffle 多语言：
□ 用「自优化 AST 解释器」实现各语言（JS/Python/Ruby/LLVM...）
□ 各语言共享 SubstrateVM/编译器，可互相调用
□ polyglot API：Java/Scala 程序内嵌调用 JS/Python
与 native-image 的关系：
□ native-image：把「宿主语言 + Truffle 语言」一起编译进镜像
□ 一个镜像 = 宿主程序 + 内嵌的 JS/Python 运行时
□ 用 GraalPy/GraalJS 可在原生镜像里跑 Python/JS 逻辑
场景：
□ 多语言脚本嵌入（规则引擎用 JS、数据处理用 Python）
□ LLM/语言类应用：宿主 Scala + 策略脚本 JS
□ 性能：Truffle 优化后接近原生语言性能（有快路径）
Scala 侧使用：
□ org.graalvm.polyglot 的 Context 建多语言上下文
□ 在 native-image 里声明需加载的语言资源

// 在 JVM/原生镜像里调用 JavaScript（polyglot API）
Context ctx = Context.newBuilder("js").build();
Value result = ctx.eval("js", "1 + 2 * 3");
System.out.println(result.asInt());   // 7

动态特性清单：
□ 反射（Class.forName / getMethod / invoke）
□ 动态代理（Proxy.newProxyInstance）
□ 序列化（Jackson/Gson 反射式读写）
□ 资源加载（Class.getResource、SPI 服务发现）
□ 方法句柄（MethodHandle，部分）
处理方式：
□ reflection-config.json：显式列出要用反射的类/方法
□ proxy-config.json：列出动态代理接口
□ resource-config.json：列出要打包的资源
□ serialization-config.json：列出可序列化类
□ @RegisterReflectionForBinding / 追踪标记（trace）
□ 编译期 `-H:+ReportUnsupportedElementsAtRuntime` 暴露问题
调试工具：
□ native-image --trace-class-initialization=...
□ 运行时报 UnsupportedOperationException → 找 metadata 缺口
□ 大量框架类：用 GraalVM 的 reachability 追踪器收集
Scala 特别注意：
□ case class 序列化（Jackson）要注册构造器/字段
□ 泛型/类型标签（TypeTag）是反射 → 需 metadata
□ 库内部反射（如某些 DI）是隐藏坑

// reflect-config.json（示意）
[
  { "name": "com.example.Order", "allDeclaredConstructors": true, "allDeclaredFields": true },
  { "name": "com.example.pkg.Serializer", "methods": [ { "name": "write", "parameterTypes": [] } ] }
]

基准量级（典型场景，示意）：
□ 启动时间：JVM 300-1500ms vs 原生 5-50ms（快 10-100x）
□ RSS 内存：JVM 200-500MB vs 原生 20-80MB（小 5-10x）
□ 峰值吞吐：JVM（JIT 优化后）通常高 10-30%
□ 长稳延迟：JVM 有 JIT 渐进提升，AOT 无冷启动抖动
□ 打包体积：JVM fat-jar 50-150MB vs 原生 20-60MB（静态链接）
性能来源：
□ AOT 快启动 = 无解释期 + 堆快照（对象已就位）
□ AOT 小内存 = 无 JIT 编译器、无类加载器、无字节码驻留
□ JVM 高吞吐 = 运行期 profile 优化 + 逃逸分析 + 内联更激进
PGO（Profile-Guided Optimization）：
□ 用运行期 profile 引导 AOT 编译（GraalVM 支持）
□ 缩小与 JIT 的吞吐差距（接近/持平）

实测注意：
□ 基准要跑「同一算法」而非「框架 hello world」
□ 关注 p99 与 GC 停顿分布，不只均值
□ Serverless 计费看冷启动 + 内存，AOT 优势放大

典型场景：
□ CLI 工具：毫秒启动、无需装 JVM、可放进 /usr/local/bin
□ Serverless（AWS Lambda/FaaS）：冷启动秒级变毫秒级，计费降
□ 边缘/嵌入式：资源受限设备（无 JVM 可装）
□ 容器：scratch/精简基础镜像（仅可执行文件 + 必要库）
□ 侧车（sidecar）：与主服务同进程部署、低开销
部署形态：
□ Scala Native：直接静态可执行（可选静态链接 libc）
□ GraalVM native-image：可执行文件，可静态/动态链接
□ 两者都适合「无 JVM 的容器镜像」
集成注意：
□ 配置注入：环境变量/文件（避免反射式配置）
□ 信号处理：原生程序处理 SIGTERM/SIGINT（优雅停机）
□ 日志/指标：标准输出 + 文件（无需 JVM 管理接口）
□ 安全：镜像内容可控（封闭世界无多余字节码）

部署清单：
□ 决定静态 vs 动态链接（静态体积大但零依赖）
□ 容器里不含 JVM，用多阶段构建减小镜像
□ 配置/密钥走环境变量或挂载文件
□ 做一次「原生镜像里的可观测性」验证（日志/指标可用）

Scala Native 构建：
□ sbt plugin：scala-native（enablePlugins(ScalaNativePlugin)）
□ 命令：sbt nativeLink → 产物 target/.../out
□ 配置：nativeConfig（GC/LTO/模式/日志）
□ 测试：nativeTest 跑原生版测试套件
GraalVM 构建：
□ 先编译成 class（sbt compile）
□ 用 native-image CLI 或 sbt-native-packager / graalvm 插件
□ 需配 reflection/proxy/resource metadata
□ CI 缓存：native-image 构建慢（分钟级），缓存 GraalVM 与目标
CI 实践：
□ 构建矩阵：JVM + native 双产物
□ 原生测试单独 job（耗时更长、要 GraalVM 环境）
□ 缓存：~/.graalvm、sbt 依赖缓存
□ 失败快照：记录 trace 输出便于补 metadata
版本注意：
□ Scala Native 对 Scala 版本有跟进节奏（3.x 支持）
□ GraalVM 版本与 JDK/框架兼容性要匹配
□ 用 CI 矩阵锁定「JDK + GraalVM + Scala」组合

# GitHub Actions 示意（片段）
- uses: graalvm/setup-graalvm@v1
  with:
    version: 'latest'
    java-version: '21'
    components: 'native-image'
- run: sbt "graalvm-native-image:packageBin"
- run: ./target/.../myapp --help   # 验证产物可执行