try catch finally return的执行顺序

          在代码编写中，为了防止出现并发情况，我们一般都设置一个key和value值，然后在最后再将这个值移除，比如在redis中设置一个值，然后判断他存在不存在，存在则不走业务逻辑。又比如在执行加锁和释放锁的过程中，我们经常会这样写：

public void contextLoads() {
   Lock lock=new ReentrantLock();
   try {
      lock.lock();

   } catch (Exception e) {
      e.printStackTrace();
   }finally {
      lock.unlock();
   }
}

         我们在finally中写lock.unlock()是为了释放锁，为了保证在获取到锁之后，能够最终释放锁。但是它真的在任何情况下都能够释放吗？正常情况下，在jvm启动的时候，finally代码一定会执行的。当然遇到断电、假如是redis中存放key值为获取或者释放锁，redis挂掉都是不会执行finally的，或者说会抛出异常。那么tomcat执行shutdown命令后呢？这个场景是经常出现的，比如我们要上线，需要将tomcat执行shutdown命令，而代码正好执行完了获取锁，这个时候tomcat的守护线程会把它执行完毕的。

         在try中写lock.lock()是否合适？当然了，假如是一个简单获取锁的代码，几乎是没有问题的，但是假如是自定义锁，在获取的过程中出现了异常，则执行finally的时候，lock.unlock()也会发生异常。

         当在try中出现了异常，会走finally吗？必须会走啊。

         加上return，我们看一下返回值。

      finally是最后走的，所以无论是try中有return还是catch中有return，都是不管用的，肯定走finally的return

       假如在方法test()的最后加上一个return呢？这样肯定编译不通过啊。 

     因为在finally中已经有了return了，而且程序最后走的是finally的return，出现了多个return情况，系统编译不通过。

     假如把finally中的return删除，则仍然编译不通过的，因为try和catch中已经有了return，出现了情况都有return可走，所以最后的 return “最后的返回” 是多余的。

                                           

       假如是上图的情况，仅仅catch中有return（或者仅仅是try中有return），在方法test()的最后也有return，那么在出现异常的时候直接返回catch的return，假如任何一个分支没有return的情况下，会走最后的return。那么会走finally吗？finally是在return之前执行的。执行结果如下：

 

        回顾基础，知其然必知其所以然。