整理 Effective Java 書中 Item 66: Use native methods judiciously 心得筆記

主旨

Java 提供 JNI（Java Native Interface），從 Java 呼叫 C 或 C++ 寫的 native 方法。這看似能補足 Java 做不到的事，但實際上，除非真的必要，最好避開 native methods，因為這樣做會犧牲安全性、可移植性與除錯性。

使用 native methods 的常見目的

目的是否合理備註
✅ 存取平台特有功能可以如 Windows registry、底層裝置
✅ 存取原生函式庫（如 GMP）可以當 Java 沒有等效工具時
⚠️ 追求更高效能很少需要JVM 效能已大幅進步，大多不必靠 native code

早期 JVM 效能不佳，BigInteger 曾經使用 native C 函式庫來處理多精度運算。但後來 Java 的實作經過優化，純 Java 版本甚至跑得比原本的 native code 還快。

現代 Java 幾乎不需要 native code

大部分平台功能現在 Java 都內建了。例如：

  • Java 9 加入的 Process API 可以操作作業系統行程，不需再呼叫 OS 的原生 API。
  • Java NIO 提供檔案存取、記憶體映射等功能。

若不是極端需求，例如高效能的多精度運算（如用 GMP），很少有理由還需要寫 JNI。

native methods 的風險與代價

問題說明
❌ 安全性風險native code 沒有記憶體安全保證，可能造成 memory corruption
❌ 可移植性變差原生碼與平台耦合，換平台可能就不能跑
❌ 除錯困難native 錯誤常不是 Java stack trace 能處理的
❌ 垃圾回收不掌握 native 資源GC 無法追蹤 native 配置的記憶體，易造成資源洩漏
❌ 呼叫成本高Java ↔ native 之間的切換本身就有額外效能負擔
❌ Glue Code 難寫難看JNI 宣告與 C/C++ 實作要對應，維護成本高

建議做法與替代方案

  1. 能用純 Java 解決就別寫 JNI：

    • 效能不一定差，而且更安全、更跨平台。

  2. 真的要用時，把 native code 封裝小一點：

    • 把 JNI 使用限制在單一小模組。
    • 最好用純 Java 包一層進行防呆與隔離。

  3. 測試 native code 要非常完整：

    • 一個 native bug，會 crash 整個 JVM。

  4. 盡量用現成工具而非手寫 JNI glue code：

小結

建議理由
✅ 若只是為了效能，幾乎不需要用 nativeJVM 已很快，反而會引來災難
✅ 若真需要 native，用得越少越好降低維護與風險
❌ 不要以為 JNI 很好它的代價與風險都非常真實

✅ 結語：現代 Java 幾乎不需要 native code，除非你真的走到語言邊界。不確定時，優先選用純 Java 解法，再考慮 JNI。