Java Foreign Function Memory API 管理本地内存生命周期

Java 的 Foreign Function and Memory API（FFM API）在 JDK 22 定稿后，本地内存管理不再只是“分配一块堆外空间”这么简单。真正决定代码是否可靠的是：谁拥有这块内存、哪些线程可以访问、什么时候失效。FFM API 把这三个问题集中到 Arena，由它控制一组 MemorySegment 的共同生命周期。

官方 API：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/foreign/Arena.html

把 Arena 看成一组本地资源的所有者

每个由 Arena 分配的 MemorySegment 都关联到该 Arena 的 scope。scope 决定时间边界：只要 scope 存活，segment 才允许访问；Arena 成功关闭后，scope 失效，相关 segment 不能继续读写，背后的本地内存也会被释放。

这是一种典型的“区域所有权”模式。它不要求给每一小块内存单独写释放逻辑，而是把同一业务操作里的参数缓冲区、返回值缓冲区和临时结构放进一个 Arena。业务作用域结束时关闭 Arena，整组资源一起退出。

单线程调用用 confined Arena 划清边界

假设一个请求要构造 1024 个整数的本地缓冲区，交给本地函数处理后立即丢弃。最自然的边界是一个 try-with-resources 块：进入时创建 Arena，退出时自动关闭。

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

