三、浅谈final、finally、finalize有什么不同

一、final可以用来修饰类、方法、变量。final修饰的类表示不能继承扩展，final的变量是不可以修改的，而final的方法也是不可以重写的。

1. 我们可以将方法或者类声明为final，这样可以明确告知别人，这些行为是不能修改的。

2. 使用final修饰参数或者变量，也可以清楚地避免意外赋值导致的编程错误，甚至，有人明确推荐将所有方法参数，本地变量，成员变量声明成final。

3. final在Java内存模型中的语义规则：
   (1)在一个线程中，初次读对象引用与初次读该对象包含的final域，JVM禁止处理器重排序这两个操作(这个规则仅仅针对处理器)。编译器会在读final域之前插入一个LoadLoad屏障。
   (2)JVM禁止编译器把final域的写重排序到构造函数之外。写final字段的重排序规则可以确保，在对象引用为任意线程可见之前，对象的final字段已经正确初始化过了，而普通字段不具有这个保障。

4. final修饰的变量在某种程度上产生了不可变的效果，所以可以用于保护只读数据，尤其是在并发编程中，因为明确地不能再赋值final变量，有利于减少额外的同步开销，也可以省去一些防御性拷贝的必要。
   但是final并不等于不可变，比如下面这段代码：

      final List strList = new ArrayList<>();
      strList.add("Hello");
      strList.add("world");
      List unmodifiableStrList = List.of("hello", "world");
      unmodifiableStrList.add("again"); 

final只能约束strList这个引用不可以不赋值，但是strList对象行为不被final影响，添加元素等操作完全是正常的。如果我们希望对象本身是不可变的，那么需要相应的类支持支持不可变的行为。
实现一个不可变类的步骤有：
(1)将class声明为final，这样别人就不能通过扩展来绕开限制了。
(2)将所有成员变量定义为private和final，并且不要实现setter方法
(3)通常构造对象时，成员变量使用深度拷贝来初始化，而不是直接赋值，这是一种防御措施，因为你无法确定输入对象不被其他人修改。
(4)如果确实需要实现getter方法，或者其他可能返回内部状态的方法，使用copy-on-write原则，创建私有的copy。

5. final也许会有性能好处，很多文章或者书籍都介绍了特定场景提高性能，比如，利用final可能有助于JVM将方法内联，可以改善编译器进行条件编译的能力等等。坦白说，很多类似的结论都是基于假设得出的，
   比如现代高性能JVM(如HotSpot)判断内联未必依赖final的提示。final字段对性能的影响，大部分情况下并没有考虑的必要。在日常开发中，除非有特别的考虑，不然最好不要指望这种小技巧带来的所谓性能好处。

二、finally是保证Java重点代码一定要执行的一种机制。我们可以使用try-finally或者try-catch-finally来进行类似JDBC连接、保证解锁等动作。需要注意下面这种代码会输出什么内容。

   try {
         // do something
         System.exit(1);
     } finally{
         System.out.println("Print from finally");
     }

三、finalize是基础类java.lang.object的一个方法，它的设计目的是保证对象在垃圾收集前完成特定资源的回收。finalize机制现在已经不推荐使用，并且在JDK9中被标记为Deprecated。
finalize存在的问题：
(1)finalize的执行是和垃圾收集关联在一起的，一旦实现了非空的finalize方法，就会导致对象回收呈现数量级的变慢。因为finalize被设计成对象被垃圾回收之前调用，这就意味着实现了finalize方法的对象是个
"特殊公民"，JVM要对他进行额外的处理。finalize本质上成为了快速回收的阻碍者，可能导致对象会经过多个垃圾收集周期才能回收。
(2)finalize还会掩盖资源回收时的出错信息，java.lang.ref.Finalizer类的源码如下所示，这就意味着一旦出现异常或者错误，应用得不到任何有效的错误信息。

    private void runFinalizer(JavaLangAccess jla) {
        synchronized (this) {
            if (hasBeenFinalized()) return;
            remove();
        }
        try {
            Object finalizee = this.get();
            if (finalizee != null && !(finalizee instanceof java.lang.Enum)) {
                jla.invokeFinalize(finalizee);

                /* Clear stack slot containing this variable, to decrease
                   the chances of false retention with a conservative GC */
                finalizee = null;
            }
        } catch (Throwable x) { }
        super.clear();
    }

(3)java.lang.Object#finalize方法注释写到，finalize方法引起的任何异常都会导致此对象的回收被停止，这可能会导致内存泄漏的问题。

     * Any exception thrown by the {@code finalize} method causes
     * the finalization of this object to be halted, but is otherwise
     * ignored.
     *
     * @throws Throwable the {@code Exception} raised by this method
     * @see java.lang.ref.WeakReference
     * @see java.lang.ref.PhantomReference
     * @jls 12.6 Finalization of Class Instances
     */
    protected void finalize() throws Throwable { }

(4)有什么机制可以替换finalize吗？
Java平台目前正在逐步使用java.lang.ref.Cleaner来替换掉原有的finalize实现。Cleaner的实现利用了幻想引用，这是一种常见的所谓post-mortem清理机制，利用幻想引用和引用队列，我们可以保证对象被彻底晓辉之前做一些类似于资源回收的工作，比如关闭文件描述符等操作系统有限的资源，它比finalize更加轻量、更加可靠。Cleaner的操作都是独立的，它有自己的运行线程，所以可以避免意外死锁等问题。下面是JDK提供的样例程序：

public class CleaningExample implements AutoCloseable {
        // A cleaner, preferably one shared within a library
        private static final Cleaner cleaner = ;
        static class State implements Runnable { 
            State(...) {
                // initialize State needed for cleaning action
            }
            public void run() {
                // cleanup action accessing State, executed at most once
            }
        }
        private final State;
        private final Cleaner.Cleanable cleanable
        public CleaningExample() {
            this.state = new State(...);
            this.cleanable = cleaner.register(this, state);
        }
        public void close() {
            cleanable.clean();
        }
    }

从可预测性的角度来判断，Cleaner或者幻想引用改善的程度仍然是有限的，如果由于种种原因导致幻想引用堆积，同样会出现问题。所以，Cleaner适合作为最后一种保证手段，而不是完全依赖Cleaner进行资源回收。资源用完就显式释放才是比较安全的。