Análisis de puntos clave: el principio de funcionamiento del acelerador de clases java

Cuando se trata de la ejecución de código Java, los estudiantes que han estado expuestos al código Java definitivamente pensarán en: escribir, compilar y ejecutar estas tres etapas. Entre ellas:

Escritura: escriba el código fuente en un archivo con el sufijo .java de acuerdo con las reglas gramaticales de Java.

Compilación: compile archivos .java (archivos de código fuente) en archivos .class (archivos de código byte).

Ejecutar: el archivo de código de bytes .class se ejecuta a través de la JVM.

Explique en la lengua vernácula: Los archivos .Java son archivos que los programadores pueden entender, pero las computadoras no pueden entender. Deben convertirse en archivos .class antes de que la computadora pueda reconocerlos y ejecutarlos. Aunque estas tres etapas pueden ser implementadas por IDE, pero muchas la gente tiende a pasar por alto un detalle, es decir: antes de que la JVM ejecute el archivo de código de bytes .class, el archivo de código de bytes debe cargarse en la memoria a través del "cargador de clases", y este proceso es el que debemos detallar. Tema para hablar acerca de.

Este artículo presentará el cargador de clases "Java" a partir de los siguientes 3 puntos:

1. Una descripción general de los cargadores de clases.

2. Clasificación de cargadores de clases.

3. Mecanismo de carga de clases.

En primer lugar, hablemos de la descripción general del cargador de clases. El cargador de clases (ClassLoader) es responsable de cargar los objetos de la clase, es decir, de cargar el archivo .class bytecode en la memoria JVM. Entonces, ¿cuándo irá? ¿Qué pasa con la carga de un archivo de código de bytes .class? La respuesta es: cuando un programa Java utiliza el contenido de una determinada clase por primera vez, y el archivo de código de bytes de esta clase no existe en la memoria, el cargador de clases cargará la clase. archivo de código de bytes. 

Como dice el refrán, "cruzar a las personas primero, cruzarse a sí mismo", si quieres ser un modelo a seguir para los demás, primero debes ser tú mismo. Este es el caso en la vida, lo mismo ocurre con el cargador de clases. Para cargar nuestra costumbre class, class loader primero debe completar el proceso de "autocarga" Después de hablar de esto, tengo que mencionar la "clasificación de class loader".

Los cargadores de clases en Java se dividen principalmente en las siguientes cuatro categorías:

1. El cargador de clases raíz (BootStrapClassLoader) es el principal responsable de cargar los archivos de código de bytes relacionados con jre / lib / rt.jar.

2. Cargador de clases de extensión (ExtensionClassLoader), la carga principal carga estos paquetes jar jre / lib / ext / *. Jar. Este cargador de clases fue renombrado en JDK1.9: Platform Class Loader, su cargador de clases padre es: null.

3. Application ClassLoader (ApplicationClassLoader), principalmente responsable de cargar clases definidas por el usuario y paquetes jar configurados por variables de entorno classpath Este cargador de clases fue renombrado en JDK1.9: System ClassLoader, su clase padre cargando El dispositivo es: ExtensionClassLoader.

4. El cargador de clases personalizado (UserClassLoader) es responsable de cargar archivos de código de bytes en el directorio especial especificado por el programador. En la mayoría de los casos, el cargador de clases personalizado solo necesita heredar la clase abstracta ClassLoader y anular findClass () y loadClass () dos métodos.

Como se muestra abajo:

1568796699124047.png

En este punto, creo que todos tienen un conocimiento preliminar y una comprensión del cargador de clases. A continuación, escribimos el código para verificarlo, el código y los resultados de la impresión son los siguientes:

1568796719787137.png

En este punto, el código ha sido verificado. De hecho, lo que hemos estado estudiando es el "orden de carga" del mecanismo de carga de la clase JVM. Ahora, estudiemos su "orden de verificación". Piense en ello, suponga: D: compile, ext * .jar, rt.jar tienen A.class en las tres categorías, entonces A.class se cargará 3 veces, si no, ¿cuál es su orden de carga?

La respuesta es: no se cargará 3 veces, y BootStrapClassLoader eventualmente cargará A.class. 

La razón es que antes de que se cargue el cargador de clases APPClassLoader (en lo sucesivo: aplicación), primero preguntará si se carga el cargador de clases ExtClassLoader (en lo sucesivo denominado: ext). Si se carga el ext, la aplicación no De lo contrario, se cargará la aplicación. De manera similar, antes de cargar ext, también preguntará si el cargador de clases BootStrapClassLoader (en adelante, bootstrap) está cargado. Si se carga bootstrap, ext no se cargará, de lo contrario, ext. Este es también el "mecanismo de delegación padre del mecanismo de carga de clases JVM" ".  

Por último, hablemos del "mecanismo de carga de clases". Hay tres tipos principales de mecanismos de carga de clases en la JVM:

1. Carga completa. Como su nombre lo indica, cuando un determinado cargador de clases carga un determinado archivo .class, también se cargará de forma predeterminada junto con el .class del que depende el archivo (a menos que la declaración explícita se cargue a través de una clase específica cargador).

2. Mecanismo de caché. Es decir, todos los archivos .class que haya cargado el cargador de clases se guardarán en el caché. La próxima vez que se utilice el archivo .class, la JVM lo buscará primero en el caché. Si no , cargará el archivo de código de bytes especificado, por eso, cuando cambia el archivo de código de bytes, debe reiniciar la JVM para ver el efecto de modificación.

3. Delegación de los padres. Explica en la lengua vernácula, el hijo (App) quiere estrellas, y no puede lograrlo solo, le pide a su padre (Ext) que se lo pida. Si su padre puede lograrlo, le dará Si no puede lograrlo, encontrará a su abuelo (BootStrap) Sí, diga: Tu nieto quiere las estrellas en el cielo. Si su abuelo puede lograrlo, dáselo. Si no puede lograrlo. , le dirá a su padre (Ext) y dejará que su hijo (App) lo haga solo Esta situación es un poco Extremadamente, si no hay nadie cargado, el programa reportará un error y se lanzará una excepción.

Resumen: el cargador de clases comprueba de arriba a abajo (Aplicación -> Ext -> BootStrap) y se carga de abajo hacia arriba (BootStrap -> Ext -> Aplicación).

 

Supongo que te gusta

Origin blog.csdn.net/cz_00001/article/details/112183643
Recomendado
Clasificación