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

Question

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

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

有人看过吗？

补充一下，当我不使用 DetachCurrentThread 时根本没有 GC，但 VisualVM 中的线程 View 显示有数百个线程附加到 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 年 3 月 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，因为我希望这些线程返回到我的 native 库。 在那种情况下，我再次附加 native 线程，这可能导致在 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

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

Answer 1

AttachCurrentThread 函数将您的当前 native 线程附加到 JVM Thread 对象。它是必需的，因为 JVM 中的所有操作都发生在线程的上下文中(在 C 端的 JNIEnv 对象中被引用)。

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

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

TLDR:如果您不创建 native 线程，则不需要经常附加/分离。

---

编辑以回应评论

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

执行此操作时，您还需要使用 thread cleanup handler在 native 线程即将结束时调用 DetachCurrentThread。假设您正在使用的库不会对清理堆栈做任何愚蠢的事情，这应该可以防止 Java Thread 对象的泄漏。