Biorąc pod uwagę ten kod, czy mogę być absolutnie pewien, że finallyblok zawsze wykonuje się, bez względu na to, co something()jest?

try {  
    something();  
    return success;  
}  
catch (Exception e) {   
    return failure;  
}  
finally {  
    System.out.println("I don't know if this will get printed out");
}

Tak, finallyzostanie wywołany po wykonaniu bloków trylub catchkodu.

Jedyne czasy, finallyktóre nie zostaną wywołane, to:

1. Jeśli się odwołujesz System.exit()
2. Jeśli się odwołujesz Runtime.getRuntime().halt(exitStatus)
3. Jeśli JVM ulegnie awarii w pierwszej kolejności
4. Jeśli JVM osiągnie nieskończoną pętlę (lub inną nieprzekraczalną, nie kończącą się instrukcję) w bloku trylubcatch
5. Jeśli system operacyjny siłą zakończy proces JVM; np. kill -9 <pid>w systemie UNIX
6. Jeśli system hosta umrze; np. awaria zasilania, błąd sprzętowy, panika systemu operacyjnego itp
7. Jeśli finallyblok ma być wykonywany przez wątek demona, a wszystkie inne wątki inne niż demony wychodzą przed finallywywołaniem

Przykładowy kod:

public static void main(String[] args) {
    System.out.println(Test.test());
}

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

Wynik:

finally trumps return. 
0

Ponadto, chociaż jest to zła praktyka, jeśli w ostatnim bloku znajduje się instrukcja return, przewyższy ona każdy inny zwrot ze zwykłego bloku. Oznacza to, że następujący blok zwróciłby wartość false:

try { return true; } finally { return false; }

To samo dotyczy rzucania wyjątków od bloku w końcu.

Oto oficjalne słowa ze specyfikacji języka Java.

14.20.2. Wykonanie try-wreszcie i try-catch-wreszcie

trySprawozdanie z finallybloku jest wykonywany przez pierwsze wykonanie trybloku. Potem jest wybór:

• Jeśli wykonanie trybloku zakończy się normalnie, [...]
• Jeśli wykonanie trybloku zakończy się nagle z powodu throwwartości V , [...]
• Jeśli wykonanie trybloku zakończy się nagle z jakiegokolwiek innego powodu R , wówczas finallyblok zostanie wykonany. Potem jest wybór:
  • Jeżeli wreszcie blokować normalnym zakończeniu, wówczas tryoświadczenie kończy się nagle z przyczyn R .
  • Jeśli finallyblok kończy się nagle z powodu S , wówczas tryinstrukcja kończy się nagle z powodu S ( i powód R jest odrzucany ).

Specyfikacja dla returntego wyraźnie wyjaśnia:

JLS 14.17 Deklaracja zwrotu

ReturnStatement:
     return Expression(opt) ;

returnOświadczenie bez Expression prób , aby przekazać kontrolę do wywołującego metody lub konstruktora, który go zawiera.

returnWraz z uzupełniającą Expression prób do przekazywania sterowania do wywołującego sposobu, który go zawiera; wartość parametru Expressionstaje się wartością wywołania metody.

Poprzednie opisy mówią „ próby przekazania kontroli ”, a nie tylko „ przekazywanie kontroli ”, ponieważ jeśli tryw metodzie lub konstruktorze są jakieś instrukcje, których trybloki zawierają returninstrukcję, wówczas wszelkie finallyklauzule tych tryinstrukcji zostaną wykonane w kolejności od najbardziej do najbardziej zewnętrznej , przed przekazaniem kontroli do wywołującego metodę lub konstruktora. Nagłe wypełnienie finallyklauzuli może zakłócić przekazanie kontroli zainicjowane przez returnoświadczenie.

Oprócz innych odpowiedzi ważne jest, aby zaznaczyć, że „w końcu” ma prawo nadpisać wszelkie wyjątki / zwrócone wartości przez blok try..catch. Na przykład następujący kod zwraca 12:

public static int getMonthsInYear() {
    try {
        return 10;
    }
    finally {
        return 12;
    }
}

Podobnie poniższa metoda nie zgłasza wyjątku:

public static int getMonthsInYear() {
    try {
        throw new RuntimeException();
    }
    finally {
        return 12;
    }
}

Podczas gdy następująca metoda go wyrzuca:

public static int getMonthsInYear() {
    try {
        return 12;          
    }
    finally {
        throw new RuntimeException();
    }
}

Próbowałem powyższy przykład z niewielką modyfikacją

public static void main(final String[] args) {
    System.out.println(test());
}

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

Powyższy kod generuje:

wreszcie atuty wracają.
2)

