编程语言
首页 > 编程语言> > Jni 线程JNIEnv,JavaVM,JNI_OnLoad(GetEnv返回NULL?FindClass返回NULL?)

Jni 线程JNIEnv,JavaVM,JNI_OnLoad(GetEnv返回NULL?FindClass返回NULL?)

作者:互联网

此文章是关于NDK线程的第二篇理论知识笔记。主要有两个点,如下:

1.pthread_create(Too many arguements, expected 1) ?
2.线程中如何获取JNIEnv?GetEnv返回NULL?
3.FindClass返回NULL ?
首先我们在主页MainActivity的代码如下:

public class MainActivity extends Activity {
 
    static {
        try {
            System.loadLibrary("native-lib");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
 
    public native void nativeThreadEnvTest();
 
    public static String getUuid() {
        // 提供给nativeThreadEnvTest使用
        return UUID.randomUUID().toString();
    }
    
    @Override
    protected void onCreate(Bundle savedInstanceState) ...
}
 nativeThreadEnvTest打算实现这样一个功能:for循环调用MainActivity.getUuid方法,打印出5串不同的UUID。听上去很简单,逻辑代码如下:

#include <unistd.h>
#include <pthread.h>
#include <assert.h>
 
void *pthread_run(void *arg) {
    JNIEnv *env = NULL;
    // get env ?
    char *name = (char *) arg;
    for (int i = 0; i < 5; ++i) {
        //char* uuid_cstr = ...
        LOGI("%s, No:%d, uuid:%s", name, i, uuid_cstr);
        sleep(1);
    }
 
    pthread_exit((void *) 0);
}
 
JNIEXPORT void JNICALL
Java_org_zzrblog_MainActivity_nativeThreadEnvTest(JNIEnv *env, jobject thiz) {
    pthread_t tid;
    pthread_create(&tid, NULL, pthread_run, (void *) "pthread1");
 
    //void* reval;
    //pthread_join(tid, &reval);
}

此时第一个坑点可能就会出现了:pthread_create报出错误提示 Too many arguements, expected 1(黑人三问号)

ctrl+左键,跳转到头文件pthread.h的定义,明明就是四个参数的啊?

rebuild,重启AS,各种大法都没解啊,怎么办? 这里给出可行科学的解决方案,在头文件添加如下宏定义就OJBK了!

#ifndef _PTHREAD_H_
#define _PTHREAD_H_
 
#include ...
// 添加宏定义 _Nonnull
#ifndef _Nonnull
#define _Nonnull
#endif

那么我们继续功能实现,在线程执行函数pthread_run中,想要调用MainActivity.getUuid方法,必须得有env啊。那么我们怎么获取env?可能就有大兄弟立马说:在nativeThreadEnvTest传入的env时NewGlobalRef啊,这样就可以全局使用了!这好像确实是一个解决思路,好像还蛮好使的(因为兄弟你见识得太少了)。但是!BUT!However! 严谨的说,这种做法是不可取的。为什么?引用Google官方翻译:

由于VM通常是多执行绪(Multi-threading)的执行环境。每一个执行绪在呼叫native函数时,所传递进来的JNIEnv指标值都是不同的。为了配合这种多执行绪的环境,C组件开发者在撰写native函数时,可藉由JNIEnv指标值之不同而避免执行绪的资料冲突问题,才能确保所写的native函数能安全地在Android的多执行绪VM里安全地执行。基于这个理由,当在呼叫C组件的函数时,都会将JNIEnv指标值传递到下一级函数使用。

看起来好像很抽象,似懂非懂的。但是我们必须知道:VM是多执行绪(Multi-threading) ,每个JNIEnv都是不同的!特别是在不同线程,都是独自维护各自独立的JNIEnv。  那么问题又回到最初的?怎么正确的获取线程安全的JNIEnv? 

此时我们引入函数JNI_OnLoad 和 结构体JavaVM,在头文件 jni.h 有它的定义:

/*
 * Prototypes for functions exported by loadable shared libs.  These are
 * called by JNI, not provided by JNI.
 */
JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved);
JNIEXPORT void JNI_OnUnload(JavaVM* vm, void* reserved);

从注释可知,JNI_OnLoad是由系统JNI回调的,并不由得开发者乱用,而且也不由JNI默认提供。不重写这个方法系统就默认进行配置。在虚拟机VM加载c组件的时候(so)就会调用组件加载接口JNI_OnLoad(),在JNI_OnLoad()函数里,就透过VM之指标而取得JNIEnv之指标值,并存入env指标变数里。

这里的JavaVM就是虚拟机VM在JNI中的表示,一个进程JVM中只有一个JavaVM对象,这个对象是线程共享的。换言之这个JavaVM是能全局安全使用的,而且也只能在JNI_OnLoad的回调进行强引用赋值。 有了这个JavaVM,我们再调用AttachCurrentThread 附加当前线程到虚拟机VM当中,并返回线程对应的JNIEnv,我们就能愉快的撸码了!

说到AttachCurrentThread,不能不提起JavaVM的另外一个接口 GetEnv,看上去GetEnv不就是获取env的方法吗?这么解释吧,只有先AttachCurrentThread到JavaVM,分配到了独立的JNIEnv之后,GetEnv第二个参数二级指针返回的env才有值。就是说JavaVM->GetEnv获取的是,此线程有效的env。JavaVM->AttachCurrentThread是向虚拟机分配线程独立的env。    所以一般在线程执行函数第一句是AttachCurrentThread,随后就能用GetEnv了。

理论知识介绍到这里,我们继续测试功能函数,现在代码应该是长这样的:

JavaVM *javaVM;
 
JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *vm, void *reserved) {
    LOGW("%s\n", "JNI_OnLoad startup ...");
    javaVM = vm;
    JNIEnv *env = NULL;
    jint result;
 
    if ((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_6) == JNI_OK) {
        LOGI("Catch JNI_VERSION_1_6\n");
        result = JNI_VERSION_1_6;
    }
    else if ((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_4) == JNI_OK) {
        LOGI("Catch JNI_VERSION_1_4\n");
        result = JNI_VERSION_1_4;
    }
    else {
        LOGI("Default JNI_VERSION_1_2\n");
        result = JNI_VERSION_1_2;
    }
 
    assert(env != NULL);
    // 动态注册native函数 ...
    return result;
}
 
