为什么调用DetachCurrentThread()会导致过多的垃圾回收？

Question

我正在用C代码调用Java方法.每次调用时我都调用AttachCurrentThread,调用完成后调用DetachCurrentThread.

这工作正常,但问题是我看到由此引起的垃圾收集,即几乎每次通过JNI调用.次要集合上的VisualVM图基本上都是绿色的!从本机代码到Java的调用速率是每秒数百.在那些调用期间,我也可以看到创建过多的Java线程,如Thread-34543,Thread-34544,Thread-34545等,这可能是GC的原因.看起来每个调用都是通过不同的线程完成的.

有谁见过这个？

只是在我没有DetachCurrentThread时添加到那里,根本没有GC,但VisualVM中的Thread视图显示连接到VM的数​​百个线程.有小费吗？

JVM设置

-Xms2048m -Xmx2048m -XX:MaxDirectMemorySize = 256M -XX:+ HeapDumpOnOutOfMemoryError -Dfile.encoding = UTF-8 -Dcom.sun.management.jmxremote.ssl = false -Dcom.sun.management.jmxremote.authenticate = false -Dcom. sun.management.jmxremote.port = 3333

平台:Ubuntu 12.04 Linux 3.2.0-35-generic#55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Java的:

OpenJDK运行时环境(IcedTea6 1.11.5)(6b24-1.11.5-0ubuntu1~12.04.1)OpenJDK 64位服务器VM(内置20.0-b12,混合模式)

更新2013-03-30

我认为我的问题出在其他地方.我打印出线程的ID,看起来只有少数线程正在调用我的JNI代码.上次运行显示13个线程.事情就是跑步的时候

if ((*vm)->GetEnv(vm, (void**)&env, JNI_VERSION_1_4) == JNI_OK)
    return env;
else
    return NULL;

获取与当前线程关联的JNIEnv*我得到错误代码-2(JNI_EDETACHED).为了清楚起见我根本没有调用DetachCurrentThread,因为我期望这些线程回到我的本机库.在这种情况下,我再次附加本机线程,这可能导致在JVM中创建过多的线程abject.上次运行显示

 29 [478e](get_env) Thread 2633996032 has env: (nil), err was: -2
 47 [478e](get_env) Thread 2642388736 has env: (nil), err was: -2
 32 [478e](get_env) Thread 2650781440 has env: (nil), err was: -2
 31 [478e](get_env) Thread 2659174144 has env: (nil), err was: -2
 37 [478e](get_env) Thread 2667566848 has env: (nil), err was: -2
 30 [478e](get_env) Thread 2675959552 has env: (nil), err was: -2
 32 [478e](get_env) Thread 2684352256 has env: (nil), err was: -2
 33 [478e](get_env) Thread 2760873728 has env: (nil), err was: -2
 33 [478e](get_env) Thread 2769266432 has env: (nil), err was: -2
 37 [478e](get_env) Thread 2777659136 has env: (nil), err was: -2
 36 [478e](get_env) Thread 2786051840 has env: (nil), err was: -2
 31 [478e](get_env) Thread 2794444544 has env: (nil), err was: -2
 52 [478e](get_env) Thread 3707176704 has env: (nil), err was: -2

其中第一列是附加线程没有与之关联的有效env的调用次数.知道为什么会这样吗？

Answer 1

该AttachCurrentThread函数将当前本机线程附加到JVM Thread对象.这是必需的,因为JVM中的所有操作都发生在线程的上下文中(在JNIEnv对象的C端引用).

如果你的C代码不是多线程的,你不需要调用attach/detach; 只需使用JNIEnv你得到的JNI_CreateJavaVM.如果你有一个有限数量的C线程,那么你可以在本机线程启动时调用attach,并JNIEnv在线程的生命周期中继续使用它(但你必须附加每个 C线程).如果您正在创建大量C线程,那么您没有选择:您必须附加每个线程.

我怀疑"过度"的垃圾收集正在发生,因为JVM使用线程本地分配块:每个Java线程都为其分配提供了一个保留的Eden内存区域(以防止与其他线程的争用).当本机线程被分离时,该TLA有资格进行收集(并且,根据TLA的大小,您可能只是因为您的短暂附加而填充Eden).您可能能够禁用此行为-XX:-UseTLAB,但这可能会导致比解决更多的问题(因为JVM必须在每次分配时锁定其内部状态).

TLDR:如果您没有创建本机线程,则无需经常连接/分离.

编辑以回应评论

我建议缓存JNIEnv指针,并根据需要附加/分离.假设您正在使用PThreads,您可以使用pthread_setspecific将环境指针与当前本机线程相关联.如果从没有环境指针的线程调用代码,则调用AttachCurrentThread并将结果存储在线程中.

执行此操作时,您还需要使用线程清理处理程序DetachCurrentThread在本机线程即将死亡时调用.假设您正在使用的库对清理堆栈没有做任何愚蠢的事情,这应该可以防止Java Thread对象的泄漏.