Wynika to z tego, że kiedy return i;jest wykonywany, ima wartość 2. Po tym finallywykonywany jest blok, do którego przypisano 12, ia następnie System.outwykonywany jest out.

Po wykonaniu finallybloku tryblok zwraca 2 zamiast 12, ponieważ ta instrukcja return nie jest wykonywana ponownie.

Jeśli będzie debugowania tego kodu w Eclipse wtedy dostaniesz wrażenie, że po wykonaniu System.outz finallyblokowania returnoświadczenie trybloku jest ponownie wykonywane. Ale tak nie jest. Zwraca po prostu wartość 2.

Oto opracowanie odpowiedzi Kevina . Ważne jest, aby wiedzieć, że wyrażenie, które ma zostać zwrócone, jest oceniane wcześniej finally, nawet jeśli jest zwracane później.

public static void main(String[] args) {
    System.out.println(Test.test());
}

public static int printX() {
    System.out.println("X");
    return 0;
}

public static int test() {
    try {
        return printX();
    }
    finally {
        System.out.println("finally trumps return... sort of");
    }
}

Wynik:

X
finally trumps return... sort of
0

To cała idea ostatecznego bloku. Pozwala upewnić się, że robisz porządki, które w przeciwnym razie mogą zostać pominięte, ponieważ wracasz, między innymi, oczywiście.

W końcu zostaje wywołany niezależnie od tego, co dzieje się w bloku try ( chyba że zadzwonisz System.exit(int)lub maszyna wirtualna Java zostanie uruchomiona z innego powodu).

Logicznym sposobem myślenia na ten temat jest:

1. Kod umieszczony w bloku ostatecznie musi zostać wykonany niezależnie od tego, co wystąpi w bloku try
2. Jeśli więc kod w bloku try spróbuje zwrócić wartość lub zgłosić wyjątek, przedmiot jest umieszczany „na półce”, aż blok w końcu będzie mógł wykonać
3. Ponieważ kod w ostatnim bloku ma (z definicji) wysoki priorytet, może zwrócić lub wyrzucić, co tylko zechce. W takim przypadku wszystko, co pozostało „na półce”, jest odrzucane.
4. Jedynym wyjątkiem jest sytuacja, gdy maszyna wirtualna wyłącza się całkowicie podczas bloku try, np. Przez „System.exit”

ostatecznie jest zawsze wykonywane, chyba że wystąpi nieprawidłowe zakończenie programu (np. wywołanie System.exit (0) ..). więc twój sysout zostanie wydrukowany

Również powrót w końcu odrzuci każdy wyjątek. http://jamesjava.blogspot.com/2006/03/dont-return-in-finally-clause.html

Ostatecznie blok jest zawsze wykonywany, chyba że wystąpi nienormalne zakończenie programu, wynikające z awarii JVM lub wywołania System.exit(0).

Ponadto, każda wartość zwrócona z bloku ostatecznie zastąpi wartość zwróconą przed wykonaniem bloku ostatecznie, więc należy uważać na wszystkie punkty wyjścia podczas korzystania z try wreszcie.

Nie, nie zawsze jeden wyjątek to // System.exit (0); zanim blok w końcu uniemożliwia w końcu wykonanie.

  class A {
    public static void main(String args[]){
        DataInputStream cin = new DataInputStream(System.in);
        try{
            int i=Integer.parseInt(cin.readLine());
        }catch(ArithmeticException e){
        }catch(Exception e){
           System.exit(0);//Program terminates before executing finally block
        }finally{
            System.out.println("Won't be executed");
            System.out.println("No error");
        }
    }
}

Wreszcie zawsze uruchamiane jest to o to chodzi, tylko dlatego, że pojawia się w kodzie po powrocie, nie oznacza, że ​​tak jest zaimplementowane. Środowisko wykonawcze Java jest odpowiedzialne za uruchomienie tego kodu podczas wychodzenia z trybloku.

Na przykład, jeśli masz następujące elementy:

int foo() { 
    try {
        return 42;
    }
    finally {
        System.out.println("done");
    }
}

Środowisko wykonawcze wygeneruje coś takiego:

int foo() {
    int ret = 42;
    System.out.println("done");
    return 42;
}

Jeśli zgłoszony zostanie nieprzechwycony wyjątek, finallyblok zostanie uruchomiony, a wyjątek będzie kontynuowany.

Jest tak, ponieważ przypisałeś wartość i jako 12, ale nie zwróciłeś wartości i do funkcji. Prawidłowy kod jest następujący:

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

Ponieważ ostatecznie blok będzie zawsze wywoływany, chyba że zadzwonisz System.exit()(lub wątek się zawiesi).

