Warum verursacht die implementierte Custom Classloader -Implementierung einen Deadlock zwischen Threads? ⇐ Java

[Anonymous]

Jetzt habe ich einen Klassenloader -Loaderx, der von urlClassloader erbt. Dieser Klassenloader implementiert die folgenden Methoden: < /p>

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)
}
}

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>

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 

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?