Java与AI：用 DJL 或 ONNX Runtime 在 JVM 里跑推理，JNI 侧的 native handle 泄漏直接吃掉 GPU 显存，Java 堆看起来正常但进程 OOM——到底该用 NDManager 的 try-with-resources 兜底，还是必须上 Arthas 抓 Direct Memory？

摘要：在 JVM 上部署深度学习推理（DJL、ONNX Runtime Java API）时，一个反复出现的故障模式是：Java 堆监控曲线平稳，GC 日志健康，但容器 RSS 持续攀升直至被 OOM Killer 终止，或 GPU 显存被逐步蚕食。根因往往不在 Java 对象本身，而在 JNI 侧持有的 native handle——它们指向引擎内部的内存池、CUDA 上下文与设备缓冲区，对 JVM 的 GC 完全不可见。本文以“资源所有权跨语言边界断裂”为贯穿主线，先界定 native handle 与 Direct Memory 的语义差异，再拆解 DJL 的 NDManager 引用计数模型与 ONNX Runtime 的 OrtSession / OrtValue 生命周期，随后给出以 try-with-resources 为第一道防线、以 Arthas + JFR + NMT 为第二道观测防线的分层治理路径，并讨论容器化与 GPU 场景下的边界条件。全文强调：资源释放是设计问题，可观测性是验证问题，二者不可互相替代。

目录

SECTION 01问题的重新定义：堆正常、进程死，究竟是谁在泄漏

先把现象摆清楚。一个典型的 JVM 推理服务在压测或长稳运行后，会出现如下组合症状：jstat -gc 显示老年代占用稳定、Full GC 后堆回落正常；但 top 或容器指标显示 RSS 单调上升；最终进程被内核 OOM Killer 杀死，或 nvidia-smi 显示显存被占满而推理请求开始抛 CUDA out of memory。

这个组合之所以令人困惑，是因为它同时否定了两个最常见的直觉：其一，“堆正常说明没有内存泄漏”——这个推论只在纯 Java 对象图内成立；其二，“OOM 一定是堆太小”——在 JNI 场景下，进程被杀与堆大小可以毫无关系。真正的问题域是堆外（off-heap）与设备侧（device-side）资源，而这两类资源的生命周期由 native 代码而非 JVM 的垃圾回收器管理。

笔者认为，把这类故障命名为“native handle 泄漏”是准确的，但容易让人误以为它只是“忘记调用 close()”这种低级错误。实际上它包含三个层次：语义层（谁拥有这块资源）、时序层（何时释放、释放是否幂等）、观测层（泄漏发生时能否被看见）。绝大多数线上事故是三层同时失守的结果——代码里没有作用域约束，运行时没有堆外指标，于是泄漏只能在进程崩溃时以最昂贵的方式被发现。

因此本文的分析主线是：资源所有权跨越 JNI 边界时的断裂，以及如何用“设计约束 + 观测验证”两条腿把它重新接上。try-with-resources 与 Arthas 不是二选一的对立选项，它们分别回答“如何不泄漏”和“如何证明没泄漏/定位已泄漏”，缺一不可。

SECTION 02背景与概念边界：native handle、Direct Memory 与设备内存

2.1 三个容易混淆的“内存”

在讨论泄漏之前，必须把三个概念分开，否则后续的排查手段会张冠李戴。

概念	分配者	回收者	典型观测手段
Java 堆	JVM	GC	jstat、GC 日志、Heap Dump
Direct Memory / 本地内存	JVM（ByteBuffer.allocateDirect）或 native 库（malloc/cudaMalloc）	Cleaner / 显式 free / 引擎析构	NMT、JFR、pmap、RSS
GPU 设备内存	CUDA 运行时 / 引擎内存池	引擎析构、cudaFree、内存池回收	nvidia-smi、DCGM、引擎自带统计

