Przed Go 1.22 specyfikacja języka alokowała zmienne pętli raz na każdy statement pętli, a nie na iterację. Ta jedna lokalizacja w pamięci była używana ponownie dla każdej iteracji, zmieniając tylko swoją wartość sekwencyjnie. Kiedy zamknięcie przechwytywało tę zmienną przez referencję — co jest powszechne w goroutines uruchamianych wewnątrz pętli — wszystkie zamknięcia dzieliły ten sam adres w pamięci. W rezultacie każde zamknięcie obserwowało ostateczną wartość przypisaną do tego adresu po zakończeniu pętli.
Go 1.22 wprowadziło zakres na poziomie iteracji, co oznacza, że każda iteracja instancjonuje nową zmienną z odrębnym adresem w pamięci. To zapewnia, że zamknięcia przechwytują specyficzną wartość dla danej iteracji, a nie wspólną lokalizację mutowalną. Ta zmiana wyeliminowała jedną z najczęstszych pułapek współbieżności, jednocześnie zachowując zgodność wsteczną dla kodu, który nie zależał od tożsamości adresu zmiennych pętli.
Usługa przetwarzania danych potrzebowała rozesłać odczyty czujników do goroutines roboczych w celu równoległej weryfikacji przed przechowaniem.
Zespół początkowo zaimplementował fan-out, korzystając z idiomatycznej składni zamknięć:
readings := []SensorReading{{ID: 1}, {ID: 2}, {ID: 3}} for _, r := range readings { go func() { validate(r.ID) // Krytyczny błąd: Wszystkie goroutines weryfikują ID 3 }() }
Po wdrożeniu logi ujawniły, że każdy pracownik przetwarzał ten sam ostatni rekord, podczas gdy wcześniejsze rekordy były całkowicie ignorowane, co spowodowało utratę danych.
Rozwiązanie 1: Cieniowanie zmiennych. To podejście wprowadza nową zmienną wewnątrz ciała pętli, aby cieniować zmienną iteracyjną, wymuszając odrębne przydzielenie pamięci dla każdej iteracji. Zalety: Natychmiast naprawia problem przechwytywania bez potrzeby zmiany sygnatur funkcji. Wady: Opiera się na subtelnym sztuczce leksykalnej, która wydaje się syntaktycznie zbędna dla recenzentów i nie zapewnia ochrony kompilatora w przypadku przypadkowego usunięcia podczas refaktoryzacji.
Rozwiązanie 2: Przekazywanie parametrów. Ta metoda jawnie przekazuje wartość jako argument do zamknięcia, zapewniając, że ewaluacja odbywa się w każdej iteracji, a nie w czasie wywołania. Zalety: Jest jednoznaczna, przenośna we wszystkich wersjach Go i czyni zależności danych wyraźnymi oraz dokumentującymi się same. Wady: Wymaga przekształcenia zamknięcia, aby akceptować parametry, co dodaje minimalny, ale niezerowy syntaktyczny narzut.
Rozwiązanie 3: Aktualizacja infrastruktury. Migracja całej floty do Go 1.22+, aby wykorzystać nowe semantyki zmiennych na poziomie iteracji. Zalety: Eliminuje źródłowy problem na poziomie języka, umożliwiając czystszy idiomatyczny kod. Wady: Wymaga skoordynowanych zmian w infrastrukturze i nie oferuje ulgi dla starszych baz kodu, które muszą pozostać na starszych narzędziach.
Zespół wybrał Rozwiązanie 2 do natychmiastowego wdrożenia. Ta decyzja zapewniła, że kod działał poprawnie we wszystkich wersjach kompilatorów i nie polegał na subtelnych sztuczkach cieniowania, które mogły być przypadkowo usunięte.
Po wdrożeniu, każda gorutyna otrzymała swój odrębny ID czujnika, pipeline przetworzył wszystkie rekordy poprawnie, a system pozostał stabilny podczas następnej aktualizacji do Go 1.22.
Dlaczego branie adresu zmiennej iteracyjnej for-range w Go 1.22+ nadal nie pozwala na bezpośrednią modyfikację oryginalnych elementów slice?
Nawet przy zmiennych na poziomie iteracji, zmienna iteracyjna zawiera kopię elementu slice, a nie sam element. Branie jej adresu daje wskaźnik do tej efemerycznej kopii, a nie do wpisu w podstawowej tablicy. Ponieważ zmienna każdej iteracji jest odrębną lokalizacją, ale zawiera kopię wartości, modyfikacja *(&v) dotyczy tylko tymczasowej kopii, która jest porzucana po zakończeniu iteracji. Aby zmodyfikować źródłowy slice, musisz użyć składni indeksu: for i := range slice { slice[i].Field = NewValue }.
Czy zmiana zakresu na poziomie iteracji w Go 1.22 wprowadza narzut wydajności lub dodatkowe przydziały w stercie w porównaniu do modelu ponownego użycia zmiennych przed 1.22?
Nie. Kompilator Go optymalizuje zmienne na poziomie iteracji, aby znajdowały się na stosie lub w rejestrach, gdy zamknięcia nie uciekają do sterty. Zmiana semantyczna wpływa na leksykalny zakres i tożsamość wskaźników, a nie strategię przydzielania lub wydajność czasu wykonania samej pętli. Pętle bez zamknięć wykazują identyczne cechy wydajności przed i po zmianie.
Jak zachowanie ponownego użycia zmiennych w Go przed 1.22 wpłynęło na tradycyjne pętle for z trzema klauzulami w porównaniu do pętli for-range?
Zachowanie było identyczne we wszystkich wariantach pętli for. Zarówno for i := 0; i < n; i++ jak i for _, v := range m ponownie używały tego samego adresu w pamięci dla swoich zmiennych iteracyjnych przez wszystkie iteracje. Kandydaci często błędnie zakładają, że błąd starych zamknięć był unikalny dla pętli range, ale zamknięcia przechwytujące indeks i w pętli z trzema klauzulami miały ten sam problem, drukując ostateczną wartość i, a nie oczekiwaną wartość iteracyjną. Go 1.22 rozwiązało to jednolicie dla wszystkich typów pętli.