# 1. 多语言代码的可观测与错误栈跨语言 A 每种语言栈独立，无需关联 B 跨语言错误无法追踪 C 需统一 Trace ID 跨语言透传、统一日志格式，并用 PolyglotException 保留原始异常栈便于定位 ✓ 正确答案 D 可观测性与语言无关，无需透传
# 2. 多语言场景下的 GC 与内存视角 A 所有语言共享一个 GC B 跨语言对象无需管理引用 C 多语言内存无额外开销 D 各语言运行时各自管理堆，跨语言对象引用需宿主 GC 追踪，多语言堆叠加导致内存占用需权衡 ✓ 正确答案
# 3. Arena 内存生命周期管理与内存泄漏防护 A Arena 需要手动释放每个 segment B Arena 与内存泄漏无关 C Arena 只能在 JNI 中使用 D Arena 定义作用域，关闭时自动释放该作用域所有 segment，并提供访问检查防泄漏与悬垂 ✓ 正确答案
# 4. FFM API 的 MemorySegment 替代 JNI 直接访问 native A MemorySegment 通过作用域与访问检查安全地直接访问 native 内存，配合 Linker 声明式调用，替代繁琐的 JNI 桥接 ✓ 正确答案 B FFM 仍需手写 C 桥接 C MemorySegment 与 JNI 无关 D MemorySegment 只能访问 Java 堆
# 5. FFM 的 VarHandle 访问结构化内存布局 A VarHandle 只能访问基本类型 B 布局无需声明即可访问 C 用 MemoryLayout 描述结构体布局，VarHandle 按字段路径类型安全地读写，替代手写偏移量 ✓ 正确答案 D VarHandle 无法访问结构体
# 6. FFM 相比 JNI 的安全性与性能优势 A FFM 提供类型安全与作用域检查、纯 Java 声明式调用且性能接近/优于 JNI，是替代 JNI 的主流方向 ✓ 正确答案 B FFM 仍需手写 C 桥接 C FFM 安全性不如 JNI D FFM 比 JNI 性能差很多
# 7. JS/Python 调用 Java 对象的方法与类型映射 A JS 无法调用 Java 方法 B 通过 Polyglot 互操作，JS/Python 用 Java.type 等调用 Java 方法，标量/对象/数组/方法按规则映射 ✓ 正确答案 C 类型映射无需任何规则 D 跨语言调用无类型转换差异
# 8. Linker 与 FunctionDescriptor 定义 native 函数签名 A Linker 只做内存分配 B FunctionDescriptor 描述 native 函数签名，Linker 生成 downcall 句柄调用 native 函数 ✓ 正确答案 C FunctionDescriptor 与函数签名无关 D FFM 无法调用 C 库
# 9. Polyglot 上下文的资源管理与线程安全 A Context 默认非线程安全，需每线程独立或同步访问，并用 close 释放其运行时资源 ✓ 正确答案 B Context 天然线程安全 C Context 无需释放资源 D 多线程可共享同一 Context 无竞争
# 10. 使用 FFM 调用 C 库（如 zstd/opencv）的案例 A FFM 无法调用 C 库 B 通过加载库、downcallHandle 定义函数签名、MemorySegment 分配缓冲区、调用并解析结果来复用 C 库 ✓ 正确答案 C FFM 调用 C 库仍需 JNI D 调用 C 库只需一次声明无需内存处理
# 11. 多语言互操作的典型落地场景评估 A 多语言互操作无任何成本 B 所有场景都应使用多语言 C 多语言只用于脚本 D 典型场景是脚本嵌入、native 库复用、多语言生态复用与 WASM 沙箱，评估要看收益是否大于复杂度 ✓ 正确答案
# 12. 多语言互操作的性能与隔离边界 A 多语言互操作无性能开销 B 跨语言调用有桥接与类型转换开销，隔离越强性能开销越大，需按可信度选择隔离级别并减少跨语言调用 ✓ 正确答案 C 所有多语言都应使用最强制隔离 D 隔离不影响性能
# 13. 多语言混合构建（Maven/Gradle）的插件配置 A native image 不支持多语言 B 多语言构建无需插件 C 用 graalvm-maven-plugin 或 org.graalvm.buildtools.native 集成多语言，并配置 native image 的元数据与语言资源 ✓ 正确答案 D Gradle 无法构建多语言
# 14. 多语言调用的安全沙箱与权限控制 A 通过 Context 访问开关与 WASM 沙箱做能力隔离，用资源限制与最小权限控制不可信代码 ✓ 正确答案 B 多语言代码天然安全 C 沙箱无需限制资源 D 不可信代码可访问全部宿主能力
# 15. FFM 在 JDK 25/26 的正式状态与启用参数 A FFM 在 JDK 26 被移除 B FFM 在 JDK 25 仍是孵化 API C FFM 无需任何参数即可访问 native D FFM 已是正式 API，使用 native 访问需配置 --enable-native-access 授权，否则会有警告 ✓ 正确答案
# 16. Java 调用 JavaScript（GraalJS）的 Context 与 Value A Value 只能表示标量 B Context 执行 JS 脚本，Value 封装跨语言类型并支持 execute/getMember 调用与访问 ✓ 正确答案 C Java 无法把对象传给 JS D Context 不需要关闭
# 17. 脚本嵌入（规则/模板）使用 GraalJS 的取舍 A GraalJS 让规则动态可配省去发布，但需权衡性能（缓存）、安全（沙箱）与维护成本 ✓ 正确答案 B 脚本嵌入无任何额外成本 C 脚本在性能敏感路径也最优 D 规则固定场景也适合用脚本
# 18. FFM 与 Vector API 协同处理 native 数组 A FFM 自带 SIMD 计算 B FFM 提供 native 内存访问，Vector API 用 SIMD 向量化计算，两者协同高效处理 native 数组 ✓ 正确答案 C Vector API 无法访问 native 内存 D 两者无法协同
# 19. GraalVM Truffle 语言实现（JS/Python/R）互操作 A Truffle 只能实现一种语言 B 各语言互操作无统一机制 C Truffle 框架让各语言共享 Graal 编译器与统一 Interop 协议，实现 JS/Python/R 等无缝互操作 ✓ 正确答案 D 互操作与编译无关
# 20. GraalVM 安装与 polyglot 镜像构建流程 A native image 不支持多语言 B 安装 GraalVM 后，用 native-image 编译时启用语言运行时（--language:*）并配置 reflect/resource 元数据构建 polyglot 镜像 ✓ 正确答案 C polyglot 镜像无需元数据配置 D GraalVM 只能运行一种语言
# 21. GraalVM 的 GraalWasm 运行 WebAssembly 模块的原理 A GraalWasm 是独立于 GraalVM 的运行时 B GraalWasm 不基于 Truffle C GraalWasm 无法执行 WASM D GraalWasm 基于 Truffle 把 WASM 解析为 AST，用自优化解释器执行并可由 Graal 编译器优化 ✓ 正确答案
# 22. GraalWasm 与 Wasm 运行时 在 JIT（AOT vs Lazy compilation）模式下的运行时开销与启动延迟？ A AOT 启动延迟更低 B Lazy/JIT 稳态性能一定更好 C AOT 启动延迟高但稳态性能好，Lazy/JIT 启动快但运行时开销有波动，按启动频率与稳态吞吐权衡 ✓ 正确答案 D 两种模式无差异
# 23. GraalWasm 与 Wasm 运行时 在 WASI Preview2、Component Model 上的沙箱与系统调用代理？ A WASM 可直接访问系统 B WASM 通过宿主注册的 WASI 函数代理访问系统，宿主控制能力权限，Component Model 让接口更结构化可组合 ✓ 正确答案 C Component Model 削弱隔离 D WASI 与沙箱无关
# 24. GraalWasm 的启动与内存隔离特性 A GraalWasm 解释执行启动快，每个 WASM 模块用独立线性内存且只能通过显式函数边界与宿主交互，实现强隔离 ✓ 正确答案 B WASM 模块可访问宿主 Java 堆 C GraalWasm 无内存隔离 D GraalWasm 启动慢
# 25. Java 与 WASM 之间的线性内存（Linear Memory）交互 A 线性内存不能共享给宿主 B Java 可直接访问 WASM 对象 C Java 通过 memory API 读写 WASM 的线性内存，按偏移量传递数据，WASM 函数处理后再写回 ✓ 正确答案 D Java 与 WASM 无法传数据
# 26. Truffle 的 AST 解释与部分求值（Partial Evaluation） A 部分求值与编译无关 B Truffle 纯解释执行无优化 C AST 自优化消除动态开销，部分求值把解释器特化为针对该语言程序的机器码，获得接近原生性能 ✓ 正确答案 D AST 自优化会降低性能
# 27. WASM 与 JVM 沙箱（SecurityManager 移除后）的替代 A WASM 无法执行不可信代码 B WASM 沙箱比 Java 权限检查更弱 C SecurityManager 移除后无需沙箱 D WASM 以线性内存与显式函数边界提供强隔离，可安全执行不可信代码，替代被移除的 SecurityManager ✓ 正确答案
# 28. WASM 在 Java 中作为沙箱执行不可信代码的场景 A 不可信代码可直接访问宿主系统 B WASM 沙箱无法隔离内存 C 把不可信代码编译为 WASM，用受限导入函数与线性内存隔离执行，宿主控制能力，实现强隔离 ✓ 正确答案 D WASM 沙箱只适合可信代码
# 29. WASM 在插件化/规则扩展中的轻量隔离价值 A WASM 模块小、启动快、内存隔离强，比进程隔离轻比同进程代码安全，适合动态插件/规则场景 ✓ 正确答案 B WASM 隔离比进程隔离更强 C WASM 插件无法动态加载 D WASM 隔离开销比进程还高
# 30. WASM 在边缘/Serverless 函数运行时的应用 A WASM 启动快、资源低、隔离强、可移植，适合 Serverless/边缘函数运行时，替代容器/VM ✓ 正确答案 B WASM 启动比容器慢 C WASM 只能用于浏览器 D WASM 函数运行时无法隔离多租户
# 31. WASM 模块签名与版本管理 A WASM 模块无需签名 B 通过数字签名验签确认模块来源可信，用版本元数据管理多版本与回滚，保障供应链安全 ✓ 正确答案 C 版本管理只影响性能 D 签名与安全无关
# 32. WASM 的系统接口（WASI）与 Java 宿主函数 A WASM 通过 WASI 标准接口调用宿主（Java）注册的函数，宿主代理系统能力并做权限控制 ✓ 正确答案 B WASM 可直接访问系统 C 宿主函数与 WASI 无关 D Java 宿主无法控制 WASM 权限
# 33. native image 中嵌入多语言运行时的体积控制 A 多语言运行时体积无法控制 B 通过按需启用语言、裁剪未用资源与特性、只打包必要内容来控制体积，权衡体积与能力 ✓ 正确答案 C 嵌入所有语言体积最小 D native image 不支持多语言
