已知输入为DirectByteBuffer时，JNI直接读取其address字段有何风险？

背景 #

我开发了一个接收DirectByteBuffer并对其进行操作的JNI库。最初使用(unsigned char *) env->GetDirectBufferAddress(input)获取缓冲区地址，但性能分析发现jni_IsInstanceOf函数耗时过长。于是改为直接访问Buffer.address字段，实现代码如下：

java_nio_Buffer = env->FindClass("java/nio/Buffer");
java_nio_Buffer_address = env->GetFieldID(java_nio_Buffer, "address", "J");
(...)
(unsigned char *) env->GetLongField(input, java_nio_Buffer_address)

该修改带来了巨大的性能提升。现咨询：在已知输入对象一定是DirectByteBuffer的情况下，这种获取地址的方式存在哪些主要风险？

主要风险 #

• 依赖JVM内部实现，兼容性极差：java.nio.Buffer的address字段是JDK未公开的内部细节，不属于标准API范畴。不同厂商的JVM（如HotSpot、OpenJ9、GraalVM）或同一JVM的不同版本，可能随意修改该字段的名称、类型甚至直接移除它。比如部分JVM会对内部字段进行混淆，或者在新版本重构NIO模块后，该字段的逻辑完全变化，你的JNI代码会因GetFieldID返回NULL或读取到错误值而直接崩溃。

• 跳过JVM安全校验，引发内存问题：标准APIGetDirectBufferAddress会由JVM完成一系列安全检查：验证缓冲区是否有效、是否已被清理回收，同时处理Java内存模型（JMM）的内存屏障以保证数据可见性。直接读取address字段会跳过所有这些校验，可能导致你访问到已被释放的无效内存，引发段错误、数据损坏或程序崩溃。比如当DirectByteBuffer通过cleaner()显式释放后，address字段的值会变成无效指针，但你的代码无法感知。

• 压缩指针等JVM配置带来的地址错误：在64位JVM中，默认启用的压缩指针（Compressed Oops）机制或其他内存优化策略，可能让address字段存储的并非直接可用的内存地址，而是经过JVM内部编码的值。GetDirectBufferAddress会自动处理这些编码转换，而直接读取long字段得到的值可能是错误的，导致访问非法内存区域。

• 未来版本升级直接失效：JDK官方从未承诺address字段会保持稳定，后续JDK版本极有可能变更或移除该字段。一旦升级JDK，你的JNI库会立即无法工作，需要重新适配；而使用标准JNI APIGetDirectBufferAddress则无需担心，因为它是公开的兼容API，会持续得到官方支持。

• 意外输入导致的不可控崩溃：即便你认为输入一定是DirectByteBuffer，实际运行中仍可能因代码逻辑错误传入其他Buffer子类。GetDirectBufferAddress遇到非直接缓冲区会返回NULL，方便你做错误处理；但直接读取address字段会直接使用错误的内存地址，引发不可预测的崩溃或数据混乱。

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