For those who have read about containers and Docker , but do not understand how Java has latched onto containers. First, let's refresh our memory about Java memory . Let me remind you that memory consists of Stack and Heap, which use the RAM (random access memory) of the server; when speaking further about memory, we will mean RAM. Now let's look at the container in cross-section. No, of course not, we are not interested in the rump and thighs, we will look at the memory structure in the container. It can be divided into three parts: • Heap Memory – the heap itself; • Off Heap is everything that is not in the heap; • OS Overhead is the memory overhead for implementing processes inside the container. Let's say: We have allocated 1 Gb to the container, in the figure it will be Container Limit - its boundaries are indicated by a blue rectangle. We allocated 80%, that is, 0.8 Gb, for Java memory in the container, and Heap took us about 80% of the container, that is, not much less than 0.8 Gb, because OS Overhead took part of the resources (overhead) for maintaining processes. About 20% of the container is left for everything that is not connected to the heap ( Off Heap ). The Used area in the figure shows the used memory area for running the application. Now we need to talk about situations when the memory in the container may run out. OutOfMemoryError If the application's memory consumption ( Used area ) reaches the heap limits ( Heap ), we will catch an OutOfMemoryError (OOM Error) . Which says that there is not enough space in the heap, namely, in the memory area in which objects created programmatically in the application are placed. If it’s not entirely clear yet, I’ll explain it in cats. OOM Error is when a cat screams for a long, long time in front of the doors to the balcony, and when this door is opened, he stands in the doorway and does not go either way, they often say that the cat is frozen. If you push him in time, he will drop his jaw and go to the balcony to do his kitty business. OOM Killer This is another situation that can happen in a container when memory runs out. If a program gets outside the container, we get an OutOfMemory Killer (OOM Killer) - this is a process that terminates the application to save the kernel from crashing. It sacrifices the application to keep the container running. It’s not a fact that the container will fall, but the application that runs in it will definitely fall. This happens if you leave the memory consumption of a Java application uncontrolled. Again on cats. If you decided to sleep longer on Saturday and forgot to give the cats food, then OOM Killerthe flowers are guaranteed, the pots may not be damaged, but the flowers will have to be replanted. What's the difference between OOM Error and OOM Killer? You can process OOM Error and perform some actions (for example: scale the application), and OOM Killer will simply kill the entire process. OOM Killer is similar to kill-9 (kill minus nine) - a command that kills a process in Linux . The thing is that the most popular container implementation is the Docker container, which is based on Linux , even if you run it under Windows , the kernel will still be from Linux . In Linux, we are interested in one concept: CGroups (English control group) - a Linux kernel mechanism that limits and isolates computing resources (processor, network, memory resources, I/O resources) for groups of processes. Simply put, this mechanism allows you to manage resources in a container, in our case memory. How does Java relate to this? It is through the CGroups mechanism that Java can latch on to container memory. But this all depends on the version of Java. For example, Java 7 does not know how to use CGroups , and container limits are unknown to it. By default, maximal heap size = ¼ physical memory. If the application exceeds the container limits, then there will be an OOM Killer , and if the container limits are not set, then the application will take memory from other applications on the server (it is better to set limits, otherwise everyone will lose). You can, of course, use heap settings or use special "images" that solve this problem, but the easiest way is to use the correct version of Java. Correct versions start with Java 8 x131 (ported from Java 9), it starts to understand CGroups . And in Java 10, support for containers appeared: UseContainerSupport , later this function was ported to Java 8 x 191 . Or you can just use Java: 11+ . What can be concluded: When using container memory, you may receive an OutOfMemoryError (OOM Error) or OutOfMemoryKiller (OOM Killer). In the first case, the application will not crash immediately, OOM Error can be caught, processed and controlled actions can be taken. For example, scale the application. If an OOM Killer occurs, the application will crash immediately, and there will be no options left to save it. And the worst thing is that outwardly the container itself will be fine, that is, you may not even suspect that something has fallen there. Linux mechanisms are used to interact with container and Java memory. But not every Java implements them. To avoid problems for Java 8, you need to use a version starting from 131, or better yet, from 191. Or use Java: 11+. For practice: OutOfMemoryError: catch it if you can
No, of course not, we are not interested in the rump and thighs, we will look at the memory structure in the container. It can be divided into three parts: • Heap Memory – the heap itself; • Off Heap is everything that is not in the heap; • OS Overhead is the memory overhead for implementing processes inside the container. 
Let's say: We have allocated 1 Gb to the container, in the figure it will be Container Limit - its boundaries are indicated by a blue rectangle. We allocated 80%, that is, 0.8 Gb, for Java memory in the container, and Heap took us about 80% of the container, that is, not much less than 0.8 Gb, because OS Overhead took part of the resources (overhead) for maintaining processes. About 20% of the container is left for everything that is not connected to the heap ( Off Heap ). The Used area in the figure shows the used memory area for running the application. Now we need to talk about situations when the memory in the container may run out. OutOfMemoryError If the application's memory consumption ( Used area ) reaches the heap limits ( Heap ), we will catch an OutOfMemoryError (OOM Error) . Which says that there is not enough space in the heap, namely, in the memory area in which objects created programmatically in the application are placed. 
If it’s not entirely clear yet, I’ll explain it in cats. OOM Error is when a cat screams for a long, long time in front of the doors to the balcony, and when this door is opened, he stands in the doorway and does not go either way, they often say that the cat is frozen. If you push him in time, he will drop his jaw and go to the balcony to do his kitty business. 
OOM Killer This is another situation that can happen in a container when memory runs out. 
If a program gets outside the container, we get an OutOfMemory Killer (OOM Killer) - this is a process that terminates the application to save the kernel from crashing. It sacrifices the application to keep the container running. It’s not a fact that the container will fall, but the application that runs in it will definitely fall. This happens if you leave the memory consumption of a Java application uncontrolled. Again on cats. If you decided to sleep longer on Saturday and forgot to give the cats food, then OOM Killerthe flowers are guaranteed, the pots may not be damaged, but the flowers will have to be replanted. 
What's the difference between OOM Error and OOM Killer? You can process OOM Error and perform some actions (for example: scale the application), and OOM Killer will simply kill the entire process. OOM Killer is similar to kill-9 (kill minus nine) - a command that kills a process in Linux . 
The thing is that the most popular container implementation is the Docker container, which is based on Linux , even if you run it under Windows , the kernel will still be from Linux . In Linux, we are interested in one concept: CGroups (English control group) - a Linux kernel mechanism that limits and isolates computing resources (processor, network, memory resources, I/O resources) for groups of processes. Simply put, this mechanism allows you to manage resources in a container, in our case memory. How does Java relate to this? It is through the CGroups mechanism that Java can latch on to container memory. But this all depends on the version of Java. For example, Java 7 does not know how to use CGroups , and container limits are unknown to it. By default, maximal heap size = ¼ physical memory. If the application exceeds the container limits, then there will be an OOM Killer , and if the container limits are not set, then the application will take memory from other applications on the server (it is better to set limits, otherwise everyone will lose). You can, of course, use heap settings or use special "images" that solve this problem, but the easiest way is to use the correct version of Java. Correct versions start with Java 8 x131 (ported from Java 9), it starts to understand CGroups . And in Java 10, support for containers appeared: UseContainerSupport , later this function was ported to Java 8 x 191 . Or you can just use Java: 11+ . What can be concluded: When using container memory, you may receive an OutOfMemoryError (OOM Error) or OutOfMemoryKiller (OOM Killer). In the first case, the application will not crash immediately, OOM Error can be caught, processed and controlled actions can be taken. For example, scale the application. If an OOM Killer occurs, the application will crash immediately, and there will be no options left to save it. And the worst thing is that outwardly the container itself will be fine, that is, you may not even suspect that something has fallen there. Linux mechanisms are used to interact with container and Java memory. But not every Java implements them. To avoid problems for Java 8, you need to use a version starting from 131, or better yet, from 191. Or use Java: 11+. For practice: OutOfMemoryError: catch it if you can
GO TO FULL VERSION