Linker 是 Java 22+ 中 java.lang.foreign 包的运行时链接协调器，必须通过 Linker.nativeLinker() 获取平台适配的单例实例；调用 C 函数前须严格校验 FunctionDescriptor 类型对齐、符号名导出状态及调用约定匹配，并采用 Arena 分配堆外 MemorySegment 实现零拷贝与 GC 安全。
Linker 是 Java 22+ 中 java.lang.foreign 包的核心入口，它不是“封装好的工具”，而是一个**运行时链接协调器**——真正决定调用是否高效、是否安全的，是它如何配合 Arena、MemorySegment 和 FunctionDescriptor 使用。
为什么直接 new Linker() 不行
Linker 没有 public 构造函数，必须通过 Linker.nativeLinker() 获取单例实例。这不是设计偷懒，而是因为 JVM 需要为不同平台（Linux 的 libdl、Windows 的 LoadLibrary、macOS 的 dlopen）注入原生链接逻辑。硬编码构造会绕过平台适配，导致 UnsatisfiedLinkError 或 SIGSEGV。
调用 C 函数前必须确认三件事
漏掉任意一项，invokeExact() 就会抛 WrongMethodTypeException 或静默传错地址：
-
FunctionDescriptor的参数/返回类型必须与 C ABI 严格对齐：比如 C 的size_t在 Linux x86_64 是ValueLayout.JAVA_LONG，但在 Windows x64 是ValueLayout.JAVA_INT；别想当然用int - C 函数符号名可能被编译器修饰：GCC 默认不修饰，但
static函数或启用-fvisibility=hidden后，find("my_func")会返回Optional.empty()；用nm -D libalgo.so确认导出符号 - 调用约定（calling convention）必须匹配：
Linker当前只支持StdCall（Windows）和SystemV（Linux/macOS），若 C 库用了__attribute__((regcall))等自定义调用约定，JVM 无法处理
避免内存拷贝的关键在 MemorySegment 分配方式
多数人卡在“明明传了地址，C 函数却读到乱码”，问题往往出在 MemorySegment 的创建方式：
- 用
arena.allocateFrom("data")→ 写入 UTF-8 字节，适合字符串，但对二进制算法输入（如 float 数组）会编码失真 - 用
MemorySegment.ofArray(floatArray)→ 数据仍在 Java 堆内，C 函数能读，但 GC 可能在任意时刻移动对象，导致悬垂指针；必须配合ResourceScope+MemorySegment.copyTo()显式拷贝到原生内存 - 真正零拷贝的做法：用
arena.allocate(ValueLayout.JAVA_FLOAT, length)分配堆外内存，再用VarHandle逐个写入 —— 这样地址稳定、无 GC 干扰、C 函数直读
动态库路径和符号解析失败的排查顺序
当 LibraryLookup.ofPath("/path/to/libalgo.so").find("fast_sort") 返回空时，不要急着改代码，按这个顺序查：
- 确认
LD_LIBRARY_PATH（Linux）或DYLD_LIBRARY_PATH（macOS）是否包含该路径；JVM 不读取系统ldconfig缓存 - 检查库是否依赖其他 .so：
ldd libalgo.so，缺失的依赖会导致LibraryLookup.ofPath()静默失败 - Java 层用
System.getProperty("os.arch")核对架构：x86_64 库不能在 aarch64 JVM 上加载，反之亦然 - 如果库是 Rust 编译的，确保导出了 C ABI：
#[no_mangle] pub extern "C" fn fast_sort(...)，否则符号名会被 Rust mangling
Linker 本身不慢，慢的是错误的内存生命周期管理或类型描述偏差。最常被忽略的是：C 函数若修改传入的 MemorySegment 内容，Java 层必须用 VarHandle 而非 getUtf8String() 读取结果——后者会重新编码，破坏原始二进制布局。 
