Gc 流程：
[older generation][survivor 1][survivor 2][eden]
*young generation=eden + survivor
1,当eden满了，触发minor GC；
2,minor GC做2件事,一，去掉一部分没用的object。2，把老的还被引用的object发到survior里面，等下几次GC以后，survivor再放到old里面。
3,当old满了，触发full GC.full GC很消耗内存，把old，young里面大部分垃圾回收掉。这个时候用户线程都会被block。
Summary：
1，保存gc信息。
java -Xloggc:<file> (Sun JVM option)/java -verbose:gc (IBM JVM)
2，调优参数。
JVM option
java -XX:NewRatio=2
2代表older generation:young generation==2:1
java -XX:SurvivorRatio=6
sets the ratio between each survivor space and eden to be 1:6. In other words, each survivor space will be one eighth of the young generation (not one seventh, because there are two survivor spaces).
Survivor的space是young generation的1/8，young generation space＝eden + survivor.
使用其他垃圾收集机制：
Full GC pause too long:java XX:+UseConcMarkSweepGC
Minor GC pause too long: java -XX:+UseParallelGC
Those flags differing per architecture/OS/JVM Verison. "Flag and Default" has the default of Sparc/-server, JVM version 1.3
| Flag and Default |
Description |
| -XX:CompileThreshold=10000 |
number of method invocations/branches before (re-)compiling [10,000 -server, 1,500 -client] |
| -XX:MaxNewSize=32m |
Maximum size of new generation (in bytes) [32m sparc, 2.5m intel for 1.3, no limit for 1.4 as NewRatio is now used to determine MaxNewSize] |
| -XX:NewRatio=2 |
Ratio of new/old generation sizes [sparc -server: 2, sparc -client: 4 (1.3) 8 (1.3.1+), intel: 12] |
| -XX:NewSize=2228224 |
Default size of new generation (in bytes) [sparc 2.125M, intel: 640k] |
| -XX:PreBlockSpin=10 |
Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (as of J2SE 1.4.2, Linux only) |
| -XX:ReservedCodeCacheSize=32m |
Reserved code cache size (in bytes) – maximum code cache size. [Solaris 64-bit: 1024m] |
| -XX:SurvivorRatio=64 |
Ratio of eden/survivor space size [Solaris: 64, Solaris: 32 (on 1.3.1 and later), Linux/Windows: 8] |
| -XX:ThreadStackSize=512 |
Thread Stack Size (in Kbytes) (0 means use default stack size) [Sparc: 512, Solaris Intel: 256, Sparc 64bit: 1024 all others 0] |
-XX:+UseTLE
(-XX:+UseTLAB in J2SE 1.4) |
Use thread-local object allocation [Sparc -server: true, all others: false] |
| -XX:-UseISM |
See Intimate Shared Memory |
| -XX:-UseMPSS |
Use Multiple Page Size Support (Solaris 9 only) w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. |
| -XX:LargePageSizeInBytes=2m |
Sets the large page size used for the Java heap. Set to 2m when running 32-bit JVM on Solaris 10 x86 with AMD64 CPUs. Solaris Only. Defaults (SPARC: 8m, x86: 4m, x86_64: 2m) |
| -XX:-UseSpinning |
Enable naive spinning on Java monitor before entering operating system thread synchronizaton code. (as of J2SE 1.4.2, Linux only) |
3，young generation比例越大。不一定最好。
〉footprint越多。所用heap越大。
〉如果太大了，会导致minor GC很少发生（young space大了，不容易触发minor GC），最后导致full GC次数增多，Acc time增多。
〉full GC肯能会越少。older generation满了会导致full GC。
〉Acc Time可能会越少。full GC会花很多的时间。当full GC的时候，用户线程都是blocking的。
〉thoughput可能越高。实际用来运行工作的运行时间越多。
4，总的来说。
对于短生命周期的object比例越大的时候，young size需要小一些。因为每次minor gc都会比较有效。
当长生命周期的object比例越大的时候，young size需要大一些。因为每次的minor gc回收的垃圾比较少，放到older space里面的object越多，这样容易促发full gc，然而，full gc并不会收集多少垃圾，只会blocking用户进程。
*是不是越烂的程序young size还是小点好？哈哈！
*其实并不是极端最好，young size太小了会有minor gc效率不高。太大了又可能导致大量的full gc。