static long sumNativeInput(int count) {
    // confined Arena 只允许创建它的线程访问，并在块末确定性释放。
    try (Arena arena = Arena.ofConfined()) {
        long bytes = Math.multiplyExact(
                ValueLayout.JAVA_INT.byteSize(), count);
        MemorySegment values = arena.allocate(
                bytes, ValueLayout.JAVA_INT.byteAlignment());

        // 按 int 元素写入，FFM 会检查索引边界和 segment 有效期。
        for (int i = 0; i 

Arena.ofConfined() 有明确所有者线程。分配、访问和关闭都应发生在该线程；其他线程访问它分配的 segment，或尝试替它关闭 Arena，会触发线程边界异常。这个限制看起来严格，却能直接阻止“请求已经结束，后台线程仍握着本地指针”的模糊所有权。

跨线程时不要把 confined segment 直接扔进线程池

常见问题是主线程创建 confined Arena 后，把 MemorySegment 放进异步任务。即使 Arena 仍然存活，工作线程也不是所有者线程，访问会失败；如果主线程先退出 try 块，segment 还会同时失效。

当多线程确实需要同时访问同一段本地内存，可以使用 Arena.ofShared()。它没有单一所有者线程，任何线程都可以访问或关闭，但“谁负责最终关闭”仍要由应用明确约定。通常让上层组件持有 Arena，并在所有任务完成后统一关闭。

import java.lang.foreign.Arena;
import java.lang.foreign.MemorySegment;
import java.lang.foreign.ValueLayout;
import java.util.concurrent.CompletableFuture;

static int readFromWorker() {
    // shared Arena 允许工作线程访问，但仍由当前业务作用域负责关闭。
    try (Arena arena = Arena.ofShared()) {
        MemorySegment value = arena.allocate(ValueLayout.JAVA_INT);
        value.set(ValueLayout.JAVA_INT, 0, 42);

        CompletableFuture task = CompletableFuture.supplyAsync(() -> {
            // 工作线程访问 shared segment，不越过 Arena 的有效期。
            return value.get(ValueLayout.JAVA_INT, 0);
        });

        // 必须在关闭 Arena 前等待任务完成，避免并发访问与释放冲突。
        return task.join();
    }
}

shared 不是“随便共享”。关闭动作是安全且原子的，但如果仍有 segment 正被并发访问，关闭可能失败。设计上应先收敛任务，再关闭 Arena，而不是把关闭当成打断工作线程的取消机制。

四类 Arena 的代价完全不同

ofAuto() 并不等于“更安全的 confined”。它允许多线程访问，但释放时机由 GC 决定；即使 Java 对象已经不再使用，堆外内存也未必立即归还。对峰值内存敏感、资源昂贵或本地库有严格释放要求的场景，仍应使用显式可关闭的 Arena。

global() 的 backing region 永不释放，且 close() 不受支持。它适合真正与进程同寿命的资源，不适合把生命周期设计问题隐藏起来。循环创建逻辑里使用 global Arena，只会把每轮分配都变成永久占用。

最危险的反例是把 segment 返回到 Arena 外

MemorySegment 对象可以被赋给外部变量，但这不代表背后的本地内存仍然有效。下面的写法在方法返回前关闭 Arena，调用方得到的是一个已经失效的 segment。

static MemorySegment brokenBuffer() {
    // 反例：方法结束前 Arena 会关闭，返回值随即失效。
    try (Arena arena = Arena.ofConfined()) {
        return arena.allocate(128);
    }
}

static byte readBroken() {
    MemorySegment segment = brokenBuffer();
    // 访问已关闭 scope 会抛出 IllegalStateException。
    return segment.get(ValueLayout.JAVA_BYTE, 0);
}

修复思路不是把 Arena 换成 global，而是把所有权一起交给调用方。可以返回一个实现 AutoCloseable 的资源对象，内部同时保存 Arena 和 segment，让调用方用 try-with-resources 管理完整生命周期。

final class NativeBuffer implements AutoCloseable {
    private final Arena arena = Arena.ofConfined();
    private final MemorySegment segment;

    NativeBuffer(long byteSize) {
        // segment 与资源对象里的 Arena 同寿命。
        this.segment = arena.allocate(byteSize);
    }

    MemorySegment segment() {
        // 只暴露视图，不转移 Arena 的关闭责任。
        return segment;
    }

    @Override
    public void close() {
        // Arena.close 不是幂等操作，资源对象也只应关闭一次。
        arena.close();
    }
}

如果资源对象可能被多个线程使用，就不能继续内部创建 confined Arena；要么把它限定在所有者线程，要么改用 shared Arena 并明确并发关闭协议。

关闭语义不是普通的幂等清理

Arena.close() 被设计为非幂等操作。重复关闭已经关闭的 Arena 会抛出异常，这能暴露应用中的重复释放或所有权混乱。对于 ofAuto() 和 global()，调用 close 则会抛出 UnsupportedOperationException。

这个选择的后果很明确：不要在多个组件里“保险起见各关一次”，也不要同时让框架和业务代码都认为自己拥有关闭权。把 Arena 放进一个最小、清晰的所有者对象中，并让 close 路径只出现一次，代码会更容易审查。

什么时候该用哪一种生命周期

• 先看释放时机：必须在请求、批次或任务结束时归还内存，就选显式可关闭 Arena。
• 再看线程边界：只在当前线程访问用 confined；确实跨线程共享才用 shared。
• 检查逃逸：segment、slice、downcall 返回值或 upcall stub 是否会活得比 Arena 更久。
• 检查关闭责任：是否只有一个组件拥有 close 权限，是否在所有并发任务结束后才关闭。
• 检查本地分配来源：若内存由 malloc 等外部函数返回，还要用正确的 cleanup 与 Arena 绑定，不能只管理 Java 侧视图。
• 限制 global：只有能证明资源应与进程同寿命时才使用。

FFM API 的关键价值不只是比 JNI 更易调用，而是把空间安全、时间安全和线程访问边界变成可表达的 Java 类型与运行时检查。把 Arena 当成区域所有者，MemorySegment 的生命周期就能跟业务作用域对齐；把它当成普通分配器，则很容易重新制造提前释放、永久占用和跨线程误用。

常见问题

Arena.ofAuto 会立刻释放本地内存吗？

不会。只有当 Arena 和相关 segment 不再可达后，背后的区域才会在未指定时间由 GC 管理释放。

MemorySegment 切片需要单独关闭吗？

通常不需要。切片与来源 segment 共享相关 scope，Arena 关闭后它们一起失效。

ofShared 可以在任何线程关闭吗？

可以由任意线程关闭，但应先保证没有并发访问仍在进行，否则关闭可能失败或暴露错误的并发协议。

为什么不用 global Arena 避免失效异常？

因为它会把本地内存变成进程级永久资源，只是掩盖所有权问题，并不能建立正确的释放边界。