JNIEnv的哲学
Java通过JNI 机制调用c/c++写的native程序。c/c++开发的native程序需要遵循一定的JNI规范，下面的例子就是一个JNI函数声明：
JNIEXPORT jint JNICALL Java_jnitest_MyTest_test (JNIEnv * env, jobject obj, jint arg0);
JVM负责从Java Stack转入C/C++ Native Stack。当Java进入JNI调用，除了函数本身的参数(arg0),会多出两个参数：JNIEnv指针和jobject指针。
JNIEnv指针是JVM创建的，用于Native的c/c++方法操纵Java执行栈中的数据，比如JavaClass,JavaMethod等。
首先，JNI对于JNIEnv的使用,提供了两种语法:c语法以及c++语法，如下：
c语法：jsize len = ( * env) -> GetArrayLength(env,array);
c++语法
jsize len = env -> GetArrayLength(array);
(注：由于C语言并不支持对象的概念，所以C语法中需要把env作为第一个参数传入，类似于C++的隐式参数this指针).
另外：JNIEnv有几个设计的原则：
第一、JNIEnv指针被设计成了ThreadLocalStorage(TLS)变量，也就是说每一个Thread,JNIEnv变量都有独立的Copy。这样做的原因主要是考虑到：
由于JVM要运行在多个平台（除了主流的Windows,Linux等平台),JNI内部实现很多要依赖到TLS，为了减少对TLS的依赖，所有TLSbased的数据都会存放于JNIEnv中。这样相当于只依赖一个TLSbased的变量JNIEnv。由于JNIEnv指针是TLS的，所以你不能把Thead#1使用的JNIEnv传给Thread#2使用。
第二、JNIEnv中定义了一组函数指针，c/c++Native程序是通过这些函数指针操纵Java数据。这样设计的好处是：你的c/c++程序不需要依赖任何函数库，或者DLL。由于JVM可能由不同的厂商实现，不同厂商有自己不同的JNI实现，如果要求这些厂商暴露约定好的一些头文件和库，这不是灵活的设计。
而且使用函数指针表的另外一个好处是： JVM可以根据启动参数动态替换JNI实现。比如：类似于C库，JNI实现为了性能起见，并没有对调用者传入的参数进行检查。但是在调试阶段，也许这种检查是很必要的，帮助你尽早发现BUG。例如如果你使用IBM JDK，你可以指定JVM参数–Xcheck:jni，告诉JVM使用带检查的JNI实现。摘自：http://leongod.iteye.com/blog/1132273