java有内置的垃圾回收器做内存回收，通过强引用、软引用、弱引用和虚引用给对象做"标记"，告诉垃圾回收器在什么时机回收什么内存。我先通过JVM options参数探测JVM内部不同垃圾回收的策略。
minimum size of heap:10MB
maximum size of heap:20MB
new size of heap:5MB
截图是以空main方法运行后JVM的内存使用概要。新生代内存大小为5MB，PSYoungGen区可用内存大小为4608K，eden、from和to区分别为4MB、512K和512K；老年代可用内存大小为5120K。
创建allocate1数组在eden区分配了4096KB*0.25=1MB内存。
JVM将3MB的对象放到了老年代：
为什么JVM不GC然后在新生代上分配3MB空间？这和内存分配与回收策略有关:
即：
新生代初始36%的内存空间没有可GC的空间。
新生代的eden+from剩余3.1MB，足以提供3MB空间，但内存按page分配（4K/page），如果在新生代分配会使得对象分开保存在不同的区（eden和from），是否存储对象的内存只能在一个区里，这点待验证。
垃圾收集器为保吞吐量，当新生代无足够内存时，把对象分配到了老年代。
初始我们给heap分配了最大20MB的内存空间，下面看下GC的场景。
此时发生了GC和Full GC:
刨除初始被占用的36%的eden区，20MB的heap大小不满足内存分配要求，触发了java.lang.OutOfMemoryError: Java heap space错误。
此时将allocate1=null，触发GC，heap刚好可以完成内存分配。此时是在释放了eden空间后，转移到老年代进行内存分配：
To be continued...