Finalizatory zostały wprowadzone we wczesnych wersjach Go, aby oferować zabezpieczenie do zwalniania zewnętrznych zasobów, szczególnie podczas łączenia z bibliotekami C za pomocą cgo. Wzorowane na podobnych mechanizmach w Javie, runtime.SetFinalizer przypisuje funkcję do obiektu, która wykonuje się, gdy zbieracz śmieci stwierdzi, że nie ma żadnych odniesień. Jednak zespół Go konsekwentnie zniechęcał do ich użycia z powodu nieokreślonego czasu wykonania i skomplikowanej interakcji z fazami zbierania śmieci.
Finalizator działa asynchronicznie w dedykowanej goroutine tylko po tym, jak GC oznaczy obiekt jako niedostępny, co tworzy okno, w którym zasoby pozostają przydzielone dłużej niż to konieczne. Krytyczny problem pojawia się, kiedy finalizator ożywia swój obiekt, przechowując odniesienie w zmiennej globalnej lub żyjącym obiekcie, co ponownie czyni go dostępnym. Aby zapobiec nieskończonym pętliom finalizacji i wyczerpaniu zasobów, czas wykonania musi śledzić, że finalizator już się wykonał i wymusić obowiązkowy okres „cooldown” przed tym, jak jakakolwiek kolejna finalizacja może się odbyć.
Go gwarantuje, że finalizator wykona się dokładnie raz po pierwszym cyklu GC, w którym obiekt zostanie uznany za niedostępny, pod warunkiem, że program nie zakończy się przedwcześnie. Kiedy zachodzi ożywienie, czas wykonania usuwa związek z finalizatorem z wewnętrznego bufora szorującego, co wymaga wyraźnego nowego wywołania runtime.SetFinalizer, aby ponownie zarejestrować finalizator. Ten design zapewnia, że ożywione obiekty muszą przeżyć co najmniej jeden dodatkowy pełny cykl GC, aby wykazać, że znowu są rzeczywiście niedostępne, zanim następny finalizator może być zaplanowany.
typ Zasób struct { ptr unsafe.Pointer // pamięć C } func NowyZasób() *Zasób { r := &Zasób{ptr: C.malloc(1024)} // Finalizator działa, gdy r staje się niedostępny runtime.SetFinalizer(r, (*Zasób).Zakończ) return r } func (r *Zasób) Zakończ() { C.free(r.ptr) // Jeśli zrobiliśmy: global = r, ożywiliśmy r // Finalizator jest teraz odłączony; r potrzebuje kolejnego cyklu GC // i nowego wywołania SetFinalizer, aby ponownie zostać sfinalizowanym. }
Podczas budowania analityki czasu rzeczywistego, nasz zespół zintegrował zewnętrzną bibliotekę C do przyspieszonego hardwarowo szyfrowania z wykorzystaniem cgo, alokując wrażliwe bufory kluczy w pamięci sterty C. Polegaliśmy na runtime.SetFinalizer w strukturach opakowujących Go, aby automatycznie wywoływać funkcję C free(), gdy opakowania były zbierane. Podczas testów obciążeniowych zauważyliśmy sporadyczne błędy segmentacji, gdy kod Go próbował uzyskać dostęp do pamięci C, która została już zwolniona, mimo że odpowiadające obiekty Go były nadal aktywne w obsłudze żądań.
Analiza przyczyn źródłowych ujawniła, że nasza rama logowania, wywoływana w finalizatorze, uchwyciła wskaźnik do opakowania Go dla kontekstu błędów, niezamierzenie przywracając go do globalnego bufora pierścieniowego. Ponieważ finalizator Go działa równolegle z aplikacją, obiekt został ożywiony po zwolnieniu pamięci C, ale przed zakończeniem używania go przez obsługę żądań. Ten problem wyścigu spowodował scenariusz użycia po zwolnieniu, w którym ożywione obiekty trzymały wiszące wskaźniki C, co niespodziewanie powodowało awarię serwisu przy dużym obciążeniu.
Rozważyliśmy wdrożenie explictnej metody Close() z semantyką io.Closer, zachowując finalizator tylko jako zabezpieczenie przed wyciekiem. To podejście oferuje deterministyczne zarządzanie zasobami i jest zgodne z najlepszymi praktykami Go, zapewniając, że pamięć C jest zwalniana natychmiast po zakończeniu żądania. Jednak niesie ze sobą ryzyko podwójnego zwolnienia, jeśli zarówno Close(), jak i finalizator uruchomią się równolegle, i nadal nie zapobiega awariom, jeśli programiści zapomną wywołać Close() i finalizator ożywi obiekt.
Inną opcją było zastąpienie finalizatorów specjalnym rejestrem, używając adresów uintptr w sync.Map, aby śledzić wybitne alokacje bez zapobiegania zbieraniu śmieci. Ta metoda pozwala na explictne kontrolowanie monitorowania cyklu życia obiektów i całkowicie unika efektów ubocznych ożywienia. Niemniej jednak wymaga skomplikowanej ręcznej synchronizacji, okresowego skanowania mapy w poszukiwaniu przestarzałych wpisów i wiąże się z ryzykiem wycieków pamięci, jeśli sam rejestr nie jest starannie utrzymywany, co wprowadza znaczny narzut operacyjny.
Oceniliśmy także modyfikację finalizatorów w celu wykrywania ożywienia poprzez sprawdzanie, czy wskaźnik obiektu istnieje w dowolnej globalnej pamięci podręcznej przed zwolnieniem pamięci C, panikując w przypadku wykrycia. Choć ujawniłoby to błędy natychmiast podczas testów, nie rozwiązuje to podstawowego problemu zarządzania zasobami i spowodowałoby awarie produkcyjne zamiast łagodnej degradacji. Ponadto opiera się na drogich globalnych blokadach do sprawdzania stanu obiektu, znacznie wpływając na przepustowość wymaganą dla naszej wysokowydajnej analityki.
Ostatecznie całkowicie wyeliminowaliśmy finalizatory z kodu produkcyjnego, nakładając obowiązkowe wywołania Close() wymuszane przez instrukcje defer we wszystkich ścieżkach kodu. Aby zapobiec przedwczesnemu GC między ostatnim użyciem a wywołaniem Close(), dodaliśmy wywołania runtime.KeepAlive(obj) po krytycznych sekcjach używania pamięci C. Ta strategia usunęła nieokreślone zachowanie, wyeliminowała ryzyko ożywienia i dostosowała się do filozofii explictnego zarządzania zasobami Go, chociaż wymagała refaktoryzacji znacznych części bazy kodu, aby zapewnić, że Close() było zawsze osiągalne.
Po migracji błędy segmentacji całkowicie zniknęły, a użycie pamięci GPU stało się przewidywalne i liniowe w zależności od objętości żądań. Do systemu dodano statyczne analizy, aby wymuszać wywołania Close() na tych obiektach, wykrywając wycieki zasobów w czasie kompilacji. System obecnie obsługuje ponad 100k żądań na sekundę bez awarii związanych z pamięcią, co pokazuje, że explictne zarządzanie cyklem życia przewyższa podejścia oparte na finalizatorach w krytycznych usługach Go.
Dlaczego obiekt z finalizatorem może być odzyskany przez GC, gdy jego finalizator nadal się wykonuje i jak zapobiega temu runtime.KeepAlive?
Kandydaci często zakładają, że istnienie finalizatora utrzymuje docelowy obiekt przy życiu, dopóki finalizator nie zakończy pracy. W rzeczywistości, gdy tylko GC stwierdzi, że obiekt jest niedostępny, staje się on natychmiast kwalifikowany do zbierania, a finalizator jest planowany do uruchomienia w osobnej goroutine; obiekt może zostać odzyskany, zanim finalizator zakończy, jeśli nie ma innych odniesień. Aby temu zapobiec, runtime.KeepAlive(obj) powinno być wywołane po ostatnim użyciu obiektu, tworząc krawędź czasie kompilatora, która wydłuża okres życia obiektu do tego momentu, zapewniając, że zasoby C lub inne zależności pozostają ważne przez cały czas wykonania finalizatora.
Czy pojedynczy obiekt Go może mieć zarejestrowane wiele finalizatorów za pomocą kolejnych wywołań runtime.SetFinalizer, a co się stanie, jeśli funkcja finalizatora sama jest zamknięciem, które uchwyciło obiekt?
Wielu kandydatów błędnie uważa, że wiele finalizatorów może tworzyć łańcuch lub kolejkę na jednym obiekcie. Go wyraźnie nadpisuje wszelkie istniejące finalizatory, gdy SetFinalizer jest wywoływane ponownie, pozostawiając tylko najnowszy wskaźnik funkcji w wewnętrznej tabeli skrótów czasu wykonania. Jeśli finalizator jest zamknięciem, które uchwyciło obiekt, tworzy to cykliczne odniesienie, które trzyma obiekt na stałe osiągalnym, uniemożliwiając uruchomienie finalizatora i powodując wyciek pamięci, ponieważ GC widzi uchwycone odniesienie w zmiennych zamknięcia.
Jak GC radzi sobie z kolejnością wykonania finalizatorów dla grafu obiektów, w którym A odnosi się do B i oba mają zarejestrowane finalizatory?
Kandydaci często oczekują deterministycznej kolejności, takiej jak dziecko przed rodzicem lub zachowanie LIFO. Go nie zapewnia gwarancji dotyczących kolejności, ponieważ GC wprowadza finalizatory dla wszystkich niedostępnych obiektów jednocześnie do globalnej kolejki przetwarzanej równolegle przez wiele funkcji w tle. Jeśli finalizator A uzyskuje dostęp do B, a finalizator B już się wykonał i potencjalnie zwolnił zasoby, finalizator A napotka uszkodzony stan lub błędy użycia po zwolnieniu, co wymaga, aby finalizatory nigdy nie uzyskiwały dostępu do innych obiektów, które również mają finalizatory, lub aby cała logika sprzątania była scentralizowana w jednym finalizatorze dla obiektu korzennego.