Interviewer: I remember last time you talked about the JVM memory structure (runtime data areas) and mentioned “heap”, and you said there were several areas

Interviewer: I felt that if I continued, I might have to work overtime

Interviewer: I’m a little empty today, so let’s talk more about the pile

Candidates: Well, as mentioned earlier, the heap is divided into “new Generation” and “old generation”, the “new generation” is divided into “Eden” and “Survivor” zones, and the “Survivor” zone is divided into “From Survivor” and “To Survivor” zones

Candidate: At this point, I’d like to talk about Java’s garbage collection mechanism

Interviewer: Then start your performance

Candidate: When we use Java, we create a lot of objects, but we don’t “manually” clean them up

Candidate: If you use C/C++, you need to free it yourself

Candidate: Why don’t we manually dump garbage when we write Java? The reason is simple, the JVM does it for us (automatic garbage collection)

Interviewer: HMM…

Candidate: My personal definition of garbage is that as long as an object is no longer in use, it is considered garbage and the space it occupies can be recycled

Interviewer: So how do you tell that the object is no longer in use?

Candidates: Two commonly used algorithms are “reference counting” and “accessibility analysis”

Candidate: The idea of reference counting is simple: +1 if the object is referenced, but -1 if the object fails to be referenced. When the counter is 0, the object is no longer referenced and can be reclaimed

Candidate: The most obvious disadvantage of reference counting is that it is impossible to determine whether an object should be recycled if it has cyclic dependencies (A depends on B, B depends on A)

Interviewer: HMM…

Candidate: Another method is reachability analysis: it starts with “GC Roots” and searches down. When there are no references connected to “GC Roots”, the object is unavailable and can be reclaimed

Candidate: “GC Roots” is a set of references that must be “active”. From “GC Root,” the program can find objects that might be in use by direct or indirect references

Interviewer: Not really. What are GC Roots? You say it’s an active set of quotes, can you give me an example? It’s too abstract.

Candidate: For example, last time we talked about the virtual machine stack in the JVM memory structure, the virtual machine stack has the stack frame, the stack frame has the local variable? Local variables store references.

Candidate: So if the stack frame is at the top of the virtual machine stack, does that mean that the stack frame is active (in other words, that the thread is being called)?

Candidate: Since the thread is calling it, is the object reference to the heap in the stack frame necessarily an “active” reference?

Candidate: So, a currently active stack frame reference to an object in the heap could be “GC Roots”

Interviewer: HMM…

Candidates: There’s more to being GC Roots than that, of course

Candidates: class static variable references are “GC Roots”, objects referenced by “Java native methods” are “GC Roots”, etc…

Candidate: Getting back to the point of understanding: GC Roots is a set of references that must be “active”, as long as there is no direct or indirect reference to GC Roots, it is garbage

Candidate: The JVM uses a “reachability analysis algorithm” to determine whether an object is garbage

Interviewer: I see

Candidates: The first step in garbage collection is to “tag” objects that are not referenced by “GC Roots.

Candidate: Once tagged, we can choose to “clear” anything that is not associated with GC Roots

Candidate: The process is pretty straightforward, but there are obvious problems

Candidate: Direct cleaning will cause the problem of “memory fragmentation” : MAYBE I have 10M free memory, but the program cannot get 9M memory space (10M memory space is discontinuous after garbage removal).

Candidate: Then solve the “memory fragmentation” problem is relatively simple and crude, “mark” finished, not directly “clean”.

Candidate: I “copy” the “marked” living object into another space, and when I’m done, I kill the entire space! There is no memory fragmentation problem

Candidate: The disadvantages are obvious: memory utilization is low and I have to copy (move) a new area

Interviewer: HMM…

Candidate: There’s a compromise: I don’t necessarily need a “big full space” to solve the memory fragmentation problem, I just need to be able to move around in the “current area.

Candidate: Move the living object to the side, move the garbage to the side, then delete the garbage together, not there is no memory fragment

Candidate: The technical term for this is “tidying up.”

Candidate: After all this talk, let’s get back to the “pile” again

Candidates: Studies have shown that most objects have a short life cycle, while only a few are likely to live for a long time

Candidate: Also because “garbage collection” causes “stop the world”

Candidate: “Stop the world” should be easy to understand: when recycling garbage, the program will not work properly for a short period of time. Otherwise, the user thread will continue to allocate change references while the JVM is reclaiming.

Candidate: To keep “stop the world” duration as short as possible and to increase the memory allocation rate that parallel GC can handle

Candidates: Many garbage collectors make a “physical” or “logical” distinction between these two types of objects, with objects that die quickly being called “young” and objects that live long being called “old.”

Candidate: Not all “garbage collectors” will be available, but we are probably using JDK8 online. All garbage collectors used in JDK8 and below are generational.

Candidate: So, you can see that my “pile” is drawing the “young generation” and the “old generation.”