Krótko mówiąc, w oficjalnej dokumentacji Java (kliknij tutaj ) napisano, że -

Jeśli JVM zakończy działanie podczas wykonywania kodu try lub catch, blok w końcu może się nie uruchomić. Podobnie, jeśli wątek wykonujący kod try lub catch zostanie przerwany lub zabity, blok ostatecznie może nie zostać wykonany, nawet jeśli aplikacja jako całość będzie kontynuowana.

Odpowiedź jest prosta TAK .

WEJŚCIE:

try{
    int divideByZeroException = 5 / 0;
} catch (Exception e){
    System.out.println("catch");
    return;    // also tried with break; in switch-case, got same output
} finally {
    System.out.println("finally");
}

WYNIK:

catch
finally

Tak, zostanie wywołany. Taki jest sens posiadania wreszcie słowa kluczowego. Jeśli wyskakiwanie z bloku try / catch może po prostu pominąć blok ostatecznie, to to samo, co umieszczenie pliku System.out.println poza try / catch.

Tak, w końcu blok jest zawsze wykonywany. Większość programistów używa tego bloku do zamykania połączenia z bazą danych, obiektu wynikowego, obiektu instrukcji, a także używa hibernacji java do wycofania transakcji.

NIE ZAWSZE

Specyfikacja języka Java opisuje sposób try- catch- finallyi try- catchbloki pracują w 14.20.2
W żadnym miejscu nie określa, że finallyblok jest zawsze wykonywany. Jednak we wszystkich przypadkach, w których try- catch- finallyi try- finallybloki zakończyć to jednak określić, że przed zakończeniem finallymuszą być wykonywane.

try {
  CODE inside the try block
}
finally {
  FIN code inside finally block
}
NEXT code executed after the try-finally block (may be in a different method).

JLS nie gwarantuje wykonania FIN po kodzie . JLS gwarantuje, że jeśli zostaną wykonane KOD i NASTĘPNY, to FIN będzie zawsze wykonywany po KOD i przed NASTĘPNYM .

Dlaczego JLS nie gwarantuje, że finallyblok jest zawsze wykonywany po trybloku? Ponieważ to niemożliwe. Jest mało prawdopodobne, ale możliwe, że JVM zostanie przerwana (zabijanie, awaria, wyłączenie zasilania) tuż po ukończeniu trybloku, ale przed wykonaniem finallybloku. JLS nie może nic zrobić, aby tego uniknąć.

Zatem każde oprogramowanie, które dla ich prawidłowego zachowania zależy od finallybloków zawsze wykonywanych po ich tryukończeniu, jest błędne.

returninstrukcje w trybloku nie mają znaczenia dla tego problemu. Jeśli wykonanie osiągnie kod po try- catch- finallyjest zagwarantowane, że finallyblok zostanie wykonany przed returninstrukcją wewnątrz trybloku lub bez niego .

Tak, to będzie. Bez względu na to, co się stanie w bloku try lub catch, chyba że wywołano System.exit () lub JVM uległo awarii. jeśli w bloku (blokach) znajduje się jakaś instrukcja return, ostatecznie zostanie wykonana przed tą instrukcją return.

Tak, to będzie. Tylko, że tak nie będzie, JVM kończy działanie lub ulega awarii

Dodanie do odpowiedzi @ vibhash, ponieważ żadna inna odpowiedź nie wyjaśnia, co dzieje się w przypadku obiektu zmiennego, takiego jak ten poniżej.

public static void main(String[] args) {
    System.out.println(test().toString());
}

public static StringBuffer test() {
    StringBuffer s = new StringBuffer();
    try {
        s.append("sb");
        return s;
    } finally {
        s.append("updated ");
    }
}

Wyjdzie

sbupdated 

Próbowałem tego, jest to jednowątkowy.

public static void main(String args[]) throws Exception {
    Object obj = new Object();
    try {
        synchronized (obj) {
            obj.wait();
            System.out.println("after wait()");
        }
    } catch (Exception ignored) {
    } finally {
        System.out.println("finally");
    }
}

main ThreadBędzie na waitstanie na zawsze, a więc finallynigdy nie zostanie wywołana ,

więc wyjście konsoli nie będzie print String: po wait()lubfinally

Powyższy przykład, uzgodniony z @Stephen C, jest jedną z 3. wzmianek o przypadkach tutaj :

Dodanie kilku takich możliwości nieskończonej pętli w następującym kodzie:

// import java.util.concurrent.Semaphore;

