El recolector de basura es un proceso de baja prioridad que se ejecuta periódicamente y libera memoria utilizada por objetos que ya no son necesarios. El recolector de basura se ejecuta en segundo plano, en paralelo con el programa, en un hilo separado. La base de la recolección de basura no es el recuento de referencias, sino la separación de objetos en dos tipos: alcanzables e inalcanzables. Un objeto se considera accesible (vivo) si otro objeto accesible (vivo) hace referencia a él. La accesibilidad se cuenta a partir de hilos. Los subprocesos en ejecución siempre se consideran accesibles (vivos), incluso si nadie hace referencia a ellos. Todos los objetos en Java se almacenan en un área de memoria especial llamada montón. Todos los objetos de los programas se pueden dividir en dos tipos: relativamente hablando, objetos simples y objetos "de larga duración". Los objetos “de larga duración” son aquellos que han sobrevivido a muchas recolecciones de basura. La mayoría de las veces existirán hasta el final del programa. Como resultado, el montón común, donde se almacenan todos los objetos creados, se dividió en varias partes. La primera parte tiene un nombre hermoso: Edén (el “Jardín del Edén” bíblico), los objetos van aquí después de su creación. Es en esta parte donde se asigna memoria para nuevos objetos cuando escribimos nuevos. Se pueden crear muchos objetos y, cuando se acaba el espacio en esta área, comienza la primera recolección de basura "rápida". Hay que decir que el recolector de basura es muy inteligente y elige un algoritmo de trabajo dependiendo de lo que haya más en el montón: basura u objetos de trabajo. Si casi todos los objetos son basura, el recolector marca los objetos "vivos" y los mueve a otra área de memoria, después de lo cual el área actual se limpia por completo. Si hay poca basura y la mayor parte está ocupada por objetos vivos, marca la basura, la limpia y ordena los objetos restantes. El área de memoria donde se transfieren todos los objetos que sobreviven al menos a una recolección de basura se llama Survival Space. Survival Space, a su vez, se divide en generaciones. A cada objeto se le asigna una generación en función de cuántas recolecciones de basura ha experimentado. Si lo hay, pertenece a la “Generación 1”, si es 5, a la “Generación 5”. Juntos, Eden y Survival Space forman un área llamada Young Generation. Además de la Generación Joven, hay otra área de memoria en el montón: la Generación Vieja (“vieja generación”). Estos son objetos de muy larga vida que han sobrevivido a muchas recolecciones de basura. Es más rentable almacenarlos por separado de todos los demás. Y sólo cuando el área de Vieja Generación esté llena, es decir. Incluso si hay tantos objetos de larga duración en el programa que no hay suficiente memoria, se realiza una recolección de basura completa. Procesa no sólo un área de memoria, sino en general todos los objetos creados por la máquina Java. Naturalmente, requiere mucho más tiempo y recursos. Por eso se decidió almacenar por separado los objetos de larga vida. Cuando en otras zonas se acaba el espacio, se realiza la llamada “recolección rápida de basura”. Cubre una sola zona, por lo que es más económico y rápido. Al final, Cuando incluso la zona de los residentes más longevos ya está atascada, entra en juego la limpieza completa. Por lo tanto, el ensamblador utiliza la herramienta más "pesada" sólo cuando ya no es necesaria.
2. ¿Qué tipos de recolectores de basura existen?
Java tiene siete tipos de recolectores de basura:
Recolector de basura en serie
Recolector de basura paralelo
Recolector de basura CMS
Recolector de basura G1
Recolector de basura Épsilon
recolector de basura Z
Recolector de basura de Shenandoah
3. ¿Qué son las “generaciones” de objetos?
Todos los objetos en Survival Space están divididos en generaciones. A cada objeto se le asigna una generación en función de cuántas recolecciones de basura ha experimentado. Si lo hay, pertenece a la “Generación 1”, si es 5, a la “Generación 5”.
4. ¿Para qué se utiliza SoftReference?
Un objeto al que se hace referencia solo mediante referencias suaves puede ser recolectado como basura si el programa se queda sin memoria. Si un programa se queda repentinamente sin memoria, antes de lanzar una excepción OutOfMemoryException, el recolector de basura eliminará todos los objetos a los que hacen referencia los enlaces blandos e intentará asignar memoria al programa nuevamente. Un objeto que sólo SoftReference evita que muera puede sobrevivir a cualquier número de recolecciones de basura y lo más probable es que sea destruido si el programa se queda sin memoria.
5. Ejemplo de uso de SoftReference
SoftReferences fueron diseñados específicamente para el almacenamiento en caché. Supongamos que un programa cliente solicita con frecuencia varios datos de un programa servidor. Luego, el programa del servidor puede almacenar en caché algunos de ellos, utilizando SoftReference para ello. Si los objetos que las referencias suaves evitan que mueran ocupan la mayor parte de la memoria, entonces el recolector de basura simplemente los eliminará y listo.
6. Ejemplo de uso de WeakReference
Si solo hay referencias débiles a un objeto, entonces este objeto está vivo, pero será destruido durante la próxima recolección de basura. Un objeto que WeakReference evita que muera solo no sobrevivirá a la siguiente recolección de basura. Pero hasta que eso suceda, puedes obtenerlo llamando a un método get()en WeakReference y llamando a sus métodos o haciendo otra cosa. Un ejemplo de uso de WeakReference es WeakHashMap.
7. Por qué se necesita WeakHashMap
WeakHashMap es un HashMap cuyas claves son referencias débiles: WeakReference. Almacena pares de objetos en un WeakHashMap: una clave y un valor. Pero WeakHashMap no hace referencia a las claves directamente, sino a través de WeakReference. Por lo tanto, cuando los objetos utilizados como claves se vuelven inalcanzables, serán destruidos durante la siguiente recolección de basura. Esto significa que sus valores se eliminarán automáticamente del WeakHashMap. WeakHashMap es muy conveniente para almacenar información adicional para algunos objetos. En primer lugar, es muy fácil de obtener si utiliza el propio objeto como clave. En segundo lugar, si un objeto se destruye, tanto él como todos los datos asociados con él desaparecerán del HashMap. Por ejemplo, el programa tiene un hilo que monitorea el trabajo de algunos objetos de tareas y escribe información sobre ellos en el registro. Entonces este hilo puede almacenar los objetos rastreados en dicho WeakHashMap. Tan pronto como los objetos ya no sean necesarios, el recolector de basura los eliminará y las referencias a ellos desde WeakHashMap se eliminarán automáticamente.
8. ¿Qué es un registrador?
Un objeto Logger se utiliza para registrar mensajes para un sistema o componente de aplicación específico. Un registro es una lista de eventos que ocurrieron. La mayoría de las veces, se escribe en el registro información sobre los parámetros del método con el que se llamó, todos los errores interceptados y mucha información intermedia. Todo el proceso de registro consta de tres partes.
La primera parte es la recopilación de información.
La segunda parte es filtrar la información recopilada.
La tercera parte es un registro de la información seleccionada.
9. Cómo configurar un registrador
Agregue dependencia a pom.xml.
Agregue el archivo log4j.properties a los recursos.
Normalmente, la configuración del registrador log4j se establece en el archivo log4j.properties. En este archivo puede especificar varios apéndices: objetos en los que se escribirán los datos.
Añadir a clase con lógica empresarial private static final Logger log = Logger.getLogger(ххх.class);.
GO TO FULL VERSION