1. HotSpot heap memory structure
Now JVMs are basically HotSpot. Next, let's take a look at the structure of the heap memory. HotSpot divides the heap memory into the above three parts, namely: Young Generation, Old Generation, and Permanent Generation. First, let’s talk about the functions of these three parts in general, and then go deeper and deeper. Learning knowledge also needs to be iterated many times in order to understand it better. You can’t eat a big fat man in one bite, which is a digression.
Young Generation
The vast majority of newly created classes are allocated to this area. Since most objects become unreachable soon after they are created, most objects are created in the young generation and then destroyed quickly. The process of destroying objects from the young generation is called Minor GC. (Translation: Small Garbage Collection
Different from the old generation and the persistent generation, the new generation is divided into three parts, namely Eden, S0, S1 in the above figure. Remember these three subsections of the Cenozoic first, which are explained below.
Old Generation
Objects from the young generation are not unreachable, and if they survive, they will be copied to this area. The space occupied by this area is larger than that of the new generation. It is precisely because this space is relatively large that the frequency of GC is much less than that of the new generation. The process of destroying objects from the old age is called Major GC. (Translation: big garbage collection)
Permanent Generation
I love this area because it lasts long! Men are meant to last. . .
This area is also called the method area, where files such as bytecode are stored, and the constant pool is also located in this area. If this area reaches the threshold, a Full GC will be triggered. Full GC will clean up the three areas of the young generation, the old generation and the persistent generation.
Summary: Why is the heap area divided into young generation and old generation? For most applications, there are not many resident objects. Because most of them do not live long, the division of the young generation and the old generation is beneficial to differentiate treatment and reduce the scope of garbage collection. (Most allocated objects are not referenced (considered live) for long, that is, they die young. Few references from older to younger objects exist.)
2. HotSpot memory recycling strategy
The general idea of GC (garbage collection) is to mark live objects → compaction → cleanup → compaction.
New Generation GC (YouGC)
Minor GC acts on the new generation. It can be seen from the above that the new generation is divided into three areas: Eden, S0, and S1. Eden is used to generate new objects, and the other two parts are the rescue area (Survivor Space). These two parts are always converted from From , To's role. First scan Eden, copy the surviving objects to To, if the objects that cannot fit in To are directly copied to the old age; then scan the surviving objects from the From area, if the threshold of survival times is reached, move to the old age, and copy the rest to To area. After this set is completed, the roles of From and To are reversed, maintaining the continuous replication of active objects in the rescue area until they enter OldGen. (From and To correspond to S0 and S1 above)
Old GC (OldGC)
Major GC acts on the old generation. Compared with the high frequency of YouGC in the new generation, Major GC is executed less frequently. The identification process is roughly: identify surviving objects, identify garbage and recycle, then slide objects and compact objects into persistent space.
Summarize the following three or four kinds of memory leaks
- Stack Overflow (StackOverflowError)
- Heap overflow (OutOfMemoryError: java heap space)
- Persistent generation overflow (OutOfMemoryError: PermGen space)
- OutOfMemoryError:unable to create native thread
Stack Overflow StackOverflowError : This kind of error is generally caused by program problems, such as dead recursion. We know that references to basic variables and objects in functions are allocated in stack memory. When a variable is defined in a function, stack memory allocates memory for this variable. When the scope of the variable is exceeded, the GC will release the memory space allocated for the variable. But if the dead recursion never ends, and the local variables generated by each recursion will not be released, because the function is still executing. The final stack is inaccessible and a StackOverflowError is thrown.
Heap overflow OutOfMemoryError: java heap space: heap memory overflow will throw OOME. This problem may be a memory leak or a memory overflow. These two cases are more troublesome, and I am still in the research stage. Dig a hole first, and make up for it after research.
Persistent generation overflow (OutOfMemoryError: PermGen space) : HotSpot jvm implements the method area of the Java virtual machine specification through the persistent generation. This area stores the class object and the constant pool when the program is running. So OutOfMemoryError: PermGen space may be a constant pool overflow, or it may be an overflow caused by the class object not being released in time. The following situations are common:
1. We usually modify the code and save it, and tomcat will perform hot deployment. At this time, OutOfMemoryError: PermGen space is likely to be thrown. This is because the original class object is not unloaded, the new class object is added to the method area, and an exception is thrown when the threshold of the method area is reached.
2 If the application itself is relatively large and involves more class libraries, but the memory we allocate to the persistent band (set by -XX:PermSize and -XX:MaxPermSize) is relatively small, this problem may also occur.
3. Class dynamic generation technology, such as CGLib dynamic proxy, etc., in this case, a larger method area space is required to store dynamically generated class objects.
OutOfMemoryError:unable to create native thread : Literally out of memory: Unable to create new thread. The literal meaning is already obvious, the reasons for this are basically the following 2 points
1. The number of threads created by the program exceeds the limit of the operating system.
2. The JVM occupies too much memory, resulting in too little memory space for creating threads. We all know that the operating system has a limit on the memory of each process. We start JVM, which is equivalent to starting a process. If one of our processes occupies 4G of memory, then the remaining memory calculated by the following formula is to create a thread The memory that can be used when stacking. 线程栈总可用内存=4G-（-Xmx的值）- （-XX:MaxPermSize的值）- 程序计数器占用的内存 From the above formula, we can see that the larger the values of -Xmx and MaxPermSize are, the less space is left for the thread stack. When the stack capacity configured by the -Xss parameter remains unchanged, the number of threads that can be created is also the smaller. So if it is because of this situation unable to create native thread, then either we increase the total memory occupied by the process, or reduce -Xmx or -Xss to create more threads.