native方法是Java调用C/C++函数的桥梁，需声明、生成头文件、C实现、加载动态库四步闭环，字符串处理需注意UTF-16/UTF-8编码差异，JNI调用有性能开销且须谨慎管理资源与线程。
native方法本质是Java调用C/C++函数的桥梁
Java里native关键字修饰的方法，本身没有Java实现体，而是把具体逻辑交给JVM加载的本地动态库（如.so、.dll或.dylib）执行。它不是“Java内部优化手段”，也不是“JVM私有API”，而是明确的跨语言调用契约：Java声明接口，C/C++提供实现。
常见误解是认为native方法能“绕过JVM安全检查”——其实不能，JVM仍控制调用时机、参数校验、异常转换和内存生命周期；只是把计算逻辑下放到了原生层。
怎么写一个可用的native方法
必须四步闭环，缺一不可：
- 在Java类中用
public static native void doWork();声明，不写方法体，且必须加static（除非绑定到对象实例，但极少用） - 运行
javac编译后，用javah（旧版）或javac -h（JDK 10+）生成C头文件，例如com_example_Utils.h - 用C/C++实现该头文件里的函数，注意函数名带包路径（如
Java_com_example_Utils_doWork），参数含JNIEnv*和jclass（或jobject） - 编译成动态库，并在Java启动前用
System.loadLibrary("utils")加载（库名不含前缀/后缀，如libutils.so→"utils"）
漏掉System.loadLibrary会抛UnsatisfiedLinkError；函数签名不匹配（比如忘了JNIEnv*参数）会导致JVM直接崩溃（SIGSEGV），而非Java异常。
立即学习“Java免费学习笔记（深入）”；
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
为什么String传到C里经常乱码或截断
Java的String是UTF-16编码的不可变对象，而C默认处理的是char*（通常为UTF-8或系统locale）。直接用GetStringUTFChars拿到的指针，返回的是修改过的UTF-8变体（会转义非BMP字符），且必须配对调用ReleaseStringUTFChars，否则内存泄漏。
更稳妥的做法：
- 需要完整Unicode语义时，用
GetStringCritical+GetStringLength，但期间禁止调用任何JNI函数（包括GC） - 常规字符串操作，优先用
GetStringUTFRegion把指定范围转成UTF-8字节数组再处理 - 绝对不要把
jstring强转成char*，JNI不保证底层内存布局
性能和线程安全的隐性代价
每次JNI调用都有固定开销：参数压栈、线程状态切换（从Java态切到Native态）、引用局部表查找、可能触发GC屏障。单次调用耗时通常在100–500ns量级，远高于纯Java方法调用（~1ns）。
容易被忽略的关键点：
-
FindClass在多线程下非线程安全，应缓存jclass全局引用（NewGlobalRef） - C代码里创建的Java对象（如
NewObject）若未显式删除，会阻塞GC，尤其在循环中极易OOM - 本地线程（pthread）无法直接访问
JNIEnv*，必须通过AttachCurrentThread绑定，用完DetachCurrentThread，否则JVM线程计数错乱
最常出问题的不是功能逻辑，而是资源没释放、线程没解绑、字符串编码没对齐——这些错误往往在线上高并发时才暴露，且堆栈不报Java异常。
