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

Posted 2023-02-16

【中文标题】为啥调用 DetachCurrentThread() 会导致过多的垃圾回收？

【英文标题】：Why calling DetachCurrentThread() causes excessive garbage collection?为什么调用 DetachCurrentThread() 会导致过多的垃圾回收？

【发布时间】：2013-03-28 16:09:55

【问题描述】：

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

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

有人看过吗？

只是补充一点，当我不 DetachCurrentThread 时根本没有 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_64 x86_64 x86_64 GNU/Linux

Java：

OpenJDK 运行时环境 (IcedTea6 1.11.5) (6b24-1.11.5-0ubuntu1~12.04.1) OpenJDK 64 位服务器虚拟机（build 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，因为我希望这些线程回到我的本机库。 在那种情况下，我再次附加本机线程，这可能会导致在 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

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

【参考方案1】：

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

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

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

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

---

根据评论进行编辑

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

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

【讨论】：

解释一下。在我的例子中，本地线程是在我的 JNI 库之外创建的，所以我无法控制它们的数量。我注意到当没有太多活动时，只使用 4-5 个本机线程。只有当这里是重负载线程数增长时。奇怪的是，VM 并没有尝试以任何方式重用 JVM Thread 对象。我还注意到，就我而言，当我不分离时，整个应用程序的工作效率更高。显然我迟早需要分离，所以我正在考虑某种本机线程管理器，它可以分离一段时间没有调用 VM 代码的线程。

谢谢帕西法尔。有关我观察到的更多详细信息，请参阅我的更新。感谢有关清理处理程序和 setspecific 的提示