void *pthread_run(void *arg) {
    JNIEnv *env = NULL;
    // (*javaVM)->AttachCurrentThread(javaVM,&env,NULL)
    // (*javaVM)->GetEnv(javaVM, (void **)&env, JNI_VERSION_1_6)
    if ( (*javaVM)->AttachCurrentThread(javaVM,&env,NULL) != JNI_OK) {
        LOGE("javaVM->Env Error!\n");
        pthread_exit((void *) -1);
    }
 
    assert(env != NULL);
   
    // 自定义的类型 jclass
    jclass clazz = (*env)->FindClass(env, "org/zzrblog/MainActivity");
    jmethodID getUuid_mid = (*env)->GetStaticMethodID(env, clazz, "getUuid","()Ljava/lang/String;");
 
    char *name = (char *) arg;
    for (int i = 0; i < 5; ++i) {
        jobject uuid_jstr = (*env)->CallStaticObjectMethod(env, clazz, getUuid_mid);
        char* uuid_cstr = (char *) (*env)->GetStringUTFChars(env, uuid_jstr, NULL);
        LOGI("%s, No:%d, uuid:%s", name, i, uuid_cstr);
        sleep(1);
    }
 
    (*env)->ReleaseStringUTFChars(env, sys_uuid_jstr, sys_uuid_cstr);
    (*javaVM)->DetachCurrentThread(javaVM);
    pthread_exit((void *) 0);
}

我们在JNI_OnLoad函数全局引用JavaVM对象,然后就是模板代码了,告诉系统虚拟机用哪个版本的JNI。此时调用JavaVM->GetEnv获取的env是主线程的。所以我们能获取成功。

然后我们进入线程执行函数,使用AttachCurrentThread请求分配当前线程安全的env,之后我们使用FindClass / GetStaticMethodID / CallStaticObjectMethod 等JNI API进行Java层的MainActivity.getUuid 静态方法的调用。

一切看着都是那么顺利,然后运行demo瞬间报错(奸笑.jpg)一堆红通通的错误啊!

为什么会找不到 org.zzrblog.MainActivity?此问题更好的体现了JNIEnv的线程独立性问题了!如果FindClass用的是主线程env就不会报错了。如果FindClass的是系统的UUID类也不会报错了。但是现实生活没有那么多如果!问题的原因就是只有主线程的env才有包含我们自定义(自己开发)的类类型,而 AttachCurrentThread的线程安全env只加载了系统的类类型,并不包含自定义的类类型。
所以问题的原因找到了,怎么解?既然env不是线程安全,不能直接引用。那么我们可以引用其他线程共享的调用对象啊,再通过GetObjectClass获取jclass。不明白的同学看如下代码:

jobject jMainActivity;
 
JNIEXPORT void JNICALL
Java_org_zzrblog_MainActivity_nativeThreadEnvTest(JNIEnv *env, jobject thiz) {
    if(jMainActivity == NULL) {
        //调用对象,创建全局引用
        jMainActivity = (*env)->NewGlobalRef(env, thiz);
    }
 
    pthread_t tid;
    pthread_create(&tid, NULL, pthread_run, (void *) "pthread1");
    //void* reval;
    //pthread_join(tid, &reval);
}

现在知道native方法的 static 和 非static的时候,传入的第二个参数的意义和真实的用处了吧?

非static的时候,传入jobject类型的thiz,就相当于MainActivity.this了。

staic的时候,传入jcalss类型的clazz,就相当于MainActivity.class了。

标签:返回,OnLoad,void,线程,env,pthread,JNI,NULL,JNIEnv
来源: https://www.cnblogs.com/zhujiabin/p/10605792.html