JNI Attach / Detach线程内存管理

Question

我有一个JNI回调：

void callback(Data *data, char *callbackName){
    JNIEnv *env;
    jvm->AttachCurrentThread((void **)&env, NULL);
    /* start useful code*/

    /* end useful code */
    jvm->DetachCurrentThread();
}

当我像这样（空有用的代码）运行它时，会发生内存泄漏。如果我注释掉整个方法，则不会泄漏。连接/分离线程的正确方法是什么？

我的应用程序处理实时声音数据，因此负责数据处理的线程必须尽快完成，以便为下一批做好准备。因此，对于这些回调，我创建了新线程。每秒有数十个甚至数百个它们，它们将自己附加到JVM，调用一个回调函数来重绘图形，分离并消亡。这是做这些事情的正确方法吗？如何处理内存泄漏？

编辑：错别字

好的，我创建了一个最少的代码：

package test;

public class Start
{
    public static void main(String[] args) throws InterruptedException{
        System.loadLibrary("Debug/JNITest");
        start();
    }

    public static native void start();
}

和

#include <jni.h>
#include <Windows.h>
#include "test_Start.h"

JavaVM *jvm;
DWORD WINAPI attach(__in  LPVOID lpParameter);

JNIEXPORT void JNICALL Java_test_Start_start(JNIEnv *env, jclass){
    env->GetJavaVM(&jvm);
    while(true){
        CreateThread(NULL, 0, &(attach), NULL, 0, NULL);
        Sleep(10);
    }
}


DWORD WINAPI attach(__in  LPVOID lpParameter){
    JNIEnv *env;
    jvm->AttachCurrentThread((void **)&env, NULL);
    jvm->DetachCurrentThread();
    return 0;
}

当我运行VisualJM探查器时，我得到了通常的锯齿模式，那里没有泄漏。堆使用量达到5MB左右的峰值。但是，观察进程浏览器确实显示出一些奇怪的行为：内存正在缓慢地上升和上升，在一分钟左右的时间内每秒4K，然后突然所有分配的内存下降。这些丢弃与垃圾回收不对应（它们比发生探查器中的锯齿出现的频率更低，分配的内存更少）。

因此，我最好的选择是这是某些OS行为处理成千上万毫秒的线程。某些大师对此有解释吗？

Answer 1

我发现了问题。它在JNI代码I中悬挂着本地引用

没有破坏。每个回调都会创建一个新的本地引用，因此导致内存泄漏。当我将本地引用转换为全局引用时，所以我可以重复使用，问题就消失了