Interviewer: Tell me about how your online JVM is optimized? I accidentally chatted for 2 hours! !
What does the memory model of JVM look like? When can the object be recovered? What are the common garbage collector algorithms, and what are their advantages and disadvantages? When will the subject enter the old age? What is the space allocation guarantee strategy? How to optimize and reduce Full
GC?Faced with this large wave of JVM interview questions, do you really Hold live?
The important knowledge points are written out here, whether it is core knowledge points or interview questions, so that everyone has a basic outline of the knowledge framework.
At the same time, 283 pages of PDF documents are also organized, which are also the core knowledge points of Java.
Friends in need can, click here to receive! ! ! , The code is: CSDN
What does the JVM memory model look like?
The JVM memory model can be roughly divided into a thread private area and a shared area. The thread private area is composed of a virtual machine stack, a local method stack, and a program counter, and the shared area is composed of a heap and a metadata space (method area).
If someone asks you about the memory model of the JVM, recall the picture above, but it’s still not good to know the memory model of the JVM. You also need to know what they do.
Virtual machine stack/local method stack
When you encountered the exception of StackOverflowException, did you think about why such an exception occurred? The answer lies in the virtual machine stack. The JVM generates a stack frame for each method and then pushes the stack frame into the virtual machine stack.
For example, if the JVM parameter -Xss is set to 1m, if a 128kb array is created in a method, then this method can only recurse 4 times in the same thread, and the fifth time it will recurse, it will report StackOverflowException. , Because the size of the virtual machine stack is only 1m, each recursion needs to allocate 128kb of space in the virtual machine stack for the method, which shows that the space is insufficient by the fifth time.
Program counter
The program counter is a line indicator that records the bytecode executed by the current thread. The multi-threading of the JVM is realized by the CPU time slice rotation (that is, the threads switch in turn and allocate processor execution time) algorithm. In other words, a thread may be suspended due to the exhaustion of the time slice during execution, and another thread acquires the time slice and starts execution.
Simply put, the main function of the program counter is to record the line number indicator of the bytecode executed by the current thread.
Method area (metadata area)
The method area stores the metadata information, static variables, constants and other data of the class.
Heap
Usually, objects created by everyone using the new keyword will enter the heap. The heap is also the area that GC takes care of. The heap will be divided into: the young generation and the old generation, and the young generation will be further divided into the Eden area and the Survivor area:
The Eden area and Survivor area in the new generation are based on the JVM recovery algorithm, but most of them now use the generational recovery algorithm, so the new generation will be directly summarized into the Eden area and the Survivor area when introducing the heap.
summary
Summary of JVM memory model:
The JVM memory model is divided into a thread private area and a shared area. The virtual machine stack/local method stack is responsible for storing the thread execution method. The stack frame. The program counter is used to record the location of the thread execution instruction. The method area (metadata area) stores the metadata information and static state. Variables, constants and other data heap (heap) objects created with the new keyword will enter the heap, and the heap is divided into the young generation and the old generation
When can the object be recovered?
JVM judges object recycling in two ways: reference counting, GC Roots, reference counting is relatively simple, JVM maintains a reference count for each object, assuming that the reference count of A object is zero, it means that no task object refers to A object, then A object It can be recycled, but the disadvantage of reference counting is that it cannot solve the problem of circular references.
GC Roots uses a series of objects named GC Roots as the starting point. From these nodes, it searches downward. The searched path is called the reference chain. When an object is connected to the GC Roots without any reference chain, the object is proved to be unavailable.
In Java, the objects that can be used as GC Roots include the following:
Objects referenced in the virtual machine stack; objects referenced by class static properties in the method area; objects referenced by constants in the method area; objects referenced by JNI (in general, Native methods) in the local method stack;
summary
In general, when an object cannot be searched through GC Roots, it means that the object can be recycled, but when it is recycled depends on the mood of the GC!
What are the common garbage collector algorithms, and what are their advantages and disadvantages?
Mark clear
This algorithm is divided into two stages: marking and cleaning. The
marking phase starts scanning from the root set (GC Root). Whenever an object is reached, the object is marked as alive. The cleaning phase will not be marked after the scan is completed. The object is cleared.
Use a picture to illustrate:
this algorithm has a defect that it will generate memory fragmentation. As shown in Figure B above, it will leave a memory area after being cleared. If a large object needs to be allocated later, there will be no continuous memory available for use.
Mark up
There is no memory fragmentation problem with marking and arranging. It also starts scanning from the root set (GC Root) to mark and then clears useless objects. After the clearing is completed, it will clear the memory.
In this way, the memory is continuous, but another problem that arises is that the object has to be moved every time, so the cost is high.
Copy algorithm
The replication algorithm will push the JVM into two equal parts. If the heap is set to 1g, then the heap will be divided into two areas of 512m each when using the replication algorithm. When allocating memory to an object, one of them is always used for allocation. After the allocation is full, the GC will mark it, and then move the surviving objects to another blank area, and then clear all non-surviving objects, and repeat In the process of processing, there will always be a blank area that has not been reasonably used.
The two areas are alternately used, the biggest problem is that it will lead to a waste of space, and the utilization rate of heap memory is only 50%.
summary
Summary of JVM recycling algorithm:
Mark removal is fast, but it will generate memory fragmentation; Mark defragmentation solves the problem of marking clear memory fragmentation, but the object must be moved every time, so the cost is high; the copy algorithm has no memory fragmentation and does not need to move the object, but it causes space waste;
When will the subject enter the old age?
The newly created objects will stay in the young generation at the beginning, but as the JVM runs, some long-lived objects will slowly move to the old generation.
According to the target age
The JVM will add an age counter to the object. Every time the object "passes" a GC, the age will be +1. When the object reaches the set threshold (the default is 15 years old), it will be moved to the old age. Adjust this threshold by -XX:MaxTenuringThreshold.
After a Minor GC, the age of the object will be +1, objects that reach the threshold will move to the old generation, and other surviving objects will continue to remain in the young generation.
Dynamic age judgment
According to the age of the object, there is another strategy that will allow the object to enter the old age. There is no need to wait for 15 GCs to enter the old age. His general rule is that if the Survivor of the object is currently placed, the total size of a batch of objects is larger than this Survivor memory. 50%, then objects older than this batch of objects can directly enter the old age.
For the four objects A, B, D, and E as shown in the figure, if Survivor 2 is 100m, if the memory size of A + B + D exceeds 50m, and the age of D is now 10, then E will be moved to the old age. In fact, the calculation logic is as follows: the sum of multiple objects with age 1 + age 2 + age n exceeds 50% of the Survivor area, then all objects over age n will be placed in the old age.
Big objects enter the old age directly
If the parameter -XX:PretenureSizeThreshold is set, then if the object you want to create is larger than the value of this parameter, such as allocating a super-large byte array, then put the large object directly into the old generation without going through new life generation.
Doing so can avoid large objects in the new generation, avoiding the GC many times, and having to copy them, and finally enter the old generation. Copying such large objects back and forth is very time-consuming.
What is the space allocation guarantee strategy?
Before the occurrence of Minor GC, the virtual machine checks whether the maximum available continuous space in the old generation is greater than the total space of all objects in the new generation. If it is greater, the Minor GC is safe. If it is less, the virtual machine checks the value of the HandlePromotionFailure setting. Whether to allow guarantee failure. If HandlePromotionFailure=true, then it will continue to check whether the maximum available continuous space in the old generation is greater than the average size of the objects promoted to the old generation. If it is greater than the average size of the objects promoted to the old generation, a Minor GC will be attempted, but this time the Minor GC is still risky; if it is less than Or HandlePromotionFailure=false, then perform a Full GC instead.
How to optimize and reduce Full GC?
Summarizing some of the previous problems and applying them online, how should the JVM optimize and reduce Full GC? Take a standard 4-core 8G machine as an example. First, the system reserves 4G, and the other 4G is allocated according to the following rules:
•Heap memory: 3g Cenozoic: 1.5g
• Cenozoic Eden area: 1228m
• Cenozoic Survivor area: 153m
•Methods Area: 256m
• Virtual machine stack: 1m/thread
The setting parameters are as follows:
-Xms3072m
-Xmx3072m
-Xmn1536m
-Xss=1m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:HandlePromotionFailure
-XX:SurvivorRatio=8
Estimate the amount of memory occupied by the system per second
Before optimizing the JVM, we must first estimate the amount of memory occupied by the system per second. For example, if there is a mall system with a daily activity of one million, the daily order volume is about 20w. Based on 8 hours a day, the order service per second is about There will be 500 requests, and then roughly estimate how much memory each request occupies, and calculate how much memory is spent per second.
Assuming 500 requests per second, each request needs to allocate 100k of space, and that 1 second needs to allocate approximately 50m of memory.
Calculate how often to trigger Minor GC
According to the previous estimation, if about 50m of memory needs to be allocated in 1 second, the space of the Eden area is 1228m, and the Minor GC will be executed every 25 seconds on average.
Check if the Survivor area is sufficient
According to the above model, Minor GC must be executed every 25 seconds. During the GC execution, all the objects in the young generation cannot be recovered. Then, at 50m per second, there will be about 100m objects that cannot be recovered during each GC execution. You will enter the Survivor area, but don’t forget that the JVM has a dynamic age determination mechanism, so that the space for Survivor is significantly smaller. Therefore, set the new generation to 2048m to avoid triggering dynamic age determination:
-Xms3072m
-Xmx3072m
-Xmn2048m
...
Big objects enter the old age directly
Large objects are generally long-lived and used objects. Generally speaking, 1M objects are set directly into the old age, so as to prevent large objects from being copied back and forth in the young generation, so add the PretenureSizeThreshold=1m parameter.
...
-XX:PretenureSizeThreshold=1m
...
Set the age threshold of the object reasonably
After Minor GC escapes 15 garbage collections by default, it is automatically promoted to the old age. According to our assessment, a Minor GC is triggered once in 25 seconds. If the default value of the MaxTenuringThreshold parameter is followed, after 15 GCs, it should be 6 minutes later. However, in combination with the current business scenario, this can be reduced a bit, so that those objects that should have entered the old age enter the old age as soon as possible, avoiding copying costs and wasting the space of the new generation, resulting in insufficient space in the new generation Survivor and triggering a Full GC.
...
-XX:MaxTenuringThreshold=6
...
to sum up
The above is an interview with a big factory for everyone: talk about how your online JVM is optimized, I hope it will be helpful to everyone