Strong references to inheritedAccessControlContext in java.lang.Thread cause classloader to be leaked about classloader-leak-prevention HOT 2 CLOSED

Did you do preventor.runPreClassLoaderInitiators(); before the script classloader was used the first time (i.e. not just before reload)?

What about the threads that are started - when are they expected to stop?

from classloader-leak-prevention.

The threads comes from pre-defined application thread pools, and they will stop when the application stops.

After adding preventor.runPreClassLoaderInitiators(); before the script classloader was used the first time and each hot loading, I found that -XX:MaxMetaspaceSize (not -XX:MetaspaceSize ) must also be set to trigger gc.
In my case, set -XX:MaxMetaspaceSize to a appropriate value, from 164m to 180m, the metaspace size would reduce upon each hot loading. Though each hot loading will lead to OOM but afterwhile the application worked fine.

set to 164M:

But set -XX:MaxMetaspaceSize to other value finally lead to OOM and the application cannot continue.
set to 256M:

It looks like to reduce the metaspace size after each hot loading there's must a gc triggered, and the gc seems has some relevance with -XX:MaxMetaspaceSize. But the choice of the value is really a mystery.

from classloader-leak-prevention.