Historia pytania
Temat ten wywodzi się z ewolucji Pythona od czystego liczenia referencji do hybrydowego modelu zbierania śmieci, wprowadzonego w Pythonie 2.0. Główny problem pojawił się, gdy deweloperzy używali metod finalizujących (__del__) do zarządzania zewnętrznymi zasobami, takimi jak uchwyty plików czy gniazda sieciowe. Kiedy obiekty z metodami finalizującymi tworzyły cykliczne odniesienia, Python nie mógł ustalić bezpiecznej kolejności zniszczenia, co mogło prowadzić do awarii lub wycieków zasobów. To ograniczenie doprowadziło do wdrożenia modułu cyklicznego zbierania śmieci (gc) oraz specjalnego traktowania „niezbieralnych” śmieci.
Problem
Gdy grupa obiektów tworzy cykl odniesień, a przynajmniej jeden z nich definiuje niestandardową metodę __del__, Python staje przed dylematem określającej destrukcji. Interpreter nie może zdecydować, który obiekt sfinalizować jako pierwszy, ponieważ cykl implikuje wzajemną zależność, a zniszczenie jednego może pozostawić inne w nieprawidłowym stanie. W związku z tym Python przenosi te obiekty do listy gc.garbage zamiast zwalniać ich pamięć. To zachowanie utrzymuje się w nowoczesnych wersjach, gdy finalizatory zapobiegają bezpiecznemu zbieraniu, co prowadzi do stopniowych wycieków pamięci w długoterminowych aplikacjach.
Rozwiązanie
Ostatecznym rozwiązaniem jest całkowite unikanie metod __del__ na rzecz menedżerów kontekstu (with) lub wywołań weakref do czyszczenia zasobów. Jeżeli finalizatory są nieuniknione, należy jawnie przerywać cykle odniesień, ustawiając zmienne instancyjne na None w metodach czyszczenia. Począwszy od Pythona 3.4, zbieracz śmieci może zbierać cykle z finalizatorami w wielu przypadkach, przy staranny porządkując finalizację, ale jawne zarządzanie zasobami pozostaje najbardziej niezawodnym wzorcem.
import gc class Resource: def __init__(self, name): self.name = name self.peer = None def __del__(self): print(f"Czyszczenie {self.name}") # Tworzenie cyklu z finalizatorami a = Resource("A") b = Resource("B") a.peer = b b.peer = a # Usunięcie zewnętrznych odniesień del a, b gc.collect() print(f"Nie do zebrani: {gc.garbage}") # Może zawierać obiekty w złożonych scenariuszach
Utrzymywaliśmy odpowiedzialną na dużą przepustowość pipeline do przetwarzania danych, w którym obiekty Node reprezentowały kroki obliczeniowe w grafie. Każdy węzeł przechowywał odniesienia do swoich sąsiadów i zawierał metodę __del__, aby zwolnić uchwyty pamięci GPU. Podczas intensywnej pracy zaobserwowaliśmy monotoniczny wzrost pamięci, mimo że w profilowaniu nie było widocznych wycieków pamięci. Badania ujawniły, że złożone topologie grafów stworzyły cykle odniesień między węzłami, a obecność metod __del__ uniemożliwiła cyklicznemu GC odzyskanie tych obiektów, powodując ich gromadzenie się w gc.garbage aż do zakończenia procesu.
Rozwiązanie 1: Refaktoryzacja do menedżerów kontekstu
Rozważaliśmy zastąpienie __del__ jawnie wywoływanymi metodami acquire() i release(), wywoływanymi za pomocą menedżerów kontekstu. To podejście całkowicie eliminowałoby barierę finalizatora dla zbierania śmieci i zapewniałoby deterministyczne czyszczenie zasobów. Jednak wymagało to modyfikacji tysięcy linii kodu konstrukcji grafów i niosło ryzyko wycieków zasobów, jeśli deweloperzy zapomnieliby o otoczeniu używania węzłów w blokach with, szczególnie w komponentach opartych na zdarzeniach.
Rozwiązanie 2: Wdrożenie słabych odniesień dla krawędzi grafu
Zbadaliśmy możliwość zmiany wszystkich odniesień sąsiadów na obiekty weakref.ref, co pozwoliłoby węzłom zostać zebranym natychmiast, gdy nie pozostały zewnętrzne odniesienia, niezależnie od spójności grafu. Choć eleganckie, wprowadziło to znaczną złożoność, ponieważ algorytmy przeszukiwania grafów musiały nieustannie sprawdzać martwe słabe odniesienia i obsługiwać przejrzyste „duchy” podczas iteracji. To podejście znacząco pogorszyło wydajność w naszym przypadku i wymagało szerokiej refaktoryzacji logiki przeszukiwania grafów.
Rozwiązanie 3: Jawne przerywanie cykli za pomocą protokołu czyszczenia
Wdrożyliśmy metodę destroy(), która jawnie ustawiła self.neighbors = [] oraz self.gpu_handle = None przed usunięciem węzłów z grafu. To deterministycznie przerywało cykle, zachowując jednocześnie istniejący interfejs API. Wybraliśmy to rozwiązanie, ponieważ lokalizowało zmiany w logice usuwania węzłów zamiast rozprzestrzeniać problemy w całym kodzie, a także utrzymywało zgodność wstecz z istniejącymi algorytmami grafowymi.
Wynik
Po wdrożeniu protokołu jawnego czyszczenia i dodaniu asercji, aby potwierdzić, że gc.garbage pozostało puste podczas testowania CI, zużycie pamięci ustabilizowało się na stałym poziomie. Usługa działała przez tygodnie bez wcześniej występującego stopniowego nagromadzenia pamięci. Udokumentowaliśmy również ten wzór, aby zapewnić, że przyszli deweloperzy zrozumieli interakcję między finalizatorami a cyklicznymi odniesieniami.
Dlaczego gc.garbage wciąż zawiera obiekty w Pythonie 3.4+, nawet gdy finalizatory są obecne w cyklach?
Podczas gdy Python 3.4 znacząco poprawił cykliczny GC, aby obsługiwać finalizatory, wywołując je w bezpiecznej kolejności i czyszcząc odniesienia po, obiekty mogą nadal pojawiać się w gc.garbage w określonych warunkach. Jeśli metoda __del__ ożywia obiekt, przechowując go w zmiennej globalnej, GC nie może bezpiecznie usunąć cyklu i przenosi go do gc.garbage, aby zapobiec niekończącym się pętlom. Dodatkowo, obiekty rozszerzeń C z niestandardowymi slotami tp_dealloc, które nie wspierają prawidłowo protokołu cyklicznego GC, mogą być traktowane jako niezbieralne, aby uniknąć awarii w kodzie natywnym.
Jak weakref.ref z wywołaniem zwrotnym wchodzi w interakcję z cyklicznym zbieraczem śmieci, gdy referent jest częścią cyklu, którego nie można zebrać?
Kandydaci często błędnie zakładają, że wywołania zwrotne słabych odniesień są wywoływane natychmiast po tym, jak obiekt staje się niedostępny. W rzeczywistości wywołanie zwrotne jest aktywowane, gdy obiekt jest rzeczywiście zniszczony i jego pamięć zwolniona. Jeśli obiekt uczestniczy w cyklu odniesień zawierającym finalizatory, których GC nie może przerwać, obiekt pozostaje przydzielony w gc.garbage, a wywołanie zwrotne słabego odniesienia nigdy nie jest wykonywane. Ta różnica jest kluczowa dla projektowania systemów czyszczenia zasobów, które polegają na wywołaniach zwrotnych słabych odniesień w celu powiadamiania o zniszczeniu obiektu.
Czym jest problem „wskrzeszenia” w metodach __del__ i jak uniemożliwia on zbieranie śmieci cyklicznych odniesień?
Wskrzeszenie występuje, gdy metoda finalizująca przypisuje umierającą instancję do zmiennej globalnej lub umieszcza ją w trwałym kontenerze, efektywnie przywracając ją po tym, jak GC oznaczył ją do zniszczenia. W scenariuszu cyklicznego odniesienia, jeśli __del__ jednego obiektu wskrzesza jakikolwiek obiekt z cyklu, cały cykl staje się znowu dostępny. Zbieracz śmieci Pythona wykrywa tę anomalię i przenosi cały cykl do gc.garbage, zamiast próbować rozwiązać potencjalnie nieskończoną pętlę zniszczenia i wskrzeszenia, pozostawiając pamięć nieprzywróconą aż do zakończenia procesu.