Java Arena.ofConfined 与 ofShared 如何选择

Java FFM API 中，Arena 同时决定原生内存的生命周期和访问线程范围。实际选择可以先记住一句话：MemorySegment 只在创建线程使用，就优先用 Arena.ofConfined()；同一段内存需要被多个线程访问，才考虑 Arena.ofShared()。两者都需要显式关闭，关闭后关联的 MemorySegment 不能再访问。

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

下面不把两种 Arena 当成“快慢开关”，而是从线程约束、关闭责任和作用域边界判断它们适合的代码结构。

一、先把 Arena 的选择问题拆成三个维度

选择前先回答三个问题：MemorySegment 会不会跨线程？谁能负责关闭 Arena？调用结束后，段是否还需要继续存活？这三个答案比“项目是否用了并发”更重要。

因此，ofShared() 不是并发代码的默认选项。只要所有访问都可以留在同一个线程，confined 约束就更清晰，关闭责任也更容易跟随局部代码阅读。

二、单线程任务使用 Arena.ofConfined

confined Arena 创建时绑定一个 owner thread。它分配的 MemorySegment 只能由这个线程访问和关闭，适合把原生内存封装在一个同步调用或一个资源块内。

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

static long readNativeValue() {
    // try-with-resources 让本地内存的释放边界和方法调用边界一致。
    try (Arena arena = Arena.ofConfined()) {
        // 这段 MemorySegment 只在当前 owner thread 内读写。
        MemorySegment segment = arena.allocate(ValueLayout.JAVA_LONG);
        segment.set(ValueLayout.JAVA_LONG, 0, 42L);
        return segment.get(ValueLayout.JAVA_LONG, 0);
    } // 离开代码块时关闭 Arena，segment 随作用域失效
}

这里的重点不是分配一个数字，而是让“创建、访问、关闭”保持在同一个线程和同一个代码块中。调用者拿到的是普通数值，不会把受 Arena 约束的 MemorySegment 继续暴露给别的线程。

如果把 segment 放进共享集合、交给线程池，或让另一个线程负责关闭，就已经违背了 confined 的使用边界。此时不要只加同步锁，应该重新判断资源是否确实需要跨线程。

三、多线程任务使用 Arena.ofShared

当多个线程确实需要访问同一个 MemorySegment 时，shared Arena 才有意义。它没有 owner thread，分配出的段可以由多个线程访问，关闭动作也可以由任意线程发起；但这不等于可以随时关闭。

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

static void useSharedSegment(MemorySegment segment, int index, int value) {
    // 调用方必须保证 index 对应的区域不会和其他任务发生未协调的写冲突。
    segment.setAtIndex(ValueLayout.JAVA_INT, index, value);
}

static void parallelWork() throws Exception {
    try (Arena arena = Arena.ofShared()) {
        // shared 只解决跨线程访问资格，不替你解决数据竞争。
        MemorySegment segment = arena.allocate(ValueLayout.JAVA_INT, 4);
        var first = Thread.ofVirtual().start(() -> useSharedSegment(segment, 0, 10));
        var second = Thread.ofVirtual().start(() -> useSharedSegment(segment, 1, 20));

        // 先等待所有访问者结束，再让 try-with-resources 关闭 Arena。
        first.join();
        second.join();
    } // 关闭后 segment 失效，不能再交给新的线程使用
}

示例把两个线程写入不同索引，只说明访问范围，不代表所有共享写入都天然安全。多个线程写同一位置时仍要设计同步、分区或其他并发协议；Arena 只负责生命周期和线程可访问性。

四、用关闭边界检查代码结构

两种 Arena 都是手动管理生命周期。Arena 关闭后，关联的 MemorySegment 不能再访问；所以代码审查时要重点看“段是否逃逸”和“关闭是否早于最后一次访问”。

1. confined 的检查清单

• 创建 Arena、访问段和关闭 Arena 是否在同一个 owner thread？
• 方法返回值是否已经转换成 Java 堆上的数据，而不是返回受限的 MemorySegment？
• 是否使用 try-with-resources 把关闭动作固定在局部作用域？

2. shared 的检查清单

• 所有 worker 是否都在 Arena 关闭前结束访问？
• 关闭责任是否明确，避免一个线程还在读写时另一个线程提前 close？
• 共享数据是否有独立的并发协议，避免把“可访问”误解成“无数据竞争”？

如果 MemorySegment 需要长期存活，但没有清晰的关闭拥有者，可以重新评估 Arena.ofAuto() 或更高层的资源封装。不过本文的选择范围只聚焦于显式关闭的 confined 与 shared，不应把自动回收当成两者的替代结论。

五、按场景做最终选择

可以用下面的决策表收尾：

最实用的默认顺序是：先尝试 confined；只有跨线程访问 MemorySegment 是真实需求时再改用 shared；最后把所有访问者的结束点放在显式关闭之前。

相关问题

Arena.ofShared 会自动解决并发写冲突吗？

不会。它解决的是多个线程能否访问同一作用域，数据读写冲突仍需要锁、分区、原子操作或其他明确协议。

confined Arena 可以由其他线程关闭吗？

不应这样设计。confined Arena 绑定创建线程，访问和关闭都应由 owner thread 完成；需要跨线程关闭时，应重新评估是否应使用 shared。

关闭 Arena 后还能访问 MemorySegment 吗？

不能。关闭会使关联作用域失效，后续访问应视为生命周期错误；需要保留的数据应在关闭前复制为 Java 堆对象。