public class OnStackTest {
    /**
     * alloc方法内分配了两个字节的内存空间
     */
    public static void alloc(){
        byte[] b = new byte[10];
        b[0] = 1;
    }

    public static void main(String[] args) {
        long b = System.currentTimeMillis();

        // 分配 100000000 个 alloc 分配的内存空间
        for(int i = 0; i < 100000000; i++){
            alloc();
        }

        System.out.print("Xmx =");
        System.out.println(Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M");

        System.out.print("free mem =");
        System.out.println(Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M");

        System.out.print("total mem =");
        System.out.println(Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M");

        long e = System.currentTimeMillis();
        System.out.println(e - b);
    }
}

不适用于存活对象较多的场合如老年代，使用在新生代，

原理是

将原有的内存空间分为两块，两块空间完全相同，每次只用一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。同样也没有内存

碎片产生。

 

复制算法的缺点是内存的浪费，因为每次只是使用了一般的空间， 而大多数存活对象都在老年代，故复制算法不用在老年代，老年代是Java堆的空间的担保地区。复制算法主要用在新生代。在垃圾回收的时候，大对象直接从新生代进入了老年代存放，大对象一般不使用复制算法，因为一是太大，复制效率低，二是过多的大对象，会使得小对象复制的时候无地方存放。还有被长期引用的对象也放在了老年代。

依据对象的存活周期进行分类，短命对象归为新生代，长命对象归为老年代。根据不同代的特点，选取合适的收集算法。少量对象存活（新生代，朝生夕死的特性），适合复制算法，大量对象存活（老年代，生命周期很长，甚至和应用程序存放时间一样），适合标记清理或者标记压缩算法。

 

经过上述总结，想到所有的算法，需要能够识别一个垃圾对象，那么怎么才能识别呢？

因此需要给出一个可触及性的定义：

　　引出一个方法的理解：finalize方法

 

　　GC准备释放内存的时候，会先调用finalize()。而调用了这个方法不代表对象一定会被回收。因为GC和finalize() 都是靠不住的，只要JVM还没有快到耗尽内存的地步，它是不会浪费时间进行垃圾回收的。

　　finalize()在什么时候被调用?
　　有三种情况

• 所有对象被Garbage Collection时自动调用,比如运行System.gc()的时候。
• 程序退出时为每个对象调用一次finalize方法。
• 显式的调用finalize方法。

　　finalize 是Object的 protected 方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。finalize与C++中的析构函数不是对应的。C++中的析构函数调用的时机是确定的（对象离开作用域或delete掉），但Java中的finalize的调用具有不确定性。

　　不建议用finalize方法完成“非内存资源”的清理工作，因为Java语言规范并不保证finalize方法会被及时地执行、而且根本不会保证它们会被执行，而且 finalize 方法可能会带来性能问题。因为JVM通常在单独的低优先级线程中完成finalize的执行，finalize方法中，可将待回收对象赋值给GC Roots可达的对象引用，从而达到对象再生的目的。finalize方法至多由GC执行一次(用户当然可以手动调用对象的finalize方法，但并不影响GC对finalize的行为)

　　但建议用于：

• 清理本地对象(通过JNI创建的对象)；
• 作为确保某些非内存资源(如Socket、文件等)释放的一个补充：在finalize方法中显式调用其他资源释放方法。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

前面说了，GC是分代的，GC的的回收条件取决于识别该对象是不是垃圾。而识别垃圾对象又取决于指向该对象的引用类型。Java中有四种引用类型，强，软，弱，虚。

如果一个对象只有弱引用指向它，GC会立即回收该对象，这是一种急切回收方式。相对的，如果有软引用指向这些对象，则只有在JVM需要内存时才回收这些对象。弱引用和软引用的特殊行为使得它们在某些情况下非常有用。

例如：软引用可以很好的用来实现缓存，当JVM需要内存时，垃圾回收器就会回收这些只有被软引用指向的对象。而弱引用非常适合存储元数据，例如：存储ClassLoader引用。如果没有类被加载，那么也没有指向ClassLoader的引用。一旦上一次的强引用被去除，只有弱引用的ClassLoader就会被回收。

• 强引用：类似我们常见的，比如 A a = new A（）；a就叫强引用。任何被强引用指向的对象都不能GC，这些对象都是在程序中需要的。
• 软引用：使用java.lang.ref.SoftReference类来表示，软引用可以很好的用来实现缓存，当JVM需要内存时，垃圾回收器就会回收这些只有被软引用指向的对象。如下：

　　强引用置空之后，代码的第二行为对象Counter创建了一个软引用，该引用同样不能阻止垃圾回收器回收对象，但是可以延迟回收，软引用更适用于缓存机制，而弱引用更适用于存贮元数据。

• 弱引用：使用java.lang.ref.WeakReference 类来表示，弱引用非常适合存储元数据，例如：存储ClassLoader引用。如果没有类被加载，那么也没有指向ClassLoader的引用。一旦上一次的强引用被去除，只有弱引用的ClassLoader就会被回收。也就是说如果一个对象只有弱引用指向它，GC会立即回收该对象，这是一种急切回收方式。如：

　　只要给强引用对象counter赋null,该对象就可以被垃圾回收器回收。因为该对象不再含有其他强引用，即使指向该对象的弱引用weakCounter也无法阻止垃圾回收器对该对象的回收。相反的，如果该对象含有软引用，Counter对象不会立即被回收，除非JVM需要内存。

　　另一个使用弱引用的例子是WeakHashMap，它是除HashMap和TreeMap之外，Map接口的另一种实现。WeakHashMap有一个特点：map中的键值(keys)都被封装成弱引用，也就是说一旦强引用被删除，WeakHashMap内部的弱引用就无法阻止该对象被垃圾回收器回收。

• 虚引用：没什么实际用处，就是一个标志，当GC的时候好知道。拥有虚引用的对象可以在任何时候GC。

　　除了了解弱引用、软引用、虚引用和WeakHashMap，还需要了解ReferenceQueue。在创建任何弱引用、软引用和虚引用的过程中，可以通过如下代码提供引用队列ReferenceQueue：

 

　　引用实例被添加在引用队列中，可以在任何时候通过查询引用队列回收对象。

　　

　　现在我对一个对象的生命周期进行描述：

　　新建Java对象A首先处于可达的，未执行finalize方法的状态，随着程序的运行，一些引用关系会消失，或者变迁，当对A使用可达性算法判断，对象A变成了 GC Roots 不可达时，A从可达状态变迁到不可达状态，但是JVM不会就就这样把它清理了，而是在第一次GC的时候，对它首先进行一个标记（标记清除算法），之后最少还要再进行一次筛选，而对其筛选的的条件就是看该对象是否覆盖了Object的finalize方法，或者看这个对象是否执行过一次finalize方法。如果没有执行，也没有覆盖，就满足筛选条件，JVM将其放入F-Queue队列，由JVM的一个低优先级的线程执行该队列中对象的finalize方法。此时执行finalize方法优先级是很低的，且不会保证等待finalize方法执行完毕才进行第二次回收（怕发生无限等待的情景，JVM崩溃），之后不久GC对队列里的对象进行二轮回收，去判断该对象是否可达，若不可达，才进行回收，否则，对象“复活”（执行finalize的过程中，应用程序是可以让对象再次被引用，复活的）。而在可达性判断的时候，还要兼顾四种引用类型，根据不同的引用类型特点去判断是否是回收的对象。看例子：

 

　　结果：

CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null

　　说明JVM不管程序员手动调用finalize，JVM它就是执行一次finalize方法。执行finalize方法完毕后，GC会再次进行二轮回收，去判断该对象是否可达，若不可达，才进行回收。

　　

　　建议：避免使用finalize方法！

　　太复杂了，还是让系统照管比较好。可以定义其它的方法来释放非内存资源。建议使用try-catch-finally来替代它执行清理操作。

　　如果手动调用了finalize，很容易出错。且它执行的优先级低，何时被调用，不确定——也就是何时发生GC不确定，因为只有当内存告急时，GC才工作，即使GC工作，finalize方法也不一定得到执行，这是由于程序中的其他线程的优先级远远高于执行finalize（）的线程优先级。 因此当finalize还没有被执行时，系统的其他资源，比如文件句柄、数据库连接池等已经消耗殆尽，造成系统崩溃。且垃圾回收和finalize方法的执行本身就是对系统资源的消耗，有可能造成程序的暂时停止，因此在程序中尽量避免使用finalize方法。

　　这是Java中一种全局暂停的现象，全局停顿，所有Java代码停止，类似JVM挂起的状态……但是native代码可以执行，但不能和JVM交互。这多半由于GC引起，其他的引起原因比如：

• Dump线程
• JVM的死锁检查
• 堆的Dump。

　　这三者出现概率很低，多半是程序员手动引起的，而GC是JVM自动引起的。

　　

　　GC时为什么会有全局停顿？

　　长时间服务停止，没有响应，一般新生代的GC停顿时间很短，零点几秒。而老年代比较时间长，几秒甚至几十分钟……一般堆内存越大，GC时间越长，也就是Stop-The-World越久。所以，JVM的内存不是越大越好，要根据实际情况设置。

　　遇到HA系统，可能引起主备切换，严重危害生产环境。比如一个系统，一个主机服务器，一个备机服务器，不会同时启动，我们会只使用一个，比如主机暂时因为GC没有响应，如果时间太长，我们会使用备机，一旦主机恢复了，主机也启动了，此时备机主机都启动了，很可能导致服务器数据不一致……

　　

　　前面罗嗦了一堆，那么这些算法是如何在JVM中配合使用的呢？那么就引出新的问题需要解决：JVM的垃圾回收器。

　　回忆下堆的结构：还是以Java 7为例子：

　　Java堆整体分两代，新生代和老年代，顾名思义，前者存放新生对象，大部分都是朝生夕死！进行GC的次数不多，后者存放的是时间比较久的对象，也就是多次GC还没死的对象。对象创建的时候，大部分都是放入新生代的eden区，除非是很大的对象，可能会直接存放到老年代，还有之前说的栈上分配（逃逸分析）。

　　如果eden对象在GC时幸存，就会进入幸存区，也就是s0，s1，或者叫from和to，或者叫survivor（两个），大小一样。完全对称，功能也一样。前面说了GC有复制算法，那么就是使用在这里，GC在新生代时，eden区的存活对象被复制到未使用的幸存区，假设是to，而正在使用的是from区的年轻的对象也会一起被复制到了to区，如果to区满了，这些对象也和大对象，老年对象一样直接进入了老年代保存（担保空间）。此时，eden区剩余的对象和from区剩余的对象就是垃圾对象，能直接GC，to区存放的是新生代的此次GC活下来的对象。避免了产生内存碎片。