摘自java performance
Surviving Generations and Memory Leaks
To understand the Generations column in the memory profiling results view, you have to
think about the JVM’s Garbage Collection process. Every time the garbage collector runs
each object either survives and continues to occupy heap memory, or it is removed and its
memory is freed. If an object survives, then its age has increased by a value of 1. In other
words, the age of an object is simply the number of garbage collections that it has survived.
The value of Generations is the number of different object ages.
For example, assume several objects were all allocated when your application first started.
Further, another group of objects was allocated at the midpoint of your application’s run.
And finally, some objects have just been allocated and have only survived one garbage
collection. If the garbage collector has run 80 times, then all the objects in the first group
will have an age of 80, all the objects in the second group will have an age of 40, and
all of the objects in the third group will have an age of 1. In this example, the value of
Generations is 3, because there are three different ages among all the objects on the
heap: 80, 40, and 1.
In most Java applications the value for Generations eventually stabilizes. This is because the
application has reached a point where all long-lived objects have been allocated. Objects
that are intended to have a shorter life span do not impact the Generations count because
they will eventually be garbage collected.
If the Generations value for your application continues to increase as the application
runs, it could be an indication of a memory leak. In other words, your application is
continuing to allocate objects over time, each of which has a different age because it has
survived a different number of garbage collections. If the objects were being properly
garbage collected, the number of different object ages would not be increasing.