在一年前的blog中，我們提到了由於JNI中的對象出現內存泄漏導致的JNI global reference table overflow，會導致system_server進程被kill掉而發生系統重啓。
https://blog.csdn.net/aaajj/article/details/83141985
系統重啓，log
pid: 1279, tid: 2518, name: Binder:1279_9 >>> system_server <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): global reference table overflow (max=51200)'
backtrace:
#00 pc 000000000006d794 /system/lib64/libc.so (tgkill+8)
#01 pc 000000000006abb4 /system/lib64/libc.so (pthread_kill+64)
#02 pc 0000000000024098 /system/lib64/libc.so (raise+24)
#03 pc 000000000001c93c /system/lib64/libc.so (abort+52)
#04 pc 000000000043581c /system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+464)
#05 pc 00000000000e5e7c /system/lib64/libart.so (_ZN3art10LogMessageD2Ev+1592)
#06 pc 000000000024dd48 /system/lib64/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+308)
#07 pc 00000000002f2468 /system/lib64/libart.so (_ZN3art9JavaVMExt12AddGlobalRefEPNS_6ThreadEPNS_6mirror6ObjectE+60)
#08 pc 000000000032de8c /system/lib64/libart.so (_ZN3art3JNI12NewGlobalRefEP7_JNIEnvP8_jobject+596)
#09 pc 0000000000101454 /system/lib64/libandroid_runtime.so (_ZN7android20javaObjectForIBinderEP7_JNIEnvRKNS_2spINS_7IBinderEEE+428)
#10 pc 00000000000f5a3c /system/lib64/libandroid_runtime.so
#11 pc 000000007564f254 /data/dalvik-cache/arm64/system@[email protected] (offset 0x19fc000)
主要發生泄漏的地方在javaObjectForIBinder 和 contentObersver對象的處理上，這2個地方Android代碼中都進行了修復處理，
惡意註冊contentObersver的進程由於binderProxy對象太多，會被系統kill掉。具體處理過程可抓log查看，
參考apk
https://github.com/SundayCool/JNIoverflow
系統進程system_server將很難出現JNI global reference table overflow導致的重啓問題了，
所以，JNI global reference table overflow將會淡出開發者的視線，或許會被遺忘。
再見了，JNI global reference table overflow