[!info] 关联笔记

• 所属 MOC：JVM 与运行时 · 学习路线
• 前置概念：平台哲学 · 类加载
• 后续概念：性能方法论 · 容器部署
• 容易混淆：JNI vs Panama/FFM（较新）

JNI 概览

这个概念为什么出现

极少数场景必须调用 OS API、硬件 SDK 或既有 C/C++ 库。JNI 是经典互操作桥，但破坏 WORA 的“无本地假设”，并引入崩溃与内存风险。

[!abstract] 一句话理解 JNI 通过 native 方法把调用转到本地库；用可移植性与安全边界换取本地能力，应作为最后手段并严格隔离。

最小可观察示例

场景：声明 native 方法（不链接真实库，仅展示形态）

public class NativeTime {
    static {
        // System.loadLibrary("native_time"); // 真实场景加载
    }
    // public native long monotonicNanos();
    public static void main(String[] args) {
        System.out.println("jni-boundary-demo");
    }
}

javac NativeTime.java && java NativeTime

期望：

jni-boundary-demo

真实项目还需：.c/cpp、头文件生成、System.loadLibrary、平台构建矩阵。

结合场景再看三个关注点

1. 本地崩溃可拖垮 JVM 进程。
2. 每平台交付本地 .so/.dll/.dylib。
3. 优先查是否有纯 Java 或 FFM 新方案。

核心概念与准确模型

1. 边界

Java 声明 native → 本地实现导出符号。

2. 引用与临界区

本地代码访问 Java 对象需谨慎，防 GC 移动等问题（按 JNI 规范处理引用类型）。

3. 替代

• 进程外 sidecar
• Panama/Foreign Function & Memory API（版本相关）

边界情况与反直觉行为

1. 难以调试的 mixed stack。
2. 容器镜像架构（amd64/arm64）必须匹配。
3. 安全策略可能禁 loadLibrary。

常见误区

[!warning] 常见误区：为了“更快”先写 JNI 多数热点应先算法与分配，再测；JNI 调用本身也有成本。

工程实践

1. 本地代码最小化表层。
2. 严格 CI 多架构。
3. 崩溃处理与可观测。
4. 文档写清非纯 Java 依赖。

本节总结

• JNI=本地桥
• 可移植性与安全代价高
• 最后手段

自测题

1. JNI 如何影响 WORA？
2. 为何容器要多架构构建本地库？

参考答案

1. 引入平台相关二进制，不再“只发 jar 即可到处跑”。
2. CPU 架构不同，本地指令与 ABI 不通用。

延伸阅读与资料来源

资料	类型	支撑内容
JNI Specification	规范	JNI
FFM API	JEP	较新互操作