Warum verursacht die implementierte Custom Classloader -Implementierung einen Deadlock zwischen Threads?
Posted: 03 Apr 2025, 05:00
Jetzt habe ich einen Klassenloader -Loaderx, der von urlClassloader erbt. Dieser Klassenloader implementiert die folgenden Methoden: < /p>
Hier ist PluginClassloaderManager ein Klassenladermanager, der alle Klassenlader im Programm verwaltet. Aufrufen der Ladeklasse Methode delegiert den Ladevorgang in die LOADCASSNOPARENT -Methode anderer Klassenlader. Führen Sie das Programm aus, ich finde, dass diese Logik möglicherweise zu einem Deadlock führen kann: < /p>
erfasst hat, sollte er logischerweise eine eigene FindClass Logik ausführen und dann eine Klasse zurückgeben (oder eine Ausnahme). Warum sollten zwei Threads auf die Schlösser des anderen warten?
Code: Select all
override fun loadClass(name: String, resolve: Boolean): Class {
try {
return super.loadClass(name, resolve)
} catch (_: ClassNotFoundException) { }
return pluginClassLoaderManager.loadClass(name, this)
}
override fun loadClassNoParent(name: String): Class {
val lock = getClassLoadingLock(name)
synchronized(lock) {
return findLoadedClass(name) ?: findClass(name)
}
}
Code: Select all
"DefaultDispatcher-worker-3@2727" tid=0x24 nid=NA waiting for monitor entry
java.lang.Thread.State: BLOCKED
Blocked by DefaultDispatcher-worker-2@2726
Waiting for DefaultDispatcher-worker-2@2726 to release lock (x.PluginUrlClassLoader)
at x.PluginUrlClassLoader.loadClassNoParent(PluginUrlClassLoader.kt:82)
at x.PluginClassLoaderManager.loadClass(PluginClassLoaderManager.kt:73)
at x.PluginUrlClassLoader.loadClass(PluginUrlClassLoader.kt:76)
at java.lang.ClassLoader.loadClass(ClassLoader.java:526)
"DefaultDispatcher-worker-2@2726" tid=0x23 nid=NA waiting for monitor entry
java.lang.Thread.State: BLOCKED
Blocked by DefaultDispatcher-worker-3@2727
Waiting for DefaultDispatcher-worker-3@2727 to release lock (x.PluginUrlClassLoader)
at x.PluginUrlClassLoader.loadClassNoParent(PluginUrlClassLoader.kt:82)
at xr.PluginClassLoaderManager.loadClass(PluginClassLoaderManager.kt:73)
at x.PluginUrlClassLoader.loadClass(PluginUrlClassLoader.kt:76)
at java.lang.ClassLoader.loadClass(ClassLoader.java:526)
< /code>
Die beiden Threads warten darauf, dass sich gegenseitig Schlösser freigeben, aber ich kann unter welchen Umständen dieser Konflikt nicht herausfinden. Sobald ein Thread eine Sperre