Android NDK方法存在重入问题，附实现代码求助

老兄，看来你在Android NDK的FrameReceived方法上碰到重入问题了，我来帮你拆解排查，一步步解决这个坑。从你贴的代码片段来看，几个典型的重入风险点已经很明显了，咱们逐个捋：

重入问题本质上就是同一个函数被多个线程同时调用，或者执行过程中被中断后再次进入，导致共享资源（比如全局变量、JNI环境、内存块）出现竞争错乱。先看你代码里的几个高危点：

1. JNIEnv的线程安全大坑 #

你用getJniEnv(&isAttached)获取JNI环境，但要记住：JNIEnv是线程局部的，绝对不是线程安全的！如果FrameReceived被多个线程触发（比如异步回调、多线程任务），直接复用这个env指针分分钟会导致崩溃或者数据乱掉。

• 修复方案：确保每个线程都正确获取自己的JNIEnv，而且如果是临时附加的线程，用完必须记得 detach（注意：只有咱们自己附加的线程才需要 detach，别碰主线程的附着状态）。
• 代码修正示例：

env = getJniEnv(&isAttached);
if (env == NULL) goto FAIL0;

// ... 你的业务逻辑代码 ...

FAIL0:
// 只有主动附加的线程才需要解除附着
if (isAttached && env != NULL) {
    (*env)->DetachCurrentThread(env);
}

2. 共享资源的竞争问题 #

如果FrameReceived里用到了全局变量、静态变量（比如你代码里的jParticipant，或者后续对modifiedRawImageBytes的全局引用），多个线程同时读写这些变量肯定会出问题——数据覆盖、内存泄漏、逻辑错乱都是常见后果。

• 排查方向：检查函数内所有跨线程访问的变量，有没有未加保护的读写操作。
• 修复方案：用互斥锁（pthread_mutex_t）把临界区代码锁起来，确保同一时间只有一个线程能操作共享资源：

// 在函数外部初始化全局互斥锁
pthread_mutex_t frame_mutex = PTHREAD_MUTEX_INITIALIZER;

void FrameReceived(int width, int height, const char *rawImageBytes, int size, jboolean remote) {
    if(size == 0) return;

    // 加锁，进入临界区
    pthread_mutex_lock(&frame_mutex);

    jboolean isAttached;
    JNIEnv *env;
    jint jParticipant;
    jint jWidth;
    jint jHeight;
    jbyteArray jRawImageBytes;
    env = getJniEnv(&isAttached);
    if (env == NULL) {
        pthread_mutex_unlock(&frame_mutex); // 失败也要解锁，避免死锁！
        goto FAIL0;
    }

    char *modifiedRawImageBytes = malloc(size);
    if (!modifiedRawImageBytes) {
        // 内存分配失败，先解锁再处理
        pthread_mutex_unlock(&frame_mutex);
        if (isAttached && env != NULL) {
            (*env)->DetachCurrentThread(env);
        }
        return;
    }

    // ... 你的内存操作、JNI调用逻辑 ...

    // 释放内存
    free(modifiedRawImageBytes);

    // 解锁，退出临界区
    pthread_mutex_unlock(&frame_mutex);

FAIL0:
    // 兜底：确保锁处于解锁状态，防止死锁
    if (pthread_mutex_trylock(&frame_mutex) == 0) {
        pthread_mutex_unlock(&frame_mutex);
    }
}

⚠️ 注意：锁的粒度要尽量小，别把整个函数都锁死（非临界区代码可以放在锁外面），同时要避免嵌套锁，防止死锁。

3. 内存分配与释放的重入隐患 #

你用malloc(size)分配了modifiedRawImageBytes，虽然大部分系统的malloc实现是线程安全的，但如果后续把这块内存的指针存在全局变量里，或者多个线程同时操作同一块内存（比如误释放多次），还是会出问题。

• 修复方案：确保每个线程分配的内存都是独立的局部变量，不要用全局指针存储；释放内存时必须保证只有分配它的线程，或者在同步保护后进行释放。

4. JNI对象的跨线程使用风险 #

如果FrameReceived里创建了JNI对象（比如jbyteArray），然后跨线程传递或者存储，JNI对象是和当前JNIEnv绑定的，跨线程使用必然崩溃。

• 修复方案：如果需要跨线程传递数据，要么把数据复制到原生内存（比如malloc的缓冲区），在目标线程里重新创建JNI对象；要么用NewGlobalRef创建全局引用保存JNI对象，但用完必须调用DeleteGlobalRef释放，避免内存泄漏。

• 开启线程安全检测：在CMakeLists.txt里添加编译选项-fsanitize=thread，可以帮你自动检测线程竞争问题，定位具体的风险代码。
• 打印线程ID：在FrameReceived开头用pthread_self()打印当前线程ID，直接确认是不是多个线程在同时调用这个函数，这是判断重入的最直接证据。
• 检查回调触发逻辑：确认FrameReceived是不是由异步回调触发的（比如网络回调、摄像头采集回调），这类回调通常在不同线程执行，是重入问题的高发区。

内容的提问来源于stack exchange，提问作者rosu alin