如果在嵌套的finally块中引发异常，finally也可以提前退出。编译器会警告你finally块没有正常完成，或者给出一个错误，说明你有无法访问的代码。仅当抛出不在条件语句后面或循环内部时，才会显示不可访问代码的错误。

try{
}finally{
   try{
   }finally{
      //if(someCondition) --> no error because of unreachable code
      throw new RunTimeException();
   }
   int a = 5;//unreachable code
}

这就是最后一块的全部想法。当然，它可以让你确保你做了清理，否则可能会因为你回来而被跳过。

不管try块中发生了什么，最终都会被调用（除非您调用System.exit（int）或Java虚拟机因其他原因退出）。

如果不处理异常，在终止程序之前，JVM将执行finally块。仅当程序的正常执行因以下原因而失败时，才会执行程序。。

通过导致导致进程中止的致命错误。由于内存损坏，程序终止。通过调用System.exit（）如果程序进入无限循环。

公认的答案在几乎所有方面都是正确的，但它仍然只是事实的一半（好吧，95%的事实）。

假设以下代码：

private final Lock m_Lock = new ReentrantLock();
…
public final SomeObject doSomething( final SomeObject arg )
{
  final SomeObject retValue;
  try
  {
    lock.lock();
    retValue = SomeObject( arg );
  }
  finally
  {
    out.println( "Entering finally block");
    callingAnotherMethod( arg, retValue );
    lock.unlock();
  }
  
  return retValue;
}
…
try
{
   final var result = doSomething( new SomeObject() );
}
catch( final StackOverflowError e ) { /* Deliberately ignored */ }

调用doSomething（）方法将几乎立即导致StackOverflowError。

锁也不会松开！

但是，当finally块总是被执行时（接受的答案中已经列出了例外情况），这怎么会发生呢？

这是因为不能保证finally块中的所有语句都真正执行！

如果在调用lock.unlock（）之前调用System.exit（）或throws语句，这将是显而易见的。

但示例代码中没有类似的内容…

除此之外，调用lock.unlock（）之前finally块中的另外两个方法调用将导致另一个StackOverflowError…

瞧，锁没有松开！

虽然这样的示例代码很愚蠢，但在许多类型的软件中都可以找到类似的模式。只要最后一个街区没有发生什么丑恶的事情，一切都会好起来的…

有趣的事实是，它在Java的更高版本中不起作用（这意味着在更高的版本中，锁被释放了…）。不知道何时以及为什么会发生变化。

但您仍然必须确保finally块始终正常终止，否则它是否始终被执行可能无关紧要…

即使在try块中放入return语句，也始终执行finally块。finally块将在return语句之前执行。

在两种独特的情况下，返回后不会调用finally块：如果首先调用System.exit（），或者JVM崩溃。

让我尽量用最简单的方式回答你的问题。

规则1：finally块始终运行（虽然有例外。但让我们坚持一段时间。）

规则2：当控件离开try或catch块时，finally块中的语句会运行。控制权的转移可能是正常执行、break、continue、goto或return语句的执行或异常传播的结果。

在返回语句的情况下（由于其标题），控件必须离开调用方法，因此调用相应try finally结构的finally块。return语句在finally块之后执行。

如果finally块中也有return语句，它肯定会覆盖try块中挂起的语句，因为它会清除调用堆栈。

您可以在此处找到更好的解释：http://msdn.microsoft.com/en-us/....这一概念在所有高级语言中基本相同。