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);

    }

}

　　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方法中显式调用其他资源释放方法。

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

Counter prime = new Counter();

SoftReference soft = new SoftReference(prime) ; //soft reference

prime = null; 

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

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

Counter counter = new Counter(); // strong reference

WeakReference<Counter> weakCounter = newWeakReference<Counter>(counter); //weak reference

counter = null; 

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

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

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

ReferenceQueue refQueue = new ReferenceQueue();

DigitalCounter digit = new DigitalCounter();

PhantomReference<DigitalCounter> phantom = new PhantomReference<DigitalCounter>(digit, refQueue);

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

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

package wys.demo1;

public class Demo1 {

    public static Demo1 obj;

    @Override

    protected void finalize() throws Throwable {

        super.finalize();

        System.out.println("CanReliveObj finalize called");

        obj = this;// 把obj复活了！！！

    }

    @Override

    public String toString(){

        return "I am CanReliveObj";

    }

    public static void main(String[] args) throws InterruptedException{

        obj = new Demo1();// 强引用

        obj = null;   //不会被立即回收，是可复活的对象

        System.gc();// 主动建议JVM做一次GC，GC之前会调用finalize方法，而我在里面把obj复活了！！！

        Thread.sleep(1000);

        if(obj == null){

            System.out.println("obj 是 null");

        }else{

            System.out.println("obj 可用");

        }

        System.out.println("第二次gc");

        obj = null;    //不可复活

        System.gc();

        Thread.sleep(1000);

        if(obj == null){

            System.out.println("obj 是 null");

        }else{

            System.out.println("obj 可用");

        }

    }

}

　　结果：

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方法。

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