JDK 22中如何手动释放MemorySegment？

问题背景 #

JDK 22 中创建原生MemorySegment必须通过Arena实现，不再支持 JDK 16/17 中直接调用MemorySegment.allocateNative(...)的方式。当前需求是通过 Graal Native Image 将 Jar 打包为共享库，暴露两个函数：

• 分配原生内存，返回内存地址及大小给调用方，且内存需持续存活至主动释放
• 通过传入的内存地址，调用专用函数释放对应内存

现有思路分析 #

使用全局Arena分配的内存无法被主动释放；使用共享Arena需维持其生命周期跨函数调用，当前可行方案是将Arena存入静态HashTable（以随机整数为键），释放时通过键关闭对应Arena。

其他可选方案 #

• 单 Segment 对应独立 Arena
  为每次内存分配请求创建独立的Arena.ofConfined()，将内存地址（segment.address()）与对应Arena存入静态Map<Long, Arena>。释放时通过传入的地址从映射中取出Arena并调用close()，即可释放该地址对应的内存。此方式能实现单内存块的精准释放，仅存在少量 Arena 创建开销，适合共享库场景。

• 通过地址重建 Segment 获取所属 Arena
  释放时可通过MemorySegment.ofAddress(address, size)重建内存段，再调用segment.scope()获取其所属Arena，随后关闭Arena释放内存。注意：该方式会释放此Arena下所有分配的内存，若需单块释放，仍需为每个 Segment 分配独立 Arena。

• 直接使用 Unsafe API（不推荐）
  若兼容风险可接受，可直接通过Unsafe的allocateMemory()和freeMemory()手动管理内存，还原 JDK 16/17 的使用方式。但Unsafe为内部 API，Graal Native Image 需额外配置，且存在未来版本被移除的风险。

总结 #

你提出的静态 HashTable 存储 Arena 的思路完全可行，上述方案均为该思路的变种优化。若需单内存块精准释放，为每个分配请求创建独立 Confined Arena 并维护地址与 Arena 的映射，是更直接且易维护的实现方式。

内容的提问来源于stack exchange，提问作者GrumpyRodriguez