This is an automated email from the ASF dual-hosted git repository.
morningman pushed a commit to branch branch-3.0
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/branch-3.0 by this push:
new 486fb5be5e1 [fix](jvm)fix jvm metrics memory leak. (#44218)
486fb5be5e1 is described below
commit 486fb5be5e1471377c3d0c1cdd8ba82140bfcb7e
Author: daidai <[email protected]>
AuthorDate: Tue Nov 19 16:59:56 2024 +0800
[fix](jvm)fix jvm metrics memory leak. (#44218)
### What problem does this PR solve?
fix jvm metrics memory leak.before pr #42507
when you set `enable_jvm_monitor=true` in be.conf, you can find that be
jvm memory is slowly growing.
By analyzing the hprof file, we can find that there are a large number
of `java.lang.management.ThreadInfo` objects.
The specific cause of the memory leak is: jni does not manually delete
the local reference after getting the object from the array, resulting
in the object not being GC.
---
be/src/util/jvm_metrics.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/be/src/util/jvm_metrics.cpp b/be/src/util/jvm_metrics.cpp
index 4cb71f5e827..b1089ef4136 100644
--- a/be/src/util/jvm_metrics.cpp
+++ b/be/src/util/jvm_metrics.cpp
@@ -485,8 +485,8 @@ Status JvmStats::refresh(JvmMetrics* jvm_metrics) const {
jvm_metrics->jvm_thread_count->set_value(threadCount < 0 ? 0 :
threadCount);
for (int i = 0; i < threadCount; i++) {
- JNI_CALL_METHOD_CHECK_EXCEPTION(jobject, threadInfo, env,
-
GetObjectArrayElement((jobjectArray)threadInfos, i));
+ JNI_CALL_METHOD_CHECK_EXCEPTION_DELETE_REF(
+ jobject, threadInfo, env,
GetObjectArrayElement((jobjectArray)threadInfos, i));
if (threadInfo == nullptr) {
continue;
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
