native方法的本质是无实现体的占位符，其实际逻辑由c/c++动态库通过jni在本地方法栈执行；它用于调用操作系统功能、高性能模块、硬件驱动或复用遗留c代码。
native 是 Java 中一个修饰方法的关键字，它不表示方法逻辑，而是告诉 JVM：这个方法的实现不在 Java 里，而是在外部本地代码中（通常是 C 或 C++ 编写的动态库）。
native 方法的本质是什么
它是一个“占位符”——只有方法声明，没有方法体。编译时不会报错，但运行时若未正确加载对应本地库，会抛出 UnsatisfiedLinkError。JVM 在调用时会跳转到本地方法栈，通过 JNI（Java Native Interface）机制去查找并执行真正的 C/C++ 函数。
- 被 native 修饰的方法必须是 static 或 实例方法，但不能是 abstract、synchronized、strictfp 等与其他语义冲突的修饰符
- 方法签名需与 C/C++ 实现严格匹配，包括类名、方法名、参数类型和返回值（JNI 有固定命名规则，如
Java_com_example_HelloNative_sayHello） - Java 层无需关心内存管理，但 C 层需手动处理 JVM 提供的
jstring、jobject等类型转换
为什么需要 native 关键字
它解决的是 Java 语言能力边界之外的问题，不是为了炫技，而是实际工程中绕不开的需求：
- 调用操作系统特有功能，比如 Windows 的服务控制、Linux 的
epoll、文件锁或进程权限设置 - 接入高性能计算模块，像音视频编解码（FFmpeg）、图像处理（OpenCV）、密码学算法（BoringSSL）等，C 实现往往比 Java 快数倍
- 对接硬件设备驱动，如串口通信、USB 设备、摄像头底层控制，这些通常只提供 C 接口
- 复用已有 C/C++ 遗留系统，避免重写整套核心逻辑，尤其在金融、嵌入式或游戏引擎集成场景中很常见
怎么写出一个能跑通的 native 示例
关键不在 Java 写得多漂亮，而在三步闭环是否完整：Java 声明 → 生成头文件 → C 实现并编译成动态库 → 正确加载。
- Java 类中用
static { System.loadLibrary("xxx"); }加载库（注意名字不含.dll或.so后缀） - 用
javac编译后，用javah -jni（旧版 JDK）或javac -h（JDK 10+）生成 .h 头文件，它定义了 C 函数原型 - C 文件里包含该头文件，实现函数体，用 gcc/clang 编译为动态链接库（Windows 下为
xxx.dll，Linux/macOS 为libxxx.so或libxxx.dylib） - 确保 JVM 能找到库：放在
java.library.path指定路径，或用System.setProperty("java.library.path", "...")临时追加（注意该属性需在加载前设置）
常见踩坑点提醒
很多问题不是语法错，而是环境和约定没对齐：
- JNI 函数名拼写错误（大小写、下划线、包路径分隔符混淆），导致 JVM 找不到符号
- 32 位 Java 进程加载了 64 位 DLL，或反之，直接崩溃
- C 层返回了局部变量地址（如栈上分配的 char 数组），Java 层拿到后变成野指针
- 忘记在 C 中调用
ReleaseStringUTFChars等释放 JNI 引用，引发内存泄漏 - 多线程环境下 native 方法未加锁，而 C 代码本身非线程安全
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