Candidates: It is important to note that the older version of the GARBAGE collector’s ZGC is non-generational (:

Candidate: Just to clarify the situation, we will talk about ZGC when we are free

Interviewer: HMM… All right

Candidates: The garbage collection process mentioned above corresponds to several “garbage collection algorithms”, respectively:

Candidates: tag clearing algorithm, tag copy algorithm, and tag collation algorithm

Candidates: These algorithms should be easier to understand after the introduction

Candidates: Now that we know about generation and garbage collection algorithms, we can look at common garbage collectors in the JDK8 production environment and the following

Candidates: Younger generation garbage collectors are Seria, Parallel Avenge, ParNew

Candidates: Garbage collectors in the “Old days” are: Serial Old, Parallel Old, CMS

Candidate: When you look at the number of garbage collectors, it’s actually quite understandable. Serial is single-threaded, Parallel is multi-threaded

Candidates: These garbage collectors essentially “implement” garbage collection algorithms (tag copy, tag collation, and tag cleanup algorithms)

Candidate: CMS is “before JDK8” is a relatively new garbage collector that features the ability to minimize “stop the world” time. Allow the user thread and the GC thread to execute concurrently at garbage collection time!

Candidate: Again, the “young generation” garbage collectors use the “tag copy algorithm”

Candidate: So in the “heap memory” partition, the young generation is divided into Survivor From and Survivor To so that there is a complete memory space for the garbage collector To copy (move)

Candidate: The new object is placed in Eden

Candidate: LET me redraw the “heap memory” diagram because they have a default scale for their size

Candidate: I’ve already drawn the picture, so I don’t need to explain it

Interviewer: I also want to ask, is that the object of creation is usually in the “new generation”, when will it be in the “old age”?

Candidate: Well, I think simplicity can be divided into two cases:

Candidates: 1. If the object is too big, it will go into the old s (object creation is very big | | Survivor area can’t save the object)

Candidate: 2. If the object is too old, it will be promoted to the old s (each a Minor GC, surviving object + 1 age, to the default value is 15 promotion old s | | dynamic object age determination Can enter the old s)

Interviewer: Since you mentioned the Minor GC again, when will the Minor GC trigger?

Candidate: Minor GC is triggered when the Eden region runs out of space

Interviewer: Well, in my opinion, the Minor GC is the GC of the younger generation. You mentioned GC Roots again

Interviewer: So in the “young generation” GC, starting from GC Roots, won’t that also scan the “old generation” objects? Nyanyanya.. Isn’t that equivalent to a full heap scan?

Candidate: There are workarounds in this JVM, too.

Candidate: HotSpot VIRTUAL machine “old GC” (below G1) requires the entire GC heap to be in a contiguous address space.

Candidate: So there is a dividing line (old generation on one side, young generation on the other), so you can tell which generation the object is in by “address”

Candidate: As a Minor collector, start with GC Roots and stop going down if you find an “old age” object (Minor collector has no interest in old age areas)

Interviewer: But here’s another question. What if the “younger generation” is referenced by the “older generation”? (The old age object holds a reference to the young generation object), it is definitely not possible to recycle the “young generation” object at that time.

Candidate: The HotSpot VIRTUAL machine has a “card table” to avoid global scanning of “old age” objects

Candidate: Each small area of heap memory forms a “card page,” which is essentially a collection of card pages. Mark a card page as “dirty” when determining that it has a cross-generation reference to an existing object

Candidate: Well, once you know the card form, it’s easy. Instead of going through the entire “old age” object, you just need to go to the “card table” to find the “dirty page” and add it to the GC Root every time you do a Minor GC.

Interviewer: Yeah, yeah, that’s fine. Why don’t we talk more about CMS?

Candidate: This interview has been going on for almost an hour, and I’ve already drawn this much. The next time? The next time? A little tired

This paper concludes:

  • What is garbage: As long as an object is no longer in use, it is garbage
  • How to tell if it is garbage: reachability analysis algorithm and reference calculation algorithm, which reachability analysis algorithm is used by JVM
  • What is GC Roots: GC Roots are a set of references that must be active. References not associated with GC Roots are garbage and can be recycled
  • Common garbage collection algorithms: tag cleanup, tag copy, tag collation
  • Why you need generations: Most objects die young, and only a few live long. Both physical and logical generation occurs on heap memory in order to keep “stop the world” duration as short as possible and to increase the memory allocation rate that parallel GC can handle.
  • Minor GC: Triggered when Eden is full and traverses from Roots, young GC does not care about old age objects
  • What is a card table: a space swap time (similar to a bitmap), which avoids scanning all correspondence of the old age so that the Minor GC can proceed smoothly (example: the old age object holds a reference to the young generation object)
  • Heap memory ratio: the young generation takes up 1/3 of the heap memory, the old generation takes up 2/3 of the heap memory. Eden district accounted for 8/10 of the young generation, and Survivor district accounted for 2/10 of the young generation (including 1/10 From and To stations respectively).

Welcome to follow my wechat official account [Java3y] to talk about Java interview, on line interview series continue to update!

Online Interviewer – Mobile seriesTwo continuous updates a week!

Line – to – line interviewers – computer – end seriesTwo continuous updates a week!

Original is not easy!! Three times!!