Java Foreign Function 怎样管理 MemorySegment 生命周期

管理 FFM API 中的 MemorySegment，关键不是保留一个 Java 引用，而是让它关联的 Arena 作用域在整个使用期间有效。单线程临时内存通常选择 Arena.ofConfined 配合 try-with-resources；跨线程访问考虑 ofShared，并另行协调任务结束与关闭。切片仍借用原作用域，不能靠 asSlice 延长内存寿命。

本文以 JDK 25 文档为准，只讨论 Arena 与其分配的 segment，不涉及原生函数调用或外部指针所有权。官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/foreign/Arena.html。MemorySegment 文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/foreign/MemorySegment.html。

先确认这块内存需要活到什么时候

假设一次计算需要两项整数的堆外暂存区，计算结束后只返回一个普通 Java 整数。内存完全在同一线程使用，释放点清晰，这时没有必要选生命周期无限的 global arena。若把 segment 返回给异步任务，原方法的结束就不再是安全释放点，需要重新定义所有者与借用期限。

Arena 管理它分配的原生内存，MemorySegment 描述可访问区域，Scope 表达有效期，创建线程则决定 confined 模式的线程限制。判断时同时问两个问题：谁会访问，谁负责结束生命周期。不要把“对象还没被垃圾回收”当成“堆外区域还有效”。

四种 Arena 不能只看是否方便关闭

ofAuto 和 global 不支持手动 close，调用会抛 UnsupportedOperationException。不要因为 Arena 实现 AutoCloseable 就把所有类型都放进 try-with-resources。confined 的关闭也只能由创建线程完成；shared 允许其他线程关闭，但这不意味着所有业务数据读写自动线程安全。

成功关闭显式管理的 arena，会让其作用域失效并释放对应堆外区域。重复 close 不是幂等清理，会抛异常，因此应指定一个明确关闭责任方。其他代码只借用 segment，不应各自争抢释放权。

最小示例：切片也受原 Arena 控制

以下代码可保存为 SegmentLifetimeDemo.java，在 JDK 25 下使用。它分配八字节并按四字节对齐，两个 JAVA_INT 的偏移分别为零与四。retained 只用于展示关闭后的错误边界；实际业务应在作用域内读出普通值再返回，而不是带出失效视图。

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

public class SegmentLifetimeDemo {
    public static void main(String[] args) {
        MemorySegment retained;
        // 单线程临时内存由当前作用域统一关闭。
        try (Arena arena = Arena.ofConfined()) {
            MemorySegment segment = arena.allocate(8, 4);
            segment.set(ValueLayout.JAVA_INT, 0, 23);
            segment.set(ValueLayout.JAVA_INT, 4, 41);
            // slice 是原内存视图，不是独立分配，也不延长作用域。
            retained = segment.asSlice(4, 4);
            System.out.println(retained.get(ValueLayout.JAVA_INT, 0));
        }
        // 保留 Java 引用仅用于展示失败边界，不是推荐的返回方式。
        System.out.println(retained.scope().isAlive());
        try {
            retained.get(ValueLayout.JAVA_INT, 0);
            throw new AssertionError("已关闭作用域不应允许读取");
        } catch (IllegalStateException expected) {
            System.out.println("关闭后读取已拒绝");
        }
    }
}

按 API 契约，作用域内第一次读取应得到 41；退出 try 块后 isAlive 应为 false，随后 get 应抛 IllegalStateException。这些是预期行为，不是本文执行得到的日志。本例没有调用原生库，也不能作为原生函数保留指针的生命周期示范。

asSlice 不复制数据、不是独立分配，它与原 segment 使用同一作用域。父段、切片都引用同一片内存；Java 对象可以继续存在，读取能力却已结束。因此把切片放进集合、缓存或字段并不能挽救它。

跨线程需要 Shared，还需要结束协议

如果一个工作线程要读取当前线程分配的 segment，confined 不适合这个访问模型。改为 shared 只解决访问线程限制，不解决数据竞争，也不保证异步任务先于 close 结束。应让所有使用者完成并停止借用后，由约定的责任方关闭；取消请求本身也不等于任务已经停止访问。

同样不能先检查 scope().isAlive，再把检查结果当作后续访问的锁。并发关闭可能发生在检查之后。isAlive 适合描述作用域状态，不替代应用的任务协调。原生调用或外部代码还可能有不同的使用期限，本例没有覆盖这些协议。

不适用情况与选择速查

为避免关早而一律用 global，会把释放问题变成无限生命周期的资源积累；为避免线程限制而一律用 shared，会增加跨线程生命周期协调责任；为省 close 而用 auto，则必须接受释放时机不确定。三者都不是 confined 的无代价升级。

• 同线程、临时使用：优先考虑 confined，把所有读取放在明确作用域内。
• 必须跨线程：使用 shared 并定义最后使用者与关闭责任。
• 允许垃圾回收决定释放时机：考虑 auto，别手动 close。
• 资源确实需要无限有效期：才考虑 global，不用于逃避正常清理。

返回 MemorySegment 时应该让谁创建 Arena？

可以由调用方提供生命周期覆盖使用期的 Arena，并明确调用方负责关闭；不要在返回前关闭内部临时 Arena。这里说的是所有权设计，不是自动延长寿命。

关闭父段的 Arena，切片还能用吗？

不能。切片没有独立生命周期，仍受同一 Scope 控制。

Shared 是否让普通 get/set 自动变成线程安全操作？

不是。可跨线程访问与业务并发正确性不同；同步和数据一致性仍需单独设计。

选择 Arena 时，把生命周期和线程范围同时纳入决策。只有两者都覆盖实际使用期，segment 才是有明确借用边界的资源，而不是一个看起来还存在的 Java 引用。