classloader en java est une classe elle-même alors qui chargera la classe classloader?
ClassLoader en Java est une classe qui est utilisée pour charger des fichiers de classe en Java.
Le java.lang.ClassLoader est une classe abstraite
Ici, ma question est de faire ce java.lang.La classe ClassLoader est de toute façon liée aux classloaders de JVM(1. Chargeur de classe Bootstrap 2. Chargeur de classe extensions 3. Chargeur de classe système)?
Ou ce java.lang.ClassLoader est une classe distincte qui peut être utilisée pour créer un classloader personnalisé?
Les chargeurs de classe sont la partie du Java Environnement d'exécution qui charge dynamiquement les classes Java dans la machine virtuelle Java. Il est responsable de la localisation des bibliothèques, de la lecture du contenu et du chargement des classes contenues dans les bibliothèques Lorsque JVM est démarré, trois chargeurs de classes sont utilisés
-
Chargeur de classe Bootstrap
-
Chargeur de classe extensions
-
Chargeur de classe système
Bootstrap class loader charge les bibliothèques java de base. Il est écrit en code natif. Le chargeur de classe bootstrap est responsable du chargement des classes java clés comme java.lang.Objet et autre code d'exécution en mémoire. Les classes d'exécution sont empaquetées à l'intérieur jre/lib/rt.jar dossier.
Extensions class loader charge le code dans les répertoires d'extensions. Il est implémenté par la classe ExtClassLoader.
System class loader le code trouvé sur java.classe.chemin qui correspond aux variables de chemin de classe système. Il est implémenté par la classe AppClassLoader. Toutes les classes d'utilisateurs par défaut sont chargés par le chargeur de classe système.
Java ClassLoader est hiérarchique et chaque fois qu'une demande est levée pour charger une classe, elle la délègue à son parent et de cette façon l'unicité est maintenue dans l'environnement d'exécution. Si le chargeur de classe parent ne trouve pas la classe la classe chargeur lui-même essaie de charger la classe.
cela signifie donc que le premier chargeur de classe système déléguera la demande au chargeur de classe Extensions qui déléguera la demande au chargeur de classe Bootstrap ici il recherchera la classe si elle n'est pas trouvée, puis Extensions class loader recherchera la classe si elle n'est pas trouvée, puis System class loader recherchera la classe si elle n'est pas trouvée, puis il lancera ClassNotFoundException
La JVM commence-t-elle toujours avec le chargeur de classe système pour la classe de chargement?
Corrigez-moi si je me trompe où
1 answers
Le terme "Chargeur de classe système" est un terme erroné. Comme vous l'avez dit correctement, il est responsable du chargement des classes à partir des emplacements du chemin de classe, qui sont les classes application.
, Comme de Java 8, à la fois, AppClassLoader et ExtClassLoader, sont des sous-classes de java.net.URLClassLoader, qui est une sous-classe de java.security.SecureClassLoader, qui est une sous-classe de java.lang.ClassLoader. Toutes ces classes sont chargées par le chargeur Bootstrap, résolvant le problème de la poule et de l'œuf.
Chaque classe d'exécution a une classe de définition chargeur. Pour les classes définies par le chargeur Bootstrap au démarrage, le chargeur de classe définissant est le chargeur Bootstrap. Lorsque l'initialisation de la JVM est terminée et qu'une tentative de démarrage d'une application est effectuée, le chargeur de classe d'application (alias Chargeur de classe système) sera interrogé pour la classe principale. Le chargeur de classe d'application suivra le modèle de délégation standard interrogeant le parent en premier, de même que le chargeur de classe d'extension et quel que soit le chargeur de classe qui créera la classe sera le chargeur de classe définissant la classe.
Maintenant, lors de la résolution d'une classe référencée par une autre classe ou lorsque Class.forName(String) est invoqué, le chargeur de définition de la classe contenant la référence sera utilisé pour résoudre la classe. Ainsi, lorsque le chargeur de classe d'application a chargé votre classe {[6] } et qu'il contient une référence à javax.swing.JButton, son chargeur de classe définissant, c'est-à-dire le chargeur de classe d'application, sera interrogé pour cette classe, suivez le modèle de délégation pour aboutir à un javax.swing.JButton défini par le Bootstrap loader. Ainsi, les références de classe dans javax.swing.JButton ne sont résolues que via le chargeur Bootstrap, ce qui implique que javax.swing.JButton ne peut pas contenir de référence à votre classe myapp.foo.Bar, car elle n'est pas dans la portée.
Ainsi, la JVM ne pas commence toujours par "System class loader" pour charger une classe, mais uniquement pour résoudre les références de classe des classes définies par elle (ou un chargeur enfant) ou lorsqu'elle est interrogée explicitement, comme lors de la résolution de la classe principale.
Il y a 3ème les chargeurs de classe parti ne suivent pas strictement le modèle de délégation parent, mais indépendamment de la façon dont et du chargeur qu'ils déléguent, il y aura un chargeur de définition pour chaque classe (celui renvoyé par getClassLoader()), qui sera celui utilisé pour résoudre les références dans la classe. La JVM garantit que les noms symboliques identiques au sein d'une classe se résolvent toujours en la même classe d'exécution, quelle que soit la façon dont le chargeur de classe particulier implémente les recherches.
Notez que dans Java 9, l'extension le chargeur de classe a été remplacé par le chargeur de classe de plate-forme. Ce chargeur de classe peut s'écarter de la simple délégation parente, c'est-à-dire qu'il peut déléguer au chargeur de classe d'application pour charger les modules fournis par l'application qui remplacent un module fourni par la plate-forme. De plus, les chargeurs de classe intégrés ne sont plus des sous-classes de URLClassLoader.