Para aquellos que han leído sobre contenedores y Docker , pero no entienden cómo Java se ha acoplado a los contenedores. Primero, refresquemos nuestra memoria sobre la memoria Java . Permítanme recordarles que la memoria consta de Stack y Heap, que utilizan la RAM (memoria de acceso aleatorio) del servidor; cuando hablemos más de memoria, nos referiremos a RAM. Ahora miremos el contenedor en sección transversal. No, claro que no, no nos interesan la grupa y los muslos, miraremos la estructura de la memoria en el contenedor. Se puede dividir en tres partes: • Memoria del montón: el montón en sí; • Fuera del montón es todo lo que no está en el montón; • La sobrecarga del sistema operativo es la sobrecarga de memoria para implementar procesos dentro del contenedor. Digamos: Hemos asignado 1 Gb al contenedor, en la figura será Límite del contenedor ; sus límites están indicados por un rectángulo azul. Asignamos el 80%, es decir, 0,8 Gb, a la memoria Java en el contenedor, y Heap nos tomó alrededor del 80% del contenedor, es decir, no mucho menos de 0,8 Gb, porque OS Overhead se llevó parte de los recursos (overhead). para el mantenimiento de procesos. Aproximadamente el 20% del contenedor se deja para todo lo que no está conectado al montón ( Off Heap ). El área Usado en la figura muestra el área de memoria utilizada para ejecutar la aplicación. Ahora tenemos que hablar de situaciones en las que la memoria del contenedor puede agotarse. OutOfMemoryError Si el consumo de memoria de la aplicación ( área utilizada ) alcanza los límites del montón ( Heap ), detectaremos un OutOfMemoryError (error OOM) . Lo que dice que no hay suficiente espacio en el montón, es decir, en el área de memoria en la que se colocan los objetos creados mediante programación en la aplicación. Si aún no está del todo claro, lo explicaré en gatos. El error OOM es cuando un gato grita mucho, mucho tiempo frente a las puertas del balcón, y cuando se abre esta puerta, se queda en la entrada y no va en ninguna dirección, suelen decir que el gato está congelado. Si lo empujas a tiempo, se quedará boquiabierto e irá al balcón a hacer sus necesidades como gatito. OOM Killer Esta es otra situación que puede ocurrir en un contenedor cuando la memoria se agota. Si un programa sale del contenedor, obtenemos un OutOfMemory Killer (OOM Killer) : este es un proceso que finaliza la aplicación para evitar que el kernel falle. Sacrifica la aplicación para mantener el contenedor en funcionamiento. No es un hecho que el contenedor se caiga, pero la aplicación que se ejecuta en él definitivamente se caerá. Esto sucede si dejas sin control el consumo de memoria de una aplicación Java. De nuevo sobre los gatos. Si decidiste dormir más el sábado y te olvidaste de darles comida a los gatos, entonces OOM Killerlas flores están garantizadas, las macetas no podrán dañarse, pero habrá que replantar las flores. ¿Cuál es la diferencia entre error OOM y OOM Killer? Puede procesar el error OOM y realizar algunas acciones (por ejemplo: escalar la aplicación), y OOM Killer simplemente finalizará todo el proceso. OOM Killer es similar a kill-9 (kill menos nueve): un comando que finaliza un proceso en Linux . El caso es que la implementación de contenedor más popular es el contenedor Docker, que está basado en Linux , incluso si lo ejecutas en Windows , el kernel seguirá siendo de Linux . En Linux, estamos interesados en un concepto: CGroups (grupo de control en inglés): un mecanismo del kernel de Linux que limita y aísla los recursos informáticos (procesador, red, recursos de memoria, recursos de E/S) para grupos de procesos. En pocas palabras, este mecanismo le permite administrar recursos en un contenedor, en nuestro caso la memoria. ¿Cómo se relaciona Java con esto? Es a través del mecanismo CGroups que Java puede adherirse a la memoria del contenedor. Pero todo esto depende de la versión de Java. Por ejemplo, Java 7 no sabe cómo utilizar CGroups y desconoce los límites de los contenedores. De forma predeterminada, el tamaño máximo del montón = ¼ de memoria física. Si la aplicación excede los límites del contenedor, habrá un OOM Killer , y si los límites del contenedor no están establecidos, la aplicación tomará memoria de otras aplicaciones en el servidor (es mejor establecer límites, de lo contrario todos perderán). . Por supuesto, puede utilizar la configuración del montón o utilizar "imágenes" especiales que resuelvan este problema, pero la forma más sencilla es utilizar la versión correcta de Java. Las versiones correctas comienzan con Java 8 x131 (portado de Java 9), comienza a comprender CGroups . Y en Java 10 apareció soporte para contenedores: UseContainerSupport , posteriormente esta función fue portada a Java 8 x 191 . O simplemente puedes usar Java: 11+ . Qué se puede concluir: Al utilizar la memoria del contenedor, es posible que reciba un OutOfMemoryError (error OOM) o un OutOfMemoryKiller (OOM Killer). En el primer caso, la aplicación no fallará inmediatamente, se puede detectar el error OOM, procesarlo y tomar acciones controladas. Por ejemplo, escale la aplicación. Si ocurre un OOM Killer, la aplicación fallará inmediatamente y no quedarán opciones para guardarla. Y lo peor es que exteriormente el propio contenedor estará bien, es decir, es posible que ni siquiera sospeches que algo ha caído allí. Los mecanismos de Linux se utilizan para interactuar con el contenedor y la memoria Java. Pero no todos los Java los implementan. Para evitar problemas con Java 8, es necesario utilizar una versión a partir de la 131, o mejor aún, a partir de la 191. O utilizar Java: 11+. Para practicar: OutOfMemoryError: atrápalo si puedes
No, claro que no, no nos interesan la grupa y los muslos, miraremos la estructura de la memoria en el contenedor. Se puede dividir en tres partes: • Memoria del montón: el montón en sí; • Fuera del montón es todo lo que no está en el montón; • La sobrecarga del sistema operativo es la sobrecarga de memoria para implementar procesos dentro del contenedor. 
Digamos: Hemos asignado 1 Gb al contenedor, en la figura será Límite del contenedor ; sus límites están indicados por un rectángulo azul. Asignamos el 80%, es decir, 0,8 Gb, a la memoria Java en el contenedor, y Heap nos tomó alrededor del 80% del contenedor, es decir, no mucho menos de 0,8 Gb, porque OS Overhead se llevó parte de los recursos (overhead). para el mantenimiento de procesos. Aproximadamente el 20% del contenedor se deja para todo lo que no está conectado al montón ( Off Heap ). El área Usado en la figura muestra el área de memoria utilizada para ejecutar la aplicación. Ahora tenemos que hablar de situaciones en las que la memoria del contenedor puede agotarse. OutOfMemoryError Si el consumo de memoria de la aplicación ( área utilizada ) alcanza los límites del montón ( Heap ), detectaremos un OutOfMemoryError (error OOM) . Lo que dice que no hay suficiente espacio en el montón, es decir, en el área de memoria en la que se colocan los objetos creados mediante programación en la aplicación. 
Si aún no está del todo claro, lo explicaré en gatos. El error OOM es cuando un gato grita mucho, mucho tiempo frente a las puertas del balcón, y cuando se abre esta puerta, se queda en la entrada y no va en ninguna dirección, suelen decir que el gato está congelado. Si lo empujas a tiempo, se quedará boquiabierto e irá al balcón a hacer sus necesidades como gatito. 
OOM Killer Esta es otra situación que puede ocurrir en un contenedor cuando la memoria se agota. 
Si un programa sale del contenedor, obtenemos un OutOfMemory Killer (OOM Killer) : este es un proceso que finaliza la aplicación para evitar que el kernel falle. Sacrifica la aplicación para mantener el contenedor en funcionamiento. No es un hecho que el contenedor se caiga, pero la aplicación que se ejecuta en él definitivamente se caerá. Esto sucede si dejas sin control el consumo de memoria de una aplicación Java. De nuevo sobre los gatos. Si decidiste dormir más el sábado y te olvidaste de darles comida a los gatos, entonces OOM Killerlas flores están garantizadas, las macetas no podrán dañarse, pero habrá que replantar las flores. 
¿Cuál es la diferencia entre error OOM y OOM Killer? Puede procesar el error OOM y realizar algunas acciones (por ejemplo: escalar la aplicación), y OOM Killer simplemente finalizará todo el proceso. OOM Killer es similar a kill-9 (kill menos nueve): un comando que finaliza un proceso en Linux . 
El caso es que la implementación de contenedor más popular es el contenedor Docker, que está basado en Linux , incluso si lo ejecutas en Windows , el kernel seguirá siendo de Linux . En Linux, estamos interesados en un concepto: CGroups (grupo de control en inglés): un mecanismo del kernel de Linux que limita y aísla los recursos informáticos (procesador, red, recursos de memoria, recursos de E/S) para grupos de procesos. En pocas palabras, este mecanismo le permite administrar recursos en un contenedor, en nuestro caso la memoria. ¿Cómo se relaciona Java con esto? Es a través del mecanismo CGroups que Java puede adherirse a la memoria del contenedor. Pero todo esto depende de la versión de Java. Por ejemplo, Java 7 no sabe cómo utilizar CGroups y desconoce los límites de los contenedores. De forma predeterminada, el tamaño máximo del montón = ¼ de memoria física. Si la aplicación excede los límites del contenedor, habrá un OOM Killer , y si los límites del contenedor no están establecidos, la aplicación tomará memoria de otras aplicaciones en el servidor (es mejor establecer límites, de lo contrario todos perderán). . Por supuesto, puede utilizar la configuración del montón o utilizar "imágenes" especiales que resuelvan este problema, pero la forma más sencilla es utilizar la versión correcta de Java. Las versiones correctas comienzan con Java 8 x131 (portado de Java 9), comienza a comprender CGroups . Y en Java 10 apareció soporte para contenedores: UseContainerSupport , posteriormente esta función fue portada a Java 8 x 191 . O simplemente puedes usar Java: 11+ . Qué se puede concluir: Al utilizar la memoria del contenedor, es posible que reciba un OutOfMemoryError (error OOM) o un OutOfMemoryKiller (OOM Killer). En el primer caso, la aplicación no fallará inmediatamente, se puede detectar el error OOM, procesarlo y tomar acciones controladas. Por ejemplo, escale la aplicación. Si ocurre un OOM Killer, la aplicación fallará inmediatamente y no quedarán opciones para guardarla. Y lo peor es que exteriormente el propio contenedor estará bien, es decir, es posible que ni siquiera sospeches que algo ha caído allí. Los mecanismos de Linux se utilizan para interactuar con el contenedor y la memoria Java. Pero no todos los Java los implementan. Para evitar problemas con Java 8, es necesario utilizar una versión a partir de la 131, o mejor aún, a partir de la 191. O utilizar Java: 11+. Para practicar: OutOfMemoryError: atrápalo si puedes
GO TO FULL VERSION