为什么调用DetachCurrentThread（）会导致垃圾收集过多？

Question

我从C代码中调用Java方法。每次调用时，我调用AttachCurrentThread，调用后，我调用DetachCurrentThread。

这可以很好地工作，但问题是，我看到了由此导致的ECSESSIVE垃圾收集，即几乎每个通过JNI的调用。VisualVM图形上的小集合基本上都是绿色的！从本机代码到Java的调用速率是每秒数百次。在调用过程中，我还可以看到创建了过多的Java线程，如Thread-34543、Thread-34544、Thread-34545等。这可能是GC的原因。看起来每个调用都是通过不同的线程完成的。

有人看过这个吗？

此外，当我不拆卸CurrentThread时，根本没有GC，但VisualVM中的线程视图显示了数百个连接到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\u 64 x86\u 64 GNU/Linux

Java：

OpenJDK运行时环境（IcedTeas6 1.11.5) (6b24-1.11.5-0ubuntu1~12.04.1）OpenJDK 64位服务器VM（build 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\u已附加）。需要明确的是，我根本不调用DetachCurrentThread，因为我希望这些线程回到我的原生库。在这种情况下，我再次附加本机线程，这可能会导致在JVM中创建过多的线程对象。上次跑步显示

 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

AttachMONtThread函数将您当前的本机线程附加到JVMThread对象。这是必要的，因为JVM中的所有操作都发生在线程的上下文中（在JNIEnv对象的C端引用）。

如果您的C代码不是多线程的，您不需要调用附加/分离；只需使用从JNI_CreateJavaVM获得的JNIEnv。如果您的C线程数量有限，那么您可以在本机线程启动时调用附加，并在线程生命周期内继续使用相同的JNIEnv（但您必须附加每个C线程）。如果您要创建大量C线程，那么您别无选择：您必须附加每个线程。

我怀疑发生“过度”垃圾收集是因为JVM使用线程本地分配块：每个Java线程都有一个Eden内存的保留区域用于分配（以防止与其他线程争用）。当本机线程被分离时，该TLA有资格被收集（并且，根据TLA的大小，由于您的短期附加，您可能只是用它们填充Eden）。您可以使用-XX：-UseTLAB禁用此行为，但这可能会导致比它解决的问题更多的问题（因为JVM必须在每次分配时锁定其内部状态）。

TLDR：如果不创建本机线程，则不需要经常附加/分离。

根据评论进行编辑

我建议缓存JNIEnv指针，并根据需要附加/分离。假设您使用的是pthread，那么可以使用pthread\u setspecific将环境指针与当前本机线程相关联。如果从没有环境指针的线程调用代码，请调用AttachCurrentThread并将结果存储到线程中。

执行此操作时，您还需要使用线程清理处理程序在本机线程即将死亡时调用DetachMONtThread。假设您使用的库不会对清理堆栈做任何愚蠢的事情，这应该可以防止JavaThread对象的泄漏。