The GC strategy of Sun Hotspot JVM is generational:

  1. Yong Generation: Eden, Survivor1, Survivor2 Scavenge GC, Copy algorithm, frequent GC
  2. Old（Tenured) Generation 
    Will cause Full GC, try to minimize the number of Full GCs as much as possible The CMS (Concurrent Mark Sweep, C is not referring to Compact) algorithm is generally used
  3. Permanent Generation    
    Will cause Full GC, minimize the number of Full GCs as much as possible
    Set permanent Generation Space to store MetaData information such as Class and Method using - XX: PermSize=- XX: MaxPermSize=. Unlike Heap, Sun JVM defaults to 64M.

Note:

  1. Balancing throughput and pause time metrics in GC tuning, server and client JVMs will have different considerations (in HotSpot)
  2. New, old space tuning: New space generally accounts for 25-40%, and if there are many stateless objects, you can consider allocating more; On the contrary, if there are many declarative objects, you can allocate more old space
  3. Add - verbose: gc to the Java startup command line to measure the current GC performance
    [GC 325407K->83000K(776768K), 0.2300771 secs]
    [GC 325816K->83372K(776768K), 0.2454258 secs]
    [Full GC 267628K->83769K(776768K), 1.8479984 secs]    
    325407K and 83000K are Yong GenerationHeap sizes before and after Minor GC, with a total size of 776768K is 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 does not include one of the survivor spaces, since only one can be used at any given time, and also does not include the permanent generation, which holds metadata used by the virtual machine.
    My understanding is that the current sum of young and old generation, excluding the size of a survivor and permanent area. The size of the current young generation is gradually increasing, between xms and xmx.  
  4. The GC log format output by the - XX:+PrintGCDetails parameter may vary
    [GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]   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 that 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.    
  5. -XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one fourth of the total heap size.  
    6. -XX:SurvivorRatio=6   sets the ratio between a survivor space and eden  to 1:6. In other words, each survivor space will be one sixth the size of eden, and thus one eighth the size of the young generation (not one seventh, because there are two survivor spaces).