注意 Direct Memory 与 GPU 设备内存并不等同：前者是主机侧（host）的本地内存，后者是设备侧（device）的显存。一次未释放的 native handle 可能同时钉住两者——例如一个指向 CUDA 张量的句柄，其元数据在 host 侧，数据在 device 侧。这就是为什么有时表现为 RSS 上涨，有时表现为显存上涨，有时两者同时发生。

2.2 native handle 的准确定义

本文所称 native handle，指 Java 对象中持有的一个指向 native 侧资源的标识符（通常是一个 long 型指针或句柄值）。Java 对象本身很小，可能只有几十字节；但它代表的 native 资源可能是数百 MB 的显存缓冲区。二者之间是“代理—实体”关系，而 JVM 的 GC 只认识代理，不认识实体。

这就引出一个关键判断：Java 对象的可达性，与 native 资源的存活，是两条独立的生命周期线。当代理对象被回收时，是否触发实体的释放，取决于实现是否注册了 finalizer、Cleaner 或 PhantomReference 回调。即便注册了，回收时机也是不确定的——这正是“堆看起来正常”却持续泄漏的机制根源。

本文评述：把 native handle 泄漏简单归因于“没写 close()”是一种工程上的偷懒。更准确的表述是：JVM 缺乏对跨语言资源所有权的强制约束机制，语言层面没有类似 Rust 所有权或 C++ RAII 的编译期保证，因此只能靠约定、API 设计与运行时观测来补偿。理解这一点，才能解释为什么“加了 try-with-resources 仍然泄漏”的情况真实存在——因为作用域可能画错了，或者资源被缓存/池化后逃逸出了作用域。

2.3 为什么这个问题在 AI 推理场景被放大

传统 JNI 应用（如 JDBC 驱动、压缩库）也有 native 资源，但单次分配量小、生命周期短，泄漏速率低，往往在进程重启周期内不显现。AI 推理则不同：单次张量分配可达数十 MB 到数 GB，请求频率高，且 GPU 显存总量有限（消费级 8–24 GB，数据中心级 40–80 GB）。这意味着同样的泄漏速率，在 AI 场景下的暴露时间被压缩了一到两个数量级。

此外，推理引擎普遍采用内存池与 arena 分配策略以减少 cudaMalloc 调用。池化提升了性能，但也让“释放”变成“归还给池”而非“还给系统”，使得 nvidia-smi 上的显存占用呈现“只增不减”的锯齿形态。本文认为，这要求观测手段必须能区分“池内空闲”与“真正泄漏”，否则极易误判。

SECTION 03DJL 的资源模型：NDManager、引用计数与作用域

3.1 NDManager 的设计意图

Deep Java Library（DJL）是 Amazon 开源的 JVM 深度学习框架，支持 PyTorch、TensorFlow、MXNet 等多种引擎后端。它引入 NDManager 的核心目的，正是为了解决跨语言资源管理问题：把一组 NDArray 的生命周期绑定到一个管理器上，管理器关闭时批量释放其名下的所有数组。

从设计模式看，这是作用域（scope）模式 + 组合（composite）释放：NDManager 形成树状层级，子管理器关闭时释放自己的资源，父管理器关闭时级联释放。NDArray 通过引用计数（reference counting）跟踪被多少个管理器持有，计数归零才真正释放 native 内存。

// 典型的作用域化写法（示意，非逐字复制官方示例）
try (NDManager manager = NDManager.newBaseManager()) {
    NDArray input = manager.ones(new Shape(1, 3, 224, 224));
    NDArray output = model.forward(input);   // output 归属同一 manager
    float[] data = output.toFloatArray();
    // 离开 try 块时 manager.close() 级联释放 input / output 的 native 资源
}

这段代码的价值不在于“用了 try”，而在于把资源的生命周期与一个词法作用域绑定，使释放时机从“GC 决定”变为“代码结构决定”。这是从不确定到确定的转变，也是本文认为最应该被强调的设计原则。

3.2 引用计数带来的两个陷阱

引用计数解决了共享所有权问题，但引入了两个在工程中高频出现的陷阱。

