Supposons que vous ayez un fichier JAR 3 Gb et que votre application n'utilise qu'une petite classe. La JVM charge-t-elle tout le fichier jar en mémoire ou lit-elle la table des matières et ne charge que les pièces dont elle a besoin? Ce comportement est-il contrôlable? JVM charge uniquement les classes requises à partir du JAR lorsqu'il est appelé.La Java JVM charge-t-elle un jar ou une oreille entière si elle n'utilise qu'une seule classe?
Si l'application a besoin d'une classe, la classe et toutes les autres classes dépendantes seront chargées. Pas sûr mais je suppose que c'est la responsabilité du chargeur de classe de localiser la classe du classpath et du load.
Le chargeur de classe par défaut ne charge que ce dont il a besoin, lorsqu'il en a besoin. Si vous avez un JAR de 10 Mo dans votre CLASSPATH et qu'un seul fichier .class est nécessaire, la JVM ne chargera cette classe que la première fois que votre code tentera d'y accéder. Le bytecode .class va dans l'espace perm. Il est «contrôlable» dans le sens où vous pouvez écrire votre propre chargeur de classe, mais cela demande un peu d'expertise.
Cela dépend entièrement de JVM et de classloader. La spécification JVM spécifie que la classe doit apparaître pour être chargée lors de sa première utilisation active. Les chargeurs de classes peuvent charger certaines classes plus tôt que nécessaire en prévision. En réalité, la plupart des chargeurs de classe retardent le chargement le plus longtemps possible.
Les fichiers jar sont une forme de fichiers zip.
Comment ceux-ci sont gérés dépend fortement de JRE.
Anciennes versions de Sun JRE utilisées pour mapper la mémoire du fichier entier. Cela allouerait de la mémoire logique, mais ne provoquerait pas nécessairement le chargement des données à partir du disque. (Windows 32 bits n'est généralement pas capable d'allouer 3 Go de mémoire contiguë, bien que vous puissiez le faire sur d'autres systèmes d'exploitation).
Je crois que le comportement actuel consiste à mapper la mémoire du répertoire central à l'arrière du fichier sous Windows. Sous d'autres systèmes d'exploitation, c'est juste lu. Ceci est contrôlé par #define s dans la source.
JDK7 est susceptible de faire autre chose.
Les classes sont généralement chargées paresseusement. Les ressources sont relues à chaque fois. java.util.ResourceBundle caches.