一、什麼是JNI
（一）什麼是JNI (Java Native Interface)
JNI全稱是Java Native Interface，顧名思義是Java和Native間的通信橋樑，如下圖所示，圖的上方是Java世界，下面是Native世界，中間是JNI通信，左邊箭頭從上往下是Java調用Native的方法，右邊是Native調用Java，彼此可以互通。
這種方式帶來的好處，Java調用Native，可以去調用非Java實現的庫，擴充Java的使用場景，比如調用Tensorflow；反之Native調用Java，可以在別的語言裡面調用Java，比如java launcher可以命令啟動Java程序。
（二）為什麼要學習JNI
掌握Java和Native之間的互相調用，大大豐富java的使用場景。瞭解原理，對於學習JVM/故障定位更加得心應手。
經典例子，如下圖所示，在主函數裡面用Selector.open創建一個select，叫select方法，這是Java裡面通過NIO取允許網絡的方法。
public static void main(String[] args) throws Exception {
java.nio.channels.Selector.open().select();
}
這個方法會阻塞其當前線程，通過java.lang呈現狀態是RUNNABLE，看到RUNNABLE總覺得會消耗CPU、NIO的BUG, 其實是一個經典謬誤，實際上線程是禁止的。
二、JNI實踐和思考
實戰一: 從native調用Java
首先要#include <jni.h> ，這個頭文件定義了各種Java和Native交互的數據結構以及定義；在主函數裡面，首先聲明一個JVM的指針，然後一個JNIEnv *env的指針，JVM表示的Java虛擬實例，我通過實例消耗資源進行各種操作。
env其實對應的是一個線程，然後創建JavaVMInitArgs結構體，結構體裡面要填充Java參數，用JavaVMOption表示。因為這裡不需要參數，場景比較簡單，所以用options[0]，把 options傳入 vm_args.options結構體，最後調用JNI_CreateJavaVM創建 Java虛擬器，如果返回的是“JNI_OK”，說明這次調用成功。
有了JNI指針表示實例以後，就可以用標準方法使用JNI，在這裡調用一個Java方法，比如Java數據結構，先通過EMC的FindClass，找到SelectorProvider類，中間有個printf變量叫lock，先通過 GetStaticField獲取 field，再通過GetStaticObjectField從 cls對象上獲取fid，就是 lock對象，然後把它打印出來，最後jvm->DestroyJavaVM。詳情操作如下圖所示：
還有一個比較經典的例子Java Launcher， java –jar spring-application執行程序的時候，在後臺默默的創建了一個jvm，把Java參數作為 arguments傳進去，調用Java入口方法，通過JNI實現。
平時所說，開發jvm其實就是開發jvm的動態庫， “libjvm.so”基本上本身是作為“os”提供出去，好處是非常靈活，可以作為獨立應用使用，也可以在別的像cer這樣的語言調用，使Java調用Native，Native調用Java更加靈活。
JNI實戰二: Java調用C
Java調用C是使用JNI最常見的方式，首先定一個類叫HelloJNI，裡面有System.loadLibrary("hello"); 系統會自動去找到library libhello.so，這個類裡面定義方法叫sayHello，加了C以後調用它，但這是調不通的，因為並沒有提供真正的Native實現。實現要通過一個頭文件去告訴這個方法的簽名，這裡實現Java文件，然後通過jni.h生成頭文件，這個是自動生成的。
簽名是 Java，然後是Java_HelloJNI_sayHello(JNIEnv *, jobject)規範，類名加上方法名，參數第一個是環境；第二個是jobject，無參數，但是 Java的方法默認是有一個this指針作為第一個參數，最後編寫它，實現HelloJNI.c，根據這個聲明定義實現，然後裡面只是printf了一下，把 HelloJNI.c定義成libhelloHello.so這個程序就可以運行起來了。詳情如下圖所示：
在Java應用裡面，可以調通過JNI調用各種庫，調用到native以後，因為任何語言跟native都互相交互，大大豐富了Java使用場景。
思考一: Java和Native的數據是怎麼傳遞的
在執行Java方法時，用的是java heap，假設暫時向下增長，需要調用 c函數的時候，它需要去壓站，把 object壓站、把JNIEnv壓站、cstack壓站，進入seat stack。然後 object本質上是指向handle的指針，handle指向戰上真正的OOP，使用二級指針結構，稍微有點複雜。詳情如下圖所示：
思考二: 回到問題，為什麼select()的線程狀態是RUNNABLE
JNI只是提供一種機制，讓Java程序可以進入Native狀態，Native狀態基本上沒有辦法管理。這段Native代碼在做一種非常複雜的數學運算，肯定是RUNNABLE狀態，也可以調用系統形象去阻塞，但這個阻塞基本上不知情，所以會一直顯示為RUNNABLE，除非通過JNI的特殊接口改變現實狀態，到其他狀態才會顯示為其他狀態，所以這裡顯示為RUNNABLE為正常，不用擔心RUNNABLE狀態消耗很多CPU等問題。
三、JNI與safepoint
首先有這樣兩個問題：
1、JNI是否會影響GC進行？
2、GC時JNI修改Java Heap怎麼保證一致？
看到第二個問題的時候，已經回答第一個問題，假如GC是不能運行JNI，那也就沒有一致性問題，所以在GC時可以執行JNI。
（一）JNI與Safepoint的協作
首先要知道Java的信任狀態，Java最主要信任狀態是“Thread in Java”狀態，這個狀態裡面在執行一個解釋器或者已經編譯的方法，純Java執行。這時候如果發生Safepoint，會通過Interpreter機制把這個線程直接掛起，暫停下來，然後去Safepoint裡面進行GC的各種操作。
在Java裡面，調用JNI進入Native，會切換到Thread in native狀態，這裡執行Native函數，在執行的時候跟GC可以並行執行，因為理論上要麼執行，要麼通過JNI和JNI交互，所有的跟JNI相關的數據結構都可以被管理。然後Native還可以去切換到JVM狀態，這是非常關鍵的狀態，這個狀態不能發生GC，不用關心。
JNI與Safepoint交互，假如JNI執行時發生Safepoint能並行。JNI執行的時候返回Java，這時候會被阻塞，需要檢查狀態，卡在Safepoint狀態，直到Safepoint結束，繼續回到Java。
（二）JNI與GC
透過幾個JNI管中窺豹，瞭解這個機制：
void * GetPrimitiveArrayCritical(JNIEnv *env, jarray array, jboolean *isCopy);
void ReleasePrimitiveArrayCritical(JNIEnv *env, jarray array, void *carray, jint mode);
這個函數叫做GetPrimitiveArrayCritical。Critical作用是把一段內存返回給用戶，用戶可以直接編輯裡面的數據，這時如果發生GC被移動，編輯肯定會導致 heap亂掉，有Critical這段時間裡鎖住heap，沒法發生GC。假如 critical狀態發生期間，基本上不會影響GC，會等待，直ReleasePrimitiveArrayCritical發出，這是比較巧妙的互相協作。
下圖所示的二級指針模型，還是前面Java調到Native，參數通過jobject到handle保存使用，jobject指向handle，handle指向oop。
java heap時候，假如OOP對象被移動handle，同時會更新 handle裡面的地址。所以只要C程序都是通過JNI訪問對象，每次對象被移動它都可以被感知，不會出現數據佈局之後突然情況。
“GC: handle_are->oops_do(f)”
指有區域專門存放handle，裡面所有handle在GC裡，都會進行一次指針修正，保證數據一致性。
四、JNI與Intrinsic
（一）高級主題: intrinsic
如下圖所示，以非常常見JNA“currentThread”為例子，說明Intrinsic機制。Intrinsic在看到currentThread的時候，不會去JNI，而是通過形成更高效的版本。
這裡inline_native_currentThread的時候，最終會調用generate_curent_thread工具。然後看裡面的實現核心部分，創建“ThreadLocalNode()”，代表當前JavaThread結構的指針，再通過JavaThread結構裡的threadObj_offset()拿到它，通常是一個偏移量，拿到Object以後作為返回值返回。這裡是一段AI，真正生成代碼時被翻譯成非常簡約的幾條指令，直接返回。所以“currentThread”變得非常高效，這就是Intrinsic機制，主要為性能而生。
（二）Intrinsic性能分析
對比一下Intrinsic與非Intrinsic性能，如下圖所示，是用jmh寫的Benchmark，可以規避掉一些具體的預熱不夠，導致性能測試不準的問題，用它進行測試，也是官方推薦的版本。
Intrinsic版本，下面測試叫“jni”，主要區別就是Intrinsic後面接了一個叫isAlive的調用。isAlive本身狀態調用看起來非常輕量，但因為他沒有做Intrinsic，所以最終會走JNI。
下圖所示，對比普通Intrinsic與加上JNI的Intrinsic性能，普通 Intrinsic的性能大概是3億次每秒；加上JNI的Intrinsic版本的性能是2000萬次每秒，差了十幾倍，差距很大。
進一步看性能問題，最重要的是performing，performing手段是perform，public第二段JNI版本，前面兩個熱點方法都是“ThreadStateTransition”現任狀態轉換。前面說到，假如JNI回到 Java時候做GC肯定要停下來，所以這有個內存同步比較好資源，要等的時間比較長，所以這兩個函數是最熱的。
下面是“JVM_IsThreadAlive”實現。後面是“HandleMark::pop_and_restore”在調JNI時需要把oop包裝成handle，JNI退出時，需要消費handle， restore指有開銷。再後面“java_lang_Thread::is_alive”佔比4.77% 非常小。
由此可以看出Intrinsic提供性能非常好的機制，直接調用JNI，性能可能差一點，但也可以接受。
（三）案例分析: RocketMQ Intrinsic導致應用卡頓
RocketMQ 是阿里巴巴開源的MQ產品，使用非常廣泛，裡面有個函數叫“warmMappedFile”，指的是RocketMQ是通過warmMapped機制內存映射磁盤去做IO，在申請完一塊磁盤映射的內存以後，會去做預熱。
這裡有for循環“for (int i = 0, j = 0; i < this.fileSize”，每隔一個PACG_SIZE去“byteBuffer.put(i, (byte) 0)”;，這樣的話，操作系統就會發生缺頁，把內存真正分配出來，而不只是EMV數據結構。分配出來以後，等到程序真正使用這塊內存的時候，就是純內存IO，不太會觸發這種缺頁了，可以變得更快，目的是減少程序卡頓。
但是後面加了if這一段，可以想到剛開始這個循環有問題，因為 byteBuffer.put是Intrinsic，最底層是Intrinsic，方法返回的時候，沒有方法調用。JVM在方法返回以及循環末尾檢查，是否有Safepoints，來看是否要進入GC，但是因為這是一個Intrinsic，所以沒有到檢查點，同樣這是一個CountedLoop，也沒法去進入檢查點。因為JVM有個機制，如果這是一個 int作為index去Counted次數的話，為了性能是不會去檢查，因為它認為這是有限次的循環，所以不用檢查次數。
這種機制循環裡面非常簡單，中間有可能因為操作系統原因帶來卡頓，導致循環，基本上沒法進入GC，因為線程沒有進入Safepoints，整個界面都沒法進入GC, 夯住很長時間，當時大家覺得很不可思議，但是通過一個很簡單方法修好了，就是每隔1000字循環的時候，去調一個“Thread.sleep(0)”。
剛剛提到，“byteBuffer.put”沒法出發，Thread.sleep是個JNI，返回的時候會檢查Safepoints，所以就可以讓這個程序能夠進入到Safepoints，這個代碼就不會影響JVM進入到GC了，代碼目前還可以從開源軟件上看到。
“-XX:+UseCountedLoopSafepoints”
解決這個問題，還有另一種方式，通過一個選項叫“-XX:+UseCountedLoopSafepoints”，可以JVM自動在CountedLoop結尾檢查這Safepoints，當然這帶來的副作用是，CountedLoop末尾都會檢查Safepoints，這樣就會影響整體性能。