Java – how to identify the cause of JNI global reference memory leak?

I am using Tomcat and still refer to the classloader instance of my web application after stopping my web application

I took a stack and realized that it was held by a JNI global reference, which prevented the class loader from being garbage collected

My application does not use JNI I also don't use Apache Tomcat native library I am using sun / Oracle JDK I want to track the cause / origin of this global reference (my guess is that the JVM references the classloader internally – but why / where?)

Question:

What methods / toolsets can be implemented?

UPDATE

It seems that bestsss is correct. JNI global reference has been introduced by JVM debugging mode It helped me, but it didn't answer the question, so I still answered questions that might help in the future

Solution

In addition to the obvious situation, there is another thread:

Do you use the application in debug mode?

The JVM does not support any classloader references except the system, but it does not involve you The remaining JNI references are objects held by threads or debugging (if you don't use JNI and lock the object yourself)

JNI references are just roots, edit your answers, and publish the objects held by these references