public static void main(String[] args) {
    try {
        // Thread.sleep(Long.MAX_VALUE);
        // Thread.currentThread().join();
        // new Semaphore(0).acquire();
        // while (true){}
        System.out.println("after sleep join semaphore exit infinite while loop");
    } catch (Exception ignored) {
    } finally {
        System.out.println("finally");
    }
}

Przypadek 2: Jeśli JVM ulegnie awarii w pierwszej kolejności

import sun.misc.Unsafe;
import java.lang.reflect.Field;

public static void main(String args[]) {
    try {
        unsafeMethod();
        //Runtime.getRuntime().halt(123);
        System.out.println("After Jvm Crash!");
    } catch (Exception e) {
    } finally {
        System.out.println("finally");
    }
}

private static void unsafeMethod() throws NoSuchFieldException, IllegalAccessException {
    Field f = Unsafe.class.getDeclaredField("theUnsafe");
    f.setAccessible(true);
    Unsafe unsafe = (Unsafe) f.get(null);
    unsafe.putAddress(0, 0);
}

Ref: W jaki sposób zawiesisz JVM?

Przypadek 6: Jeśli finallyblok ma być wykonywany przez demona Threadi wszystkie inne Threadswyjścia inne niż demony przed finallywywołaniem.

public static void main(String args[]) {
    Runnable runnable = new Runnable() {
        @Override
        public void run() {
            try {
                printThreads("Daemon Thread printing");
                // just to ensure this thread will live longer than main thread
                Thread.sleep(10000);
            } catch (Exception e) {
            } finally {
                System.out.println("finally");
            }
        }
    };
    Thread daemonThread = new Thread(runnable);
    daemonThread.setDaemon(Boolean.TRUE);
    daemonThread.setName("My Daemon Thread");
    daemonThread.start();
    printThreads("main Thread Printing");
}

private static synchronized void printThreads(String str) {
    System.out.println(str);
    int threadCount = 0;
    Set<Thread> threadSet = Thread.getAllStackTraces().keySet();
    for (Thread t : threadSet) {
        if (t.getThreadGroup() == Thread.currentThread().getThreadGroup()) {
            System.out.println("Thread :" + t + ":" + "state:" + t.getState());
            ++threadCount;
        }
    }
    System.out.println("Thread count started by Main thread:" + threadCount);
    System.out.println("-------------------------------------------------");
}

wyjście: To nie drukuje „w końcu”, co sugeruje, że „W końcu blok” w „wątku demona” nie został wykonany

main Thread Printing  
Thread :Thread[My Daemon Thread,5,main]:state:BLOCKED  
Thread :Thread[main,5,main]:state:RUNNABLE  
Thread :Thread[Monitor Ctrl-Break,5,main]:state:RUNNABLE   
Thread count started by Main thread:3  
-------------------------------------------------  
Daemon Thread printing  
Thread :Thread[My Daemon Thread,5,main]:state:RUNNABLE  
Thread :Thread[Monitor Ctrl-Break,5,main]:state:RUNNABLE  
Thread count started by Main thread:2  
-------------------------------------------------  

Process finished with exit code 0

Rozważ następujący program:

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

Od wersji Java 1.8.162 powyższy blok kodu daje następujące dane wyjściowe:

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

oznacza to, że używanie finallydo zwalniania obiektów jest dobrą praktyką, taką jak następujący kod:

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.
    }
}

Tak naprawdę jest to prawdą w każdym języku ... w końcu zawsze będzie wykonywane przed instrukcją return, bez względu na to, gdzie zwrot ten znajduje się w treści metody. Gdyby tak nie było, blok w końcu nie miałby większego znaczenia.

Oprócz kwestii powrotu do ostatecznego zastąpienia zwrotu w bloku try, to samo dotyczy wyjątku. Wreszcie blok, który zgłasza wyjątek, zastąpi zwrot lub wyjątek zgłoszony z bloku try.

finally wykona się i to na pewno.

finally nie będzie działać w poniższych przypadkach:

przypadek 1 :

Podczas wykonywania System.exit().

przypadek 2:

Gdy następuje awaria JVM / wątku.

przypadek 3:

Gdy wykonanie zostanie zatrzymane pomiędzy nimi ręcznie.

1. W końcu Blok zawsze jest wykonywany. Chyba że i do System.exit () nie istnieje instrukcja (pierwsza instrukcja w końcu blok).
2. Jeśli system.exit () jest pierwszą instrukcją, to w końcu blok nie zostanie wykonany, a kontrola wyjdzie z bloku w końcu. Ilekroć instrukcja System.exit () dostaje się w końcu do bloku, aż ta instrukcja w końcu zostanie wykonana i kiedy pojawi się System.exit (), wtedy siła sterująca w pełni wychodzi z bloku w końcu.