这是因为您将i的值指定为12，但没有将i的返回给函数。正确的代码如下：

public static int test() {
    int i = 0;
    try {
        return i;
    } finally {
        i = 12;
        System.out.println("finally trumps return.");
        return i;
    }
}

此外，finally的返回将丢弃任何异常。http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

考虑以下程序：

public class SomeTest {

    private static StringBuilder sb = new StringBuilder();

    public static void main(String args[]) {

        System.out.println(someString());
        System.out.println("---AGAIN---");
        System.out.println(someString());
        System.out.println("---PRINT THE RESULT---");
        System.out.println(sb.toString());
    }

    private static String someString() {

        try {
            sb.append("-abc-");
            return sb.toString();

        } finally {
            sb.append("xyz");
        }
    }
}

从Java 1.8.162开始，上述代码块提供以下输出：

-abc-
---AGAIN---
-abc-xyz-abc-
---PRINT THE RESULT---
-abc-xyz-abc-xyz

这意味着使用finally释放对象是一种很好的做法，如以下代码所示：

private static String someString() {

    StringBuilder sb = new StringBuilder();

    try {
        sb.append("abc");
        return sb.toString();

    } finally {
        sb = null; // Just an example, but you can close streams or DB connections this way.
    }
}

是的，写在这里

如果在执行try或catch代码时JVM退出，那么finally块可能不会执行。同样，如果执行try或catch代码的线程被中断或终止，那么即使整个应用程序继续运行，finally块也可能不会执行。

公认的答案在几乎所有方面都是正确的，但它仍然只是事实的一半（好吧，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块始终正常终止，否则它是否始终被执行可能无关紧要…

我很晚才回答，但我很惊讶没有人提到Java调试器选项来删除堆栈帧。我是IntelliJ中此功能的重度用户。（我确信Eclipse和NetBeans支持相同的功能。）

如果我从后面跟着finally块的try或catch块中删除堆栈帧，IDE将提示我：“我要执行finally块吗？”显然，这是一个人工运行时环境——调试器！

为了回答您的问题，我想说，只有在连接调试器时忽略，并且（就像其他人所说的）method something（）不（a）通过JNI调用Java方法System.exit（int）或（b）C函数exit（int/abort（），或（C）对自身执行类似于调用kill-9$PID（！）的疯狂操作时，才能保证它运行。