JNA比JNI更适合纯Java项目调用本地库，因其无需编写C头文件、编译或打包.so/.dll，仅需Java接口+注解即可运行时自动解析符号；但要求函数签名严格匹配，存在性能开销与内存控制限制。
为什么JNA比JNI更适合纯Java项目调用本地库
因为JNA绕过了JNI繁琐的C头文件编写、编译和.so/.dll打包流程，它在运行时自动解析动态库符号，Java端只需定义接口+注解。你不需要写一行C代码，也不用配javah或gcc——只要目标机器上有对应架构的.so或.dll，JNA就能加载。
但这也带来隐性约束：函数签名必须严格匹配，参数传递方式（如指针/值/结构体）容易出错；且JNA默认不校验函数是否存在，调用时才抛UnsatisfiedLinkError。
- 适用于调用系统API（如Windows
kernel32.dll、Linuxlibc.so.6）或已有成熟C库（如libusb-1.0.so） - 不适合高频调用（相比JNI有约2–5倍性能开销），也不适合需要深度控制内存生命周期的场景
- JNA 5.x 要求 Java 8+，6.x 开始要求 Java 11+；若用 Maven，注意排除旧版
jna-platform冲突
如何用Maven引入JNA并避免常见依赖冲突
直接加jna核心包即可，jna-platform只在需要跨平台封装（如WinDef、Posix等预定义接口）时才引入。很多人误以为必须一起引，结果导致类重复、版本打架。
典型错误是同时声明了jna 5.13.0 和 jna-platform 5.9.0 ——它们必须版本号完全一致，否则Structure序列化会失败，报java.lang.NoSuchFieldError: fieldOrder。
立即学习“Java免费学习笔记（深入）”；
- 最小必要依赖（Maven）：
<dependency> <groupId>net.java.dev.jna</groupId> <artifactId>jna</artifactId> <version>5.13.0</version> </dependency>
- 如果用了
jna-platform，确保<version></version>与jna完全相同 - Spring Boot 3.x 用户注意：Boot 自带的
spring-boot-starter-jdbc等可能间接拉入旧版JNA，需用<exclusions></exclusions>显式排除
怎么写一个安全的Library接口映射（含常见崩溃点）
JNA通过Java接口+extends Library约定来绑定本地函数，但接口定义稍有偏差就会在运行时报错，比如LastErrorException、Invalid memory access，甚至JVM直接崩溃（SIGSEGV）。根本原因是类型映射没对齐C ABI。
关键不是“能不能调通”，而是“调通后行为是否稳定”。例如把C的int*写成IntByReference是对的，但写成Integer或int[]就可能读越界。
- 字符串传参统一用
String（JNA自动转UTF-8），返回C字符串用String接收，但需确认C端内存由谁释放（JNA默认拷贝，安全） - 结构体必须继承
Structure，且显式设置public List<string> getFieldOrder()</string>；漏掉getFieldOrder会导致字段偏移错乱 - 回调函数（callback）要用
StdCallLibrary或Closure（JNA 6+），不能直接用Lambda——否则GC可能提前回收，引发段错误 - 示例：正确映射
libc的getpidinterface CLibrary extends Library { CLibrary INSTANCE = Native.load("c", CLibrary.class); int getpid(); }
如何让JNA自动找库、跨平台适配路径与调试加载失败
JNA默认按固定顺序搜索库：先看jna.library.path系统属性，再查java.library.path，最后尝试从classpath根目录找同名文件。很多人卡在“找不到库”，其实是路径没对上，或者没设jna.platform.library.path指定平台子目录。
更隐蔽的问题是：Linux下libfoo.so能加载，但libfoo.so.1不行——JNA不支持soname自动解析，必须写全名或用NativeLibrary.getInstance("foo")手动加载。
- 推荐做法：把
.so/.dll放在src/main/resources/lib/<os-name>/<arch>/</arch></os-name>下，启动时加JVM参数：-Djna.platform.library.path=lib/${os.name}/${os.arch} - 调试加载问题，加
-Djna.debug_load=true -Djna.debug_load_verbose=true，会打印每一步尝试的绝对路径 - Windows下注意DLL依赖链：用
Dependencies.exe查缺失的VCRT或msvcp140.dll，JNA本身不解决这些依赖 - 容器环境（如Alpine）要确认glibc兼容性，musl libc下多数glibc编译的
.so无法加载
最常被忽略的是结构体内存对齐和字节序——尤其当C结构体含#pragma pack(1)或大小端混合字段时，Java端Structure必须显式用setAlignType(ALIGN_NONE)或ALIGN_PACKED，否则字段错位，数据全乱。
