第三节、虚拟机年代划分（Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning官方文档抄录）

3 Generations

Efficient collection is made possible by focusing on the face that a majority of objects ‘die young.’

📓Generations : is memory pools holding objects of different ages.

🔑Minor collection: When the young generation fills up, it causes a minor collection in which only the young generation is collected; garbage in other generations is not reclaimed.

🔑the tenured generation: 老年代

🔔Major collection: Typically, some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection. Eventually, the tenured generation will fill up and must be collected, resulting in a major collection, in which the entire heap is collected.

🎶 If garbage collection becomes a bottleneck, you will most likely have to customize the total heap size as well as the sizes of the individual generations. Check the verbose garbage collector output and then explore the sensitivity of your individual performance metric to the garbage collectors parameters.

• Figure 3-2 Default Arrangement of Generations, Except for Parallel Collector and G1

At initialization, a maximum address space is virtually reserved but not allocated to physical memory unless it is needed. The complete address space reserved for object memory can be divided into the young and tenured generations.

Performance Considerations

There are two primary measures of garbage collection performance:

• Throughput is the percentage of total time not spent in garbage collection considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed.)
• Pauses are the times when an application appears unresponsive because garbage collection is occurring.

🔑Footprint is the working set of a process, measured in pages and cache lines. 内存占用是进程的工作集，以页面和高速缓存线度量。

🔑Promptness is the time between when an object becomes dead and when the memory becomes available.

In general, choosing the size for a particular generation is a trade-off between these considerations. For example, a very large young generation may maximize throughput, but does so at the expense of footprint, promptness, and pause times. Young generation pauses can be minimized by using a small young generation at the expense of throughput. The sizing of one generation does not affect the collection frequency and pause times for another generation.

Measurement

🍐 -verbose:gc

The command-line option -verbose:gc causes information about the heap and garbage collection to be printed at each collection. For example, here is output from a large server application:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

日志解释：

• GC: minor collection

• Full GC: major collection

• 325407K->83000K

  • 325407K: the combined size of live objects before garbage collection
  • 83000K: the combined size of live objects after garbage collection. After minor collections, the size includes some objects that are garbage (no longer alive) but cannot be reclaimed. These objects are either contained in the tenured generation or referenced from the tenured generation.

• (776768K): the committed size of the heap: the amount of space usable for Java objects without requesting more memory from the operating system. Note that this number only includes one of the survivor spaces. Except during a garbage collection, only one survivor space will be used at any given time to store objects.

• 0.2300771 secs: indicates the time taken to perform the collection

⚠️ The format of the output produced by -verbose:gc is subject to change in future release.

🍐 -XX:+PrintGCDetails

The command-line option -XX:+PrintGCDetails causes additional information about the collections to be printed.

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

This indicates that the minor collection recovered about 98% of the young generation, DefNew: 64575K->959K(64576K) and took 0.0457646 secs (about 45 milliseconds).

The usage of the entire heap was reduced to about 51% (196016K->133633K(261184K)), and there was some slight additional overhead for the collection (over and above the collection of the young generation) as indicated by the final time of 0.0459067 secs.

⚠️ The format of the output produced by -XX:+PrintGCDetails is subject to change in future releases.

🍐 -XX:+PrintGCTimeStamps

The option -XX:+PrintGCTimeStamps adds a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

The collection starts about 111 seconds into the execution of the application. The minor collection starts at about the same time. Additionally, the information is shown for a major collection delineated by Tenured. The tenured generation usage was reduced to about 10% (18154K->2311K(24576K)) and took 0.1290354 secs (approximately 130 milliseconds).