外部函数与内存 (FFM) API 引入了 MemorySegment，以安全访问堆外内存。每个段都与 MemorySession （在较新版本中称为 Arena）相关联，该会话定义了其生命周期。当一个 arena 被关闭时，ScopedMemoryAccess 层将所有相关的段标记为 "不再有效"。
任何后续的访问尝试都会触发 ScopedMemoryAccess.Scope 检查，立即抛出 IllegalStateException。为了防止垃圾收集器在本地操作进行时回收某个段，JVM 在隐式地使用 reachabilityFence 语义。编译器在关键边界插入保持活动屏障，确保段对象在本地调用完成之前保持强可达。
这种协调允许通过 close() 进行显式确定性清理，同时防止在 GC 提前终止段时发生使用后释放错误。这种设计确保了在不需要手动同步每次访问的情况下保持内存安全。这一架构选择弥合了手动内存管理和 Java 自动垃圾收集范式之间的差距。
考虑一个高频交易应用程序，通过 MemorySegment 处理市场数据，该段映射到与 C++ 交易所网关共享的堆外缓冲区。当多个线程尝试读取定价更新时，问题出现了，背景维护线程定期通过关闭旧的 Arena 并分配一个新的来刷新缓冲区。如果没有适当的时间安全性，读取线程可能会尝试访问一个其基础内存已经返回给操作系统的段，造成 JVM 崩溃或无声数据损坏。
考虑的一个解决方法是使用 AtomicInteger 进行显式引用计数。每次读取操作都会递增计数器，并在完成后递减。优点包括逻辑简单和泄漏的即时检测。然而，缺点是在高负载下对原子变量的竞争显著，而且它未能与垃圾收集器集成；一个被遗忘的递减仍然会导致内存泄漏，并且在本地代码持有原始指针时不会阻止 arena 关闭。
另一种方法是使用 try-with-resources 块包装每个访问，确保在操作期间 arena 保持打开。优点是确定性范围和简洁的语法。缺点包括为短期操作过度关闭和重新打开 arena，当每秒分配数千个段时，代价高昂。此外，这种模式无法防范可能超出 Java 范围的本地代码的异步回调。
选择的解决方案利用 Arena.ofShared() 以及适当的 reachabilityFence 放置和范围访问检查。通过将 arena 关闭限制为专用维护线程，并确保所有读取操作在取消引用之前验证段的有效性，系统消除了竞争条件。ScopedMemoryAccess 机制在快速路径上提供了零成本检查，而 JVM 的可达性保证防止了 GC 介入。结果是一个稳定的系统，每秒处理数百万条消息，而没有本地崩溃或内存泄漏。
为什么 MemorySegment 即使在段没有被明确限制的情况下也会抛出 WrongThreadException，而 Arena 类型又是如何决定线程限制语义的？
许多候选人假设所有的段默认都是线程安全的。实际上，Arena.ofConfined() 创建的段仅能由发起线程访问，这是通过 ScopedMemoryAccess 中的线程 ID 检查来强制执行的。Arena.ofShared() 允许跨线程访问，但要求外部同步。当通过 lambda 或回调将一个受限段的地址传递给另一个线程时，就会发生该异常。
在确保堆外资源在本地调用期间保持有效方面，reachabilityFence 机制与 PhantomReference 有何不同？
候选人常常混淆这两种机制。PhantomReference 允许在对象变得不可达后进行事后清理，这对于防止在活跃操作期间发生使用后的释放而言太晚。reachabilityFence 作为编译器插入的屏障，确保该对象在屏障执行之前保持强可达。在 FFM 中，JVM 会自动在 MemorySegment 访问操作周围插入这些屏障，确保该段在本地内存访问期间保持有效，而无需在用户代码中手动放置。
直接关闭 MemorySegment 与关闭其父级 Arena 之间的区别是什么，为什么关闭一个 arena 会同时使所有派生段无效？
一个常见的误解是段是独立的资源。实际上，通过 slice() 或 reinterpret() 派生的段与其父 arena 共享相同的 ScopedMemoryAccess.Scope。当调用 Arena.close() 时，它会使整个范围无效，波及到所有派生段。关闭单个段仅将特定视图标记为无效，但基础内存在 arena 关闭之前保持分配状态。