Ich erstelle einen URLClassloader, um einige Gläser zu laden. Jedes JAR wird korrekt von einem anderen Klassenlader geladen und jedes JAR enthält eine Klasse mit einer Methode run (). Jetzt kann der Rumpf von run () eine anonyme innere Klasse darin erzeugen. Da ich meinen URLClassloader jedoch in einem try-with-resources-Block erstellt habe, wird er autoclosed und zur Laufzeit, wenn er versucht, die anonyme innere Klasse zu laden, wirft er einen NoClassDefFoundError, weil der Classloader bereits geschlossen ist.
Nun ist meine Frage, was ist die normale Praxis für diese Situationen? ist es in Ordnung, den Classloader offen zu lassen, damit er später etwas anderes laden kann? Gibt es eine Möglichkeit, einen geschlossenen Classloader wieder zu öffnen?
Wenn ich den Classloader offen lasse, gibt der Compiler Warnungen über potentielle Ressourcenlecks ab , also habe ich das Gefühl, dass dies wie Streams ist, wo man sie nicht unbegrenzt offen lassen soll . Aufgrund der Eigenschaften von Klassenladeprogrammen kann jedoch nicht derselbe Klassenlader die anonyme Klasse laden, er kann nicht in der äußeren Klasse verwendet werden.
Hier ist der Code, in dem der Klassenlader erstellt wird
%Vor%Die Lebensdauer eines Klassenladeprogramms sollte mindestens der Lebensdauer der Instanzen der Klassen entsprechen, die damit geladen werden. Solange sie und ihre Klassen nicht zur Garbage-Collection berechtigt sind, ist auch ihr Class Loader nicht geeignet. Und wenn sie zusätzlichen Code oder Ressourcen laden müssen, müssen Sie den Klassenlader öffnen.
Wenn Sie also mit einem Player fertig sind, sollten Sie den Klassenlader schließen.
Anstatt für jeden Player einen neuen Classloader zu erstellen, könnten Sie ein Factory-Pattern (oder etwas Ähnliches) verwenden:
%Vor%wo die Factory die Verweise auf die Klassenlader beibehält (so sind die Klassen nicht verwaist). Dann haben Sie die Möglichkeit, die Fabrik bei Bedarf herunterzufahren, um die Klassenlader zu schließen.
Tags und Links java classloader