jni调试最蛋疼的就是signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4这种错误，爆出来完全不知道是哪句代码造成的，很难定位到问题所在，网上很多人说是内存原因，还有说是空指针，不一而论。
我的错误是这样的：
02-16 14:54:53.041 20897-20897/? I/AEE/AED: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4
02-16 14:54:53.058 20897-20897/? I/AEE/AED: r0 00000001 r1 00000002 r2 00000000 r3 0000002f
02-16 14:54:53.058 20897-20897/? I/AEE/AED: r4 00000000 r5 f4489000 r6 f4400000 r7 f6fb3c0c
02-16 14:54:53.058 20897-20897/? I/AEE/AED: r8 f48000c0 r9 f6fb3c0c sl 00000001 fp 00000002
02-16 14:54:53.058 20897-20897/? I/AEE/AED: ip f6fb3c24 sp dc144060 lr 00000000 pc f6f7f566 cpsr 600f0030
02-16 14:54:53.059 20897-20897/? I/AEE/AED: backtrace:
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #00 pc 00042566 /system/lib/libc.so (je_arena_dalloc_bin_locked+365)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #01 pc 0004fa0b /system/lib/libc.so (je_tcache_bin_flush_small+234)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #02 pc 0004a33f /system/lib/libc.so (ifree+446)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #03 pc 00035775 /data/app/我的包名-1/lib/arm/libjni-lib.so (std::__ndk1::basic_string, std::__ndk1::allocator >::~basic_string()+148)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #04 pc 00086087 /data/app/我的包名-1/lib/arm/libjni-lib.so (WPZHandler::OnRspQryPosition(TradingLibFast::RspQryPositionResponse*)+2518)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #05 pc 0004451d /data/app/我的包名-1/lib/arm/libjni-lib.so (TradingLibFast::TLClient::HandleMessage(TradingLibFast::Message&)+964)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #06 pc 00041083 /data/app/我的包名-1/lib/arm/libjni-lib.so (TradingLibFast::TLClient::RecvFun()+226)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #07 pc 00066cfb /data/app/我的包名-1/lib/arm/libjni-lib.so (fastdelegate::FastDelegate0::operator()() const+94)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #08 pc 00066889 /data/app/我的包名-1/lib/arm/libjni-lib.so (TradingLibFast::TLThread::ProcessInThread()+68)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #09 pc 00066837 /data/app/我的包名-1/lib/arm/libjni-lib.so (TradingLibFast::ThreadFunc(void*)+26)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #10 pc 00017003 /system/lib/libc.so (__pthread_start(void*)+30)
02-16 14:54:53.059 20897-20897/? I/AEE/AED: #11 pc 0001506f /system/lib/libc.so (__start_thread+6)
然后就是nativeCrashListener，这个log其实已经很清晰了，记得一定不要过滤，选择no Filters，日志级别选择Verbose最低级别，这样才能看到最全的log信息。je_arena_dalloc_bin_locked显示就是内存处理出问题了，jni代码出问题导致了系统错误。再往下包含“我的包名”的log信息就显示了错误的具体位置，越上面就是越具体的位置，越下面范围就越广，这里大致就定位了问题代码大概在哪几行。不过这几行我纠结了许久，因为觉得没有问题，闪退只是偶现，后来看到另外一篇文章：常见 core dump 原因分析signal 11 - SIGSEGV,说signal 11 (SIGSEGV)是由于内存释放不当（多次释放或者空释放）或者空指针引起的，遂检查，终于发现了问题：
在调用NewStringUTF方法的时候使用了ReleaseStringUTFChars进行释放，这个释放内存的方法并不能在此处使用，应该使用DeleteLocalRef来释放引用即可。
jni具体内存释放对应方法如下：
总体原则：释放所有对object的引用
1.FindClass
例如，
jclass ref= (env)->FindClass("java/lang/String");
env->DeleteLocalRef(ref);
2.NewString/ NewStringUTF/NewObject/NewByteArray
例如，
jstring (*NewString)(JNIEnv*, const jchar*, jsize);
const jchar* (*GetStringChars)(JNIEnv*, jstring, jboolean*); void (*ReleaseStringChars)(JNIEnv*, jstring, const jchar*);
jstring (*NewStringUTF)(JNIEnv*, const char*);
const char* (*GetStringUTFChars)(JNIEnv*, jstring, jboolean*); void (*ReleaseStringUTFChars)(JNIEnv*, jstring, const char*);
env->DeleteLocalRef(ref);
3.GetObjectField/GetObjectClass/GetObjectArrayElement
jclass ref = env->GetObjectClass(robj);
env->DeleteLocalRef(ref);
4.GetByteArrayElements和GetStringUTFChars
jbyte* array= (*env)->GetByteArrayElements(env,jarray,&isCopy);
(*env)->ReleaseByteArrayElements(env,jarray,array,0);
const char* input =(*env)->GetStringUTFChars(env,jinput, &isCopy);
(*env)->ReleaseStringUTFChars(env,jinput,input);
5.NewGlobalRef/DeleteGlobalRef
jobject (NewGlobalRef)(JNIEnv, jobject);
void (DeleteGlobalRef)(JNIEnv, jobject);
例如，
jobject ref= env->NewGlobalRef(customObj);
env->DeleteGlobalRef(customObj);
改完果然就没有再闪退了！