陷阱一：attach 与 detach 的不对称。DJL 允许把一个 NDArray 从一个管理器“挂靠”到另一个管理器（attach），以延长其生命周期。如果 attach 了却没有对应的 detach，或者 detach 次数与 attach 不匹配，引用计数就永远不会归零。这类问题在把张量跨线程传递、或缓存中间结果时尤其常见。

陷阱二：临时管理器的隐式创建。某些 API 在内部会创建临时 NDManager 并在方法结束时关闭，如果返回值仍引用其资源，就会出现“资源已释放但对象仍在用”的悬垂问题；反之，如果内部临时管理器未被关闭，则形成泄漏。本文评述：这类隐式行为是 API 设计上的双刃剑——它降低了初学者的使用门槛，却提高了排障时的认知负担，因为泄漏点不在调用方代码里，而在库内部。

3.3 为什么 try-with-resources 是“必要但不充分”

必须明确：try-with-resources 能保证在正常控制流与异常控制流下都调用 close()，这是它相对手动 close 的核心优势。但它无法保证三件事：

• 资源没有被缓存或池化到作用域之外（例如放进静态 Map 做推理结果缓存）；
• 资源没有被异步线程持有（提交到线程池后，作用域已结束但任务仍在跑）；
• close() 本身没有抛异常或被吞掉（某些引擎在关闭失败时只记日志）。

因此，try-with-resources 是第一道防线，它把绝大多数“忘记释放”的问题消灭在编码阶段；但它不是万能药，仍需第二道观测防线来验证“防线是否真的生效”。

SECTION 04ONNX Runtime Java API：OrtSession 与 OrtValue 的生命周期陷阱

4.1 两个核心对象

ONNX Runtime 的 Java 绑定相对“薄”，它把 C++ API 直接映射为 Java 类。其中最关键的两个是：OrtSession（承载模型与执行环境，内部持有 native 的 OrtSession 指针）与 OrtValue（承载输入/输出张量，可能位于堆外或设备侧）。二者都实现了 AutoCloseable。

与 DJL 的“管理器批量释放”不同，ONNX Runtime 采用逐对象显式关闭模型。这带来更细的控制粒度，也带来更高的遗漏概率：一个推理请求可能创建多个 OrtValue（多个输入、多个输出），任何一个未关闭都会钉住其底层缓冲区。

4.2 会话复用与线程安全

工程实践中，OrtSession 通常被设计为单例或长生命周期对象，因为创建会话涉及模型加载与图优化，代价高昂。这本身是正确做法，但会掩盖一个问题：会话不泄漏，不代表每次推理不泄漏。真正的泄漏点往往在每次请求创建的 OrtValue 上。

另一个容易忽视的边界是线程安全。ONNX Runtime 的会话在并发 Run 调用下是线程安全的（内部有执行器管理），但 OrtValue 的创建与关闭必须由调用方保证配对。若在异步回调中关闭，需确认回调一定被执行——异常路径、超时取消、线程池拒绝策略都可能让关闭逻辑被跳过。

// 每个请求内，输入输出都必须成对关闭（示意）
try (OrtSession.Result result = session.run(inputs)) {
    // 处理 result 中的输出
} finally {
    // 若 inputs 中的 OrtValue 是本次请求创建的，也必须在此关闭
    for (OrtValue v : inputs.values()) {
        v.close();
    }
}

本文评述：这段代码的形态暴露了 ONNX Runtime Java API 的一个结构性弱点——资源所有权没有在类型系统里表达出来。调用方无法从方法签名判断“传进去的 OrtValue 会不会被内部关闭”，只能靠文档与经验。这恰恰是 DJL 用 NDManager 试图解决的问题。两种设计各有取舍：前者灵活但易错，后者安全但学习曲线陡。

4.3 内存池与 arena 配置的影响

ONNX Runtime 提供内存模式配置（如启用 arena 分配器）以提升性能。启用后，释放的 OrtValue 内存会归还给 arena 而非操作系统，因此外部观测到的 RSS 或显存不会立即下降。这会造成两种误判：把正常池化当成泄漏，或把泄漏当成池化而延误处置。

