JDK 26 外部函数与内存 API 怎样管理 Arena

使用 JDK 26 的 Foreign Function & Memory API 时，Arena 不只是一个分配器，它还是 native memory 的生命周期边界。最稳妥的做法是：短期调用用 Arena.ofConfined() 配合 try-with-resources，跨线程共享才换成 Arena.ofShared()；不要把 global() 当成普通缓存，也不要把 ofAuto() 当成确定的释放点。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/lang/foreign/Arena.html

先把 Arena 看成一条资源边界

MemorySegment 记录的是一段可访问的内存视图，真正决定它还能不能用的是所属 Arena 的 scope。Arena 正常关闭后，segment 仍可能保留在 Java 变量里，但再次读写会失败；这正是 FFM API 用来阻止 use-after-free 的时间安全边界。

import java.lang.foreign.Arena;
import java.lang.foreign.MemorySegment;
import java.lang.foreign.ValueLayout;

static void readNativeValue() {
    // 让 arena、segment 和一次 native 操作拥有同一个短生命周期
    try (Arena arena = Arena.ofConfined()) {
        MemorySegment value = arena.allocate(ValueLayout.JAVA_INT);
        value.set(ValueLayout.JAVA_INT, 0, 42);
        int result = value.get(ValueLayout.JAVA_INT, 0);
        System.out.println(result);
    } // 退出作用域后释放区域，value 不能再被访问
}

这里的关键不是“手动记得调用 close”，而是让所有只在本次调用中使用的数据都被同一个 try 块包住。这样异常、提前 return 和正常结束都会走同一条释放路径。

按线程模型选择 Arena 类型

选择依据只有两个：谁能访问 segment，以及谁负责结束生命周期。ofConfined() 把访问和关闭都限制在创建线程，开销与边界都更容易理解；ofShared() 去掉了线程所有者限制，但关闭时必须确认没有并发访问。

尤其要注意：ofAuto() 和 global() 不支持普通的显式关闭。它们解决的是生命周期策略问题，不是“忘记 close 也没关系”的通用兜底。

跨线程调用时，把关闭动作放到 join 之后

如果 segment 会交给线程池或外部函数回调，shared arena 只能解决“谁可以访问”，不能自动解决“什么时候可以关闭”。创建任务、等待任务完成、最后关闭 Arena，顺序必须明确。

try (Arena arena = Arena.ofShared()) {
    MemorySegment buffer = arena.allocate(1024);
    // 任务只持有当前作用域里的 segment，不把它泄漏到更长生命周期
    Future> task = executor.submit(() -> {
        // 真实项目中先完成边界检查，再读写 buffer
        buffer.set(ValueLayout.JAVA_BYTE, 0, (byte) 1);
    });
    task.get(); // 先等待访问结束，再让 try 自动关闭 arena
} catch (InterruptedException e) {
    // 恢复中断标记，让上层决定是否取消整个操作
    Thread.currentThread().interrupt();
} catch (ExecutionException e) {
    // 保留异步任务的根因，避免把资源错误伪装成成功
    throw new RuntimeException("native task failed", e.getCause());
}

生产代码还要处理取消、超时和回调注册：只要仍有代码可能访问 segment，就不能先关闭它。若关闭与 downcall 同时发生，API 可能抛出异常；这比静默读到已经释放的地址更容易定位。

资源释放前的工程检查

• 返回值是否仍引用 Arena 里的 segment？如果是，返回前应复制到 Java 堆或延长同一 Arena 的所有权。
• 外部函数是否保存了指针、回调或字符串地址？这些对象必须在外部代码不再使用后才能释放。
• 关闭是否只发生一次？close() 不是幂等操作，重复关闭通常意味着所有权设计有问题。
• 共享任务是否已经完成？不要以“任务已提交”代替“任务已停止访问”。

经验上，先从 confined 开始，只有明确的跨线程需求才升级到 shared；把 Arena 创建位置、关闭位置和 segment 传递路径写在同一个方法或明确的资源对象里，排查 native memory 占用时会轻松很多。

常见问题

关闭 Arena 后还能继续读取 MemorySegment 吗？

不能。关闭成功后 scope 不再存活，关联 segment 的访问会失败；需要长期使用时，应在关闭前复制数据或重新设计所有权。

为什么不统一使用 Arena.ofAuto？

因为它的回收时机由 GC 管理，不能表达请求结束、批处理结束或 native 调用结束这类确定事件。需要及时释放时优先使用可显式关闭的类型。

什么时候才值得使用 Arena.ofShared？

只有当同一段 segment 确实需要被多个线程访问或关闭时。若工作可以收敛到一个线程，confined 的边界更简单。