Historia: Przed Javą 7 zarządzanie zasobami opierało się na rozbudowanych konstrukcjach try-catch-finally, w których deweloperzy ręcznie wywoływali close() w blokach finally. Ten wzorzec okazał się podatny na błędy, zwłaszcza gdy mowa o obsłudze wielu zasobów lub wyjątków wyrzucanych podczas sprzątania. W Javie 7 wprowadzono instrukcję try-with-resources dzięki Project Coin, której kompilator tłumaczy na wyrafinowany bajtkod, który automatyzuje zamykanie zasobów, zachowując integralność łańcucha wyjątków.
Problem: Gdy wiele zasobów implementuje AutoCloseable, JVM musi zapewnić zamknięcie w odwrotnej kolejności inicjacji, aby uszanować hierarchie zależności. Na przykład strumień wyjściowy opakowujący strumień plikowy musi być zamykany jako pierwszy, aby opróżnić bufory. Dodatkowo, jeśli zarówno blok try, jak i metoda close() wyrzucają wyjątki, specyfikacja nakazuje, aby główny wyjątek z bloku był propagowany, podczas gdy wyjątek związany z sprzątaniem jest dołączany jako wyjątek tłumiony poprzez Throwable.addSuppressed(). To wymaga, aby kompilator generował syntetyczne bloki try-catch wokół każdego zamknięcia zasobu i zarządzał zmiennymi tymczasowymi do przechowywania wyjątków.
Rozwiązanie: Kompilator przekształca try-with-resources w podstawowy blok try zawierający oryginalną logikę, a następnie serię zagnieżdżonych bloków finally — jeden na każdy zasób — które zamykają zasoby w kolejności LIFO. Dla każdego zasobu kompilator generuje bajtkod, który przechwytuje Throwable, przechowuje go w syntetycznej zmiennej, wywołuje close(), a jeśli close() wyrzuca, wywołuje addSuppressed() na przechwyconym wyjątku przed ponownym wyrzuceniem. W Javie 9+ kompilator również obsługuje skutecznie finalne zasoby, opakowując je w tymczasowe syntetyczne zmienne, aby zapewnić dostępność w generowanych blokach sprzątania.
// Kod źródłowy public String readFirstLine(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } } // Koncepcyjna transformacja bajtkodu public String readFirstLine(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); Throwable primaryException = null; try { return br.readLine(); } catch (Throwable t) { primaryException = t; throw t; } finally { if (br != null) { if (primaryException != null) { try { br.close(); } catch (Throwable suppressed) { primaryException.addSuppressed(suppressed); } } else { br.close(); } } } }
Mieliśmy incydent produkcyjny, w którym wycieki połączeń z bazą danych występowały okresowo pod dużym obciążeniem w usłudze zarządzania zapasami. Kod bazowy korzystał z ręcznych konstrukcji try-catch-finally, w których deweloperzy wywoływali close() w blokach finally, ale te implementacje nie miały odpowiedniej obsługi wyjątków dla samych operacji sprzątania. Kiedy close() wyrzucało wyjątki, oryginalny SQLException z logiki biznesowej był tracony, maskując przyczyny źródłowe i uniemożliwiając prawidłowy zwrot do puli połączeń.
Pierwsza strategia naprawcza, którą rozważano, polegała na wzmocnieniu ręcznych wzorców sprzątania poprzez rygorystyczne przeglądy kodu i narzędzia analizy statycznej, takie jak SonarQube. To podejście wymagało, aby deweloperzy pisali defensywny kod, owijając każde wywołanie close() w zagnieżdżonych blokach try-catch w celu tłumienia wyjątków wtórnych, ale nadal pozostawało podatne na błędy podczas szybkich cykli rozwoju i wprowadzało znaczną ilość szablonów, co utrudniało czytelność. Ostatecznie odrzuciliśmy to, ponieważ ludzka nadzór nie mógł zapewnić konsekwentnej aplikacji w rosnącej bazie kodu.
Druga strategia oceniła narzędzie Closer z pakietu Guava, które oferuje płynne API do rejestrowania zasobów i automatycznie zarządza kolejnością zamknięcia. Choć Closer poprawnie obsługuje tłumienie wyjątków i sprzątanie w odwrotnej kolejności, wprowadziło dużą zewnętrzną zależność do mikroserwisu próbującego zminimalizować swoją wielkość, i wymagało refaktoryzacji typów wyjątków do uwzględnienia specyficznego dla Closer typu wyjątków. Postanowiliśmy nie korzystać z tego z powodu wagi zależności i nietypowych wzorców obsługi wyjątków, które to narzędzie narzucało.
Trzecie podejście przeniosło wszystko do standardowych instrukcji try-with-resources, wykorzystując bajtkod generowany przez kompilator w celu zautomatyzowania sprzątania. To rozwiązanie wyeliminowało ręczne szablony, zapewniło kolejność zamykania LIFO dzięki syntetycznym blokom bajtkodu i automatycznie zachowało hierarchie wyjątków poprzez Throwable.addSuppressed() bez konieczności wymogu zależności bibliotecznych. Wybraliśmy to podejście, ponieważ dotykało przyczyny źródłowej na poziomie kompilatora, zmniejszało złożoność kodu o około trzysta linii i było zgodne z nowoczesnymi najlepszymi praktykami Javy.
Po migracji, wycieki połączeń spadły do zera w monitoringu produkcji, a wydajność debugowania poprawiła się dramatycznie, ponieważ inżynierowie mogli teraz zobaczyć oryginalny SQLException z awariami sprzątania dołączonymi jako tłumione ślady. Usługa osiągnęła kompatybilność z deployem bez przestojów, ponieważ gwarancje na poziomie bajtkodu działały konsekwentnie w różnych wersjach JVM bez zmian w konfiguracji czasie działania.
Jak try-with-resources radzi sobie z wyjątkami wyrzucanymi przez metodę close(), gdy blok try kończy się normalnie?
Gdy blok try wykonuje się bez wyrzucania, generowany przez kompilator blok finally wywołuje close() na każdym zasobie. Jeśli close() wyrzuca wyjątek, ten wyjątek staje się głównym wyjątkiem propagowanym do wywołującego, ponieważ nie istnieje wcześniejszy wyjątek do tłumienia. JVM nie owija ani nie odrzuca tego wyjątku; propaguje go dokładnie tak, jak został wyrzucony, co potencjalnie przerywa dalsze zamykanie zasobów w łańcuchu. Zrozumienie tej różnicy jest kluczowe, ponieważ wyjaśnia, dlaczego implementacje zasobów muszą zapewnić, że close() pozostaje idempotentne i minimalnie inwazyjne, ponieważ błąd w close() może zamaskować pomyślne zakończenie logiki biznesowej.
Dlaczego zasoby muszą być zamykane w odwrotnej kolejności inicjacji i jaki mechanizm bajtkodu to egzekwuje?
Zasoby często wykazują zależności enkapsulacyjne, w których zewnętrzne opakowania (jak BufferedWriter) przechowują odwołania do podległych strumieni (jak FileOutputStream). Zamknięcie podległego strumienia jako pierwszego pozostawiłoby opakowanie w niespójnym stanie, potencjalnie tracąc dane buforowane lub powodując IOException, gdy opakowanie próbuje opróżnić. Kompilator egzekwuje zamykanie w odwrotnej kolejności (LIFO), generując zagnieżdżone bloki finally, gdzie najbliższy blok finally (odpowiadający ostatnio zadeklarowanemu zasobowi) wykonuje się przed zewnętrznymi blokami finally. Ta struktura zapewnia, że BufferedWriter.close() opróżnia swój bufor do podległego strumienia przed tym, jak FileOutputStream.close() zwalnia uchwyt do pliku, zapobiegając utracie danych i uszkodzeniom zasobów.
Co zmieniło się w generacji bajtkodu między Javą 7 a Javą 9 w zakresie zakresu deklaracji zasobów?
Java 7 wymagała, aby zmienne zasobów zadeklarowane w nagłówku try były wyraźnie finalne, co ograniczało elastyczność przy potrzebie ponownego przypisania zasobów lub gdy były one pochodnymi złożonych wyrażeń. Java 9 poluzowała ten warunek, pozwalając na deklarowanie skutecznie finalnych zasobów na zewnątrz nagłówka try, ale kompilator nadal generuje syntetyczne zmienne do przechowywania odwołań wewnątrz generowanych bloków sprzątania. Konkretnie, jeśli zasób jest przypisany do zmiennej r na zewnątrz instrukcji try-with-resources, kompilator generuje bajtkod taki jak final AutoCloseable resource$1 = r;, aby upewnić się, że odniesienie pozostaje stabilne dla sprzątania, nawet jeśli oryginalna zmienna r jest później modyfikowana w zakresie (choć modyfikacja naruszyłaby status skutecznie finalny). To wstrzyknięcie zmiennej syntetycznej zapewnia, że kod sprzątania zawsze odnosi się do oryginalnej instancji obiektu, zapobiegając wyjątkowym błędom wskaźnikowym lub przestarzałym odniesieniom podczas wykonywania bloku finally.