笔者认为，正确的判读方法是观察“稳态”而非“瞬时值”：在固定负载下，若内存占用在若干个完整的请求周期后趋于平台，则是池化；若每个周期都抬升一个台阶且不回落，则高度怀疑泄漏。这一判据简单但有效，后文会给出具体的观测脚本思路。

SECTION 05泄漏的因果链：从一次未关闭的 handle 到 GPU OOM

5.1 一条完整的因果链

把机制串起来看，一次典型的泄漏演进包含五个环节：

1. 分配：某次推理创建了 native 资源（张量缓冲区、CUDA 上下文对象），Java 侧只持有一个小对象作为代理。
2. 逃逸：由于异常路径未关闭、或对象被缓存、或被异步任务持有，代理对象在作用域结束后仍然可达，或虽不可达但未被 Cleaner 处理。
3. 累积：请求持续到来，每次泄漏一点，native 侧占用单调上升。由于 GC 只看到小对象，堆指标毫无异常。
4. 挤压：显存或本地内存逼近上限，引擎开始分配失败或触发内部重试，延迟上升。
5. 崩溃：CUDA 返回 out of memory，或内核因 RSS 超限杀死进程。此时堆 dump 往往“干净得令人困惑”。

5.2 为什么 finalizer / Cleaner 兜不住

Java 提供了 finalizer 与 Cleaner 作为“最后一道保险”，但在高吞吐推理场景下它们不可靠，原因有三：

其一，触发时机不确定。Cleaner 依赖 GC 发现对象不可达，而小对象可能长期停留在年轻代，迟迟不触发回收。其二，吞吐不匹配。分配速率远高于清理速率时，积压会持续扩大。其三，执行线程受限。Cleaner 在专用线程上运行，若清理动作本身耗时（如释放大块显存），会形成瓶颈。

本文评述：把 Cleaner 当作主要释放手段，本质上是用“不确定的兜底”替代“确定的设计”，在低负载下看似有效，在高负载下必然失效。这与数据库连接池不能依赖 finalizer 关闭连接是同一个道理——工程界对此早有共识，只是在 AI 推理这个较新的领域里，教训还在被反复重学。

5.3 容器化环境下的额外变量

在 Kubernetes 中运行时，还有两个变量会改变故障形态。第一，cgroup 内存限制统计的是 RSS，包含堆外内存，因此 JVM 的 -Xmx 设置不再能代表进程的内存上限，必须为堆外预留空间。第二，GPU 显存不参与 cgroup 内存核算，显存耗尽可能先于容器 OOM 发生，表现为 CUDA 错误而非进程被杀。

这意味着同一个代码缺陷，在物理机上可能表现为进程被 OOM Killer 终止，在容器里可能表现为推理请求批量失败。排查时必须先确认“是哪一类资源先耗尽”，再选择对应的观测工具。

SECTION 06第一道防线：try-with-resources 与作用域化资源管理

6.1 作用域设计的三条规则

要让 try-with-resources 真正发挥作用，关键不在语法，而在作用域画得对不对。笔者总结三条可操作的规则：

规则一：资源的作用域应尽可能小，且与业务请求边界对齐。一次 HTTP 请求或一次消息处理对应一个管理器/一组 OrtValue，请求结束即释放。避免把管理器提升为类成员或静态字段。

规则二：禁止把 native 资源放入长生命周期容器。缓存推理结果时应缓存序列化后的字节或 Java 基本类型数组，而不是 NDArray 或 OrtValue。这是最容易被忽视的一条，因为“缓存张量”在代码上看起来非常自然。

规则三：异步任务必须显式转移所有权。若把资源提交给线程池，需明确由谁负责关闭，并在任务包装器中用 try-finally 保证执行。推荐做法是在提交前完成数据拷贝，让异步任务只持有纯 Java 数据。

6.2 一个可复用的请求级模板

public float[] infer(float[] input) {
    try (NDManager mgr = NDManager.newBaseManager()) {
        NDArray x = mgr.create(input).reshape(SHAPE);
        try (NDArray y = model.forward(x)) {   // 若引擎返回可关闭对象
            return y.toFloatArray();           // 立即转回 Java 数据
        }
    }
    // 出作用域后，native 资源确定释放；返回值不含任何 native 引用
}

这个模板的要点是“数据出、句柄留”：跨出方法边界的一律是纯 Java 数据，native 句柄绝不外泄。本文认为，这一约定比任何框架特性都更能从根上消除泄漏，因为它把“资源是否可能逃逸”变成了一个可以在代码评审中肉眼检查的问题。

6.3 静态检查与代码规范

仅靠自觉不够，需要工具兜底。可行手段包括：用 Error Prone 或 SpotBugs 的自定义规则检测“实现了 AutoCloseable 却未在 try-with-resources 中使用”的对象；在团队规范中明确“NDArray / OrtValue 不得作为字段或返回值”；在 CI 中加入架构测试（如 ArchUnit）禁止特定包之间传递 native 类型。

本文评述：这类静态约束的收益被严重低估。它们把一类运行时才暴露、且难以复现的故障，前移为编译期或评审期就能发现的问题，单位成本的下降是数量级的。相比之下，等到线上 OOM 再用 Arthas 去抓，代价要高得多——这也回答了标题中的设问：两者不是替代关系，而是成本相差两个数量级的前后两道工序。

SECTION 07第二道防线：Arthas、JFR 与 NMT 的联合观测

7.1 为什么需要“联合”而非单一工具

没有任何一个工具能同时回答“泄漏了多少”“泄漏在哪”“是谁分配的”。NMT 给出本地内存的分类统计，JFR 给出分配事件与采样，Arthas 给出运行时的对象与调用现场。三者互补，才能形成证据链。

工具	能回答的问题	不能回答的问题
NMT	JVM 自身分配的本地内存分类与总量	第三方 native 库（CUDA、引擎）的分配
JFR	分配采样、线程、GC、部分 native 事件	非 JFR 事件覆盖的引擎内部细节
Arthas	运行时对象统计、方法调用追踪、堆外相关命令	设备侧显存的精确归属

需要说明的是，NMT 只统计 JVM 通过其内部内存分配器申请的内存，第三方库直接调用 malloc 或 cudaMalloc 的部分不在其列。因此当 NMT 显示“内部内存稳定”而 RSS 上涨时，恰恰是重要线索：泄漏发生在 JVM 之外。

7.2 一套可执行的排查步骤

以下步骤按“先定性、再定位、后验证”的顺序组织，可直接用于线上排障。

步骤一：定性。在固定 QPS 下连续采集 RSS 与显存，绘制时间序列。若呈阶梯上升且不回落，判定为泄漏；若呈锯齿且平台稳定，判定为池化。采集间隔建议覆盖至少 10 个完整请求周期。

步骤二：分层归因。开启 NMT（-XX:NativeMemoryTracking=summary），用 jcmd <pid> VM.native_memory summary 查看分类。若 JVM 内部稳定而 RSS 上涨，转向第三方库。

步骤三：对象侧确认。用 Arthas 的 heapdump 导出堆快照，统计 NDArray / OrtValue 代理对象的数量。若代理对象数量随请求数线性增长，说明对象未被回收，问题在引用未断开；若代理对象数量稳定而 RSS 上涨，说明对象已回收但 native 资源未释放，问题在释放回调缺失。

步骤四：调用现场定位。用 Arthas 的 trace 或 stack 命令对创建资源的入口方法采样，统计调用栈分布，找出未被关闭路径对应的调用来源。

步骤五：修复验证。修复后重复步骤一，确认曲线恢复平台形态，并观察至少一个完整的发布周期。

7.3 关于“上 Arthas”的边界

Arthas 是诊断工具，不是治理方案。它能在事故中给出证据，但不能阻止事故。把它当作常规手段常驻生产，会带来额外开销与安全风险。本文建议：Arthas 用于事后定位与灰度验证，常态化的可观测性应依赖指标与 JFR 的持续采集。

此外，Arthas 对 native 内存的可见性有限，它擅长的是 Java 对象与调用链。若怀疑问题在 CUDA 侧，还需结合 nvidia-smi、DCGM 指标或引擎自带的内存统计。这一点在排障时经常被混淆，值得反复强调。

SECTION 08关键数据与案例：可复现的观测指标与判读方法

8.1 模拟数据：泄漏速率与暴露时间的关系

为说明“为什么 AI 场景更容易暴露”，下面给出一组模拟数据（基于公开的显存容量规格与假设的泄漏速率计算，非实测）：

单次泄漏量	QPS	每小时泄漏	耗尽 16 GB 显存所需时间
1 MB	50	约 176 GB	约 5.5 分钟
1 MB	5	约 17.6 GB	约 55 分钟
0.1 MB	5	约 1.76 GB	约 9 小时

（模拟数据，计算方式：泄漏速率 = 单次泄漏量 × QPS × 3600；耗尽时间 = 显存容量 ÷ 泄漏速率。实际值受池化、碎片与引擎行为影响。）

这组数字的工程含义是：哪怕单次只漏 1 MB，在中等 QPS 下也会在分钟级耗尽显存。这解释了为什么很多团队觉得“这个 bug 很神秘”——它确实不会在功能测试中暴露，只在持续压测或长稳中显现。

8.2 判读指标清单

建议在监控中固化以下指标，形成“泄漏可被看见”的能力：

• RSS 与堆使用量的差值：差值持续扩大是堆外泄漏的强信号。
• 显存占用 / 显存容量：配合请求量归一化，观察“单位请求的显存成本”是否上升。
• 代理对象数量：通过定期堆直方图统计 NDArray / OrtValue 实例数。
• CUDA OOM 错误计数：作为结果指标，用于验证前三个指标的预警有效性。

本文评述：指标的价值在于归一化。绝对值的上升可能只是流量增长，只有“单位请求资源成本”这类比值指标才能区分“业务增长”与“资源泄漏”。这一点在容量规划与故障归因中同样重要。

SECTION 09对比与局限：两种防线各自的失效边界

9.1 设计防线（try-with-resources）的局限

它假设开发者能正确识别资源边界，且所有资源都能被纳入作用域。失效场景包括：第三方库内部创建的临时资源、跨线程传递、以及需要跨请求复用的资源（如会话）。对于会话这类长生命周期对象，作用域模式不适用，需要改用“单例 + 健康检查 + 定期重建”的策略。

9.2 观测防线（Arthas / JFR / NMT）的局限

它假设问题已经发生且可被观测。失效场景包括：低频泄漏（观测窗口内不显著）、观测工具本身的开销导致无法在生产常开、以及 native 库不在任何观测工具的覆盖范围内。此外，观测只能定位不能修复，若团队没有相应的修复流程，观测数据会沦为“知道有问题但解决不了”。

9.3 一个综合判断

笔者认为，标题中的设问本身隐含了一个错误的二分法。“用 NDManager 兜底”与“上 Arthas 抓 Direct Memory”不是同一层面的选择：前者是预防性设计，后者是诊断性手段。正确的工程答案是“两者都要，但优先级与投入不同”——设计防线应覆盖 90% 以上的场景，观测防线用于兜住剩余的长尾并验证设计是否真的生效。把资源全部押在任一方向，都会在另一方向付出代价。

SECTION 10工程落地：一套可执行的治理清单与操作步骤

10.1 编码阶段

1. 所有 native 资源在请求边界内创建与释放，禁止作为字段或返回值。
2. 缓存只存纯 Java 数据（字节数组、基本类型数组），不存张量句柄。
3. 异步任务提交前完成数据拷贝，任务内不持有 native 引用。
4. 在 CI 中加入静态规则，拦截未使用 try-with-resources 的可关闭对象。

10.2 运行阶段

