Why the new generation of JMM has two survivors

The reason is actually very simple:

If there is only one Eden and one survivor, Eden will copy the surviving objects to the survivor when performing the Minor GC. This step is no problem. When Eden executes Minor GC again, Eden splices the surviving objects into the survivor. At the same time, survivor clears the objects that were previously stored but are now invalid. It is this step that makes the previously stored continuous data memory no longer continuous .

If there are two survivors now, when Eden executes Minor GC for the first time, copy the data to one of them, temporarily named s0. When Eden executes Minor GC again, both Eden and s0 will copy the surviving objects to another survivor , Temporarily named s1. During the copying process, the data stored in s1 is in order . At this time, the roles of s0 and s1 are exchanged. In the next Eden GC, Eden and s1 will copy the surviving objects to s0. The copy process ensures the continuity of the data memory . Next, the roles of s0 and s1 are switched again.

That is to say, through the mutual backup of two survivors, each time the data is in order, a single survivor has the problem of memory fragmentation, resulting in low memory utilization. The Full GC triggered when the memory is insufficient will cause serious performance problems (more time-consuming, and the gc thread will suspend other threads (stop the world)).

Guess you like

Origin blog.csdn.net/u013821237/article/details/90044565