1. 容器内存限制 = 堆上限 + 堆外预留 + 安全余量，三者分别配置并留出观测空间。
2. 开启 NMT summary 与 JFR 低开销采样，指标接入监控。
3. 固化“单位请求资源成本”指标，设置趋势告警而非阈值告警。
4. 在预发环境定期做长稳压测，主动暴露低频泄漏。

10.3 事故阶段

1. 先定性：区分池化与泄漏，避免误处置。
2. 再分层：NMT 判断是否在 JVM 内，RSS 差值判断是否在第三方库。
3. 后定位：Arthas 堆直方图 + 调用栈采样，锁定未关闭路径。
4. 终验证：修复后观察至少一个完整发布周期的曲线形态。

10.4 拓展资源

以下链接供进一步查阅（均为官方文档或公开教程，访问时请以最新版本为准）：

• DJL 官方文档中关于 NDManager 与内存管理的章节：docs.djl.ai
• ONNX Runtime Java API 文档与示例：onnxruntime.ai/docs/get-started/with-java.html
• Arthas 官方用户文档（含 heapdump、trace、stack 等命令）：arthas.aliyun.com/doc
• JDK Flight Recorder 与 NMT 的官方说明：docs.oracle.com/en/java/javase
• NVIDIA 关于 CUDA 内存管理与显存诊断的开发者博客：developer.nvidia.com/blog

SECTION 11前沿预判：Project Panama、FFM API 与资源确定性的未来

11.1 FFM API 带来的结构性变化

JDK 的 Foreign Function & Memory API（Project Panama 的产物）正在改变 JVM 与 native 代码交互的方式。它引入 Arena 作为内存分配的作用域，配合 MemorySegment 表达内存段，把“分配—释放”的配对关系提升到语言与类型层面。

其关键改进在于：Arena 关闭后，其分配的所有内存段立即失效，访问会抛出异常而非静默读写野指针。这把“释放后使用”从不可预测的崩溃转变为可捕获的错误，是资源安全性的实质提升。本文评述：这一设计思路与 DJL 的 NDManager 高度同构，说明“作用域化资源管理”是跨语言交互的通用解法，而非某个框架的独创。

11.2 对推理框架的潜在影响

若推理框架逐步迁移到 FFM API，native handle 的泄漏问题有望从“运行时事故”降级为“编译期或测试期问题”。但迁移不会一蹴而就：现有框架大量依赖 JNI，重写成本高，且 FFM API 在旧版本 JDK 上不可用。因此可以预期，未来数年内两种模式会并存，工程团队仍需掌握本文所述的治理方法。

另一个值得关注的方向是引擎侧的资源核算接口。若推理引擎能通过标准接口暴露“当前活跃句柄数”“池内空闲量”“设备侧占用”，观测防线就能从“间接推断”升级为“直接读取”。这需要框架与引擎的协同，目前尚无统一标准，属于开放问题。

SECTION 12结论与展望

回到最初的问题：到底该用 NDManager 的 try-with-resources 兜底，还是必须上 Arthas 抓 Direct Memory？本文的结论是，这个问法把预防与诊断混为一谈。正确的工程姿态是：

第一，以作用域化资源管理为默认范式，把 native 资源的生命周期绑定到请求边界，让“数据出、句柄留”成为团队约定，并用静态检查固化。

第二，以分层观测为验证手段，用 NMT 区分 JVM 内外，用 RSS 差值定位第三方库，用 Arthas 锁定调用现场，用归一化指标实现趋势预警。

第三，承认两者的边界，不指望任何单一手段解决全部问题，也不把诊断工具当作治理方案常驻生产。

从更长的视角看，native handle 泄漏是 JVM 生态在拥抱 AI 过程中必然经历的阵痛。它暴露的不是某个框架的缺陷，而是跨语言资源所有权缺乏语言级约束这一结构性问题。FFM API 的出现说明社区已经意识到这一点并在改进，但在迁移完成之前，工程团队仍需用设计纪律与观测能力来弥补语言的不足。这既是当下的务实选择，也是理解未来演进的基础。

主要参考文献