Czy Małe Wycieki Pamięci Mają Już Znaczenie?

Przecieki to robaki.

Prawdopodobnie masz też inne błędy.

Kiedy wysyłasz produkt, wysyłasz go ze znanymi błędami. Gdy wybierzesz, które (ze znanych) błędy "naprawić" w porównaniu do "Wyślij z", robisz to na podstawie kosztów i ryzyka, aby naprawić w porównaniu do korzyści dla klienta.

Przecieki nie różnią się niczym. Jeśli jest to mały wyciek, który występuje podczas rzadkiej operacji w aplikacji innej niż serwerowa( np. aplikacja, która działa przez kilka minut lub godzin, a następnie się wyłącza), może być " ok " w ten sam sposób każdy inny błąd jest ok.

W rzeczywistości przecieki mogą być trochę inne w jeden ważny sposób, czyli jeśli wysyłasz bibliotekę / API, naprawdę powinieneś je naprawić, ponieważ korzyści dla klienta są ogromne(w przeciwnym razie wszyscy twoi klienci "odziedziczą" Twój wyciek i będą dzwonić do ciebie tak, jak musisz teraz porozmawiać z zewnętrznym dostawcą).

Chociaż zgadzam się, że każdy mały przeciek się sumuje, nie zgadzam się, że zawsze jest najlepsza biznes decyzja, aby go naprawić.

Co jeśli masz bezpaństwowy system legacy i żadnych programistów, którzy go rozumieją? Teraz używasz go w sytuacji, która musi się skalować... 100x tańsze jest odradzanie nowej instancji i zamiana jej na inną, zanim pamięć wypłynie za burtę.

Lub powiedzmy, że masz system przetwarzania wsadowego, który działa 24x7, ale dla którego nie ma prawdziwego użytkownika. Jeśli jest taniej aby monitorować pamięć i powiedzieć systemowi, aby okresowo się restartował, po co szukać wycieku?

Myślę, że powinieneś się bardzo starać, ale bądź pragmatyczny w kwestii biznesowych konsekwencji decyzji.

Nie, Nie ma to jednak znaczenia tylko wtedy, gdy, jak zauważyłeś, wyciek pamięci nie może Być powtarzalnym . Wycieki pamięci, które nie rosną w miarę postępu programu, są zwykle w porządku. Nie rosnące wycieki pamięci zostaną ostatecznie rozwiązane po zakończeniu procesu.

Trudno jednak udowodnić, że obserwowany wyciek pamięci nie rośnie; masz wystarczające dane empiryczne. W rzeczywistości wiele ogromnych programów (nawet napisanych w Javie/C#) ma wycieki pamięci, ale większość z nich to nie rosnące przecieki.

Ale muszę się nie zgodzić z Twoją opinią: "pamięć jest tania". To nie usprawiedliwia wycieków pamięci. To bardzo niebezpieczne.

Tak. Przecieki mają znaczenie. Jeśli Twoje aplikacje działają 24x7x365 i obsługują kilka tysięcy transakcji na sekundę, kilka bajtów szybko zamienia się w gigabajty.

Wyciek pamięci naprawdę zależy od kilku rzeczy:

• jak często zdarza się przeciek
• ile pamięci traci się za każdym razem
• Jak długo program będzie działał

Na przykład, jeśli stracisz 40 bajtów za każdym razem, gdy pojawi się zadanie, i to zadanie dzieje się, gdy program się uruchomi, to nikogo to nie obchodzi. Jeśli stracisz 40MB za każdym razem, gdy program się uruchomi, należy go zbadać. Jeśli stracisz 40 bajtów na każdą klatkę w swoim silniku wideo lub gry, powinieneś zajrzeć do tego, bo co sekundę tracisz 1,2 kB, a po godzinie stracisz prawie 4MB.

To zależy również od tego, jak długo program zostanie. Na przykład mam małą aplikację kalkulatora, którą otwieram, uruchamiam obliczenia, a następnie ponownie zamykam. Jeśli ta aplikacja straci 4Mb w swoim uruchomieniu, to naprawdę nie ma znaczenia, ponieważ system operacyjny odzyska utraconą pamięć po jej zamknięciu. Jeśli hipotetyczny silnik wideo / gry wspomniany wcześniej stracił 4Mb na godzinę, a uruchomił Jednostka demonstracyjna, przez kilka godzin dziennie na stoisku na konwencie, a potem się temu przyglądałem.

Przykładem słynnego wycieku pamięci jest Firefox, który stracił dużo pamięci we wcześniejszych wersjach. Gdyby twoja przeglądarka wyciekła z pamięci 10 lat temu, prawdopodobnie nie dbałbyś o to. Wyłączasz komputer każdego dnia, a podczas uruchamiania przeglądarki masz tylko jedną stronę na raz. Dziś po prostu pozwoliłem mojemu laptopowi przejść w stan gotowości i nigdy nie zamykam Firefoksa. Jest otwarta tygodniami, a ja mam w co najmniej 10 zakładek otwartych w danym momencie. Jeśli pamięć wycieka za każdym razem, gdy karta jest zamknięta, to będzie to narastać do większego wycieku teraz niż 10 lat temu, a więc jest ważniejsze.

Czy wycieki pamięci są w porządku?

Wycieki pamięci przez długi okres czasu są, jak sugeruje 85-punktowa odpowiedź, problematyczne. Weźmy na przykład prostą aplikację komputerową-przed wersjami 3.x, czy zauważyłeś kiedyś, że trzeba go zrestartować Firefoksa po jakimś czasie, aby odzyskać go z ospałości?

Jestem na tej samej łodzi co Ty. Mam małe wycieki pamięci, które nigdy nie rosną. Większość przecieków jest spowodowana nieprawidłowym niszczeniem obiektów COM. Przestudiowałem przecieki i zdałem sobie sprawę, że czas i pieniądze na ich naprawę są nieproporcjonalne do szkód, jakie wyrządzają przecieki. Windows oczyszcza się przez większość czasu, więc prawdziwe uszkodzenie jest realizowane tylko wtedy, gdy użytkownik uruchamia swój komputer przez lata bez ponownego uruchamiania.

Myślę, że można zostawić w przeciekach. To brzmi tak tabu, ale jeśli przecieki nigdy nie rosną i są małe, to jest to dość nieistotne w większym schemacie rzeczy.

Zgadzam się z wcześniejszymi odpowiedziami, że przecieki mają znaczenie.

Ludzie mogą mieć mnóstwo pamięci, ale także uruchamiają coraz więcej programów, i jeśli Twoja aplikacja nie jest całkowicie zamocowana do procesora, musi grać ładnie z innymi programami, co oznacza również, że nie zamocuje zasobów, których nie potrzebuje.

Tak więc ten mały wyciek pamięci sumuje się i oznacza, że użytkownik będzie miał inne problemy, a jeśli zdecyduje, że mają problemy z pamięcią, jeśli zdecyduje, że uruchomienie aplikacji powoduje problemy, a następnie przestaną ją uruchamiać.

Poza tym, jak już wspomniano, jeśli nie wiesz, co jest przyczyną wycieku, możesz mieć inne problemy, o których nie wiesz. To może być wierzchołek bug iceberg.

To zależy od charakteru aplikacji. Pracuję przede wszystkim ze stronami internetowymi i aplikacjami internetowymi. Tak więc według większości definicji moja aplikacja" uruchamia się " raz na żądanie. Kod, który wycieka kilka bajtów na żądanie w witrynie o dużej objętości, może być katastrofalny. Z doświadczenia wynika, że mieliśmy jakiś kod, który wyciekł kilka kb na żądanie. Podsumowując, to spowodowało, że nasze procesy pracowników serwerów internetowych były restartowane tak często, że powodowały minutowe przestoje w ciągu dnia.

Ale aplikacje internetowe (i wiele innych rodzaje) mają nieokreśloną długość życia-biegną w sposób ciągły, na zawsze. Im krótsza żywotność aplikacji, tym lepiej. Jeśli każda sesja aplikacji ma skończony i rozsądnie przewidywalny punkt końcowy, istnieje oczywiście rozsądna ilość wycieków, którą możesz tolerować. Chodzi o zwrot z inwestycji.

Wszystko zależy. Powody, aby się nie martwić: Proces jest krótkotrwały, wycieki są małe i / lub rzadkie, koszt wyjątku bez pamięci jest niski (np. instancja serwera www w klastrze wymaga ponownego uruchomienia, a kilka pobrań wymaga ponownej próby). Więc zgadzam się, że niektóre przecieki nie mają znaczenia w praktyce.

Ale z drugiej strony, jeśli masz powód do zmartwień, a nawet czujesz dokuczliwe poczucie wątpliwości, że może nie traktujesz jakości wystarczająco poważnie, jest to mała sprawa (w większości przypadków), aby uruchomić oprogramowanie z wykrywaczem wycieku pamięci i rozwiązać problemy. Istnieje wiele dobrych wykrywaczy wycieków. I może się okazać, że wyciek jest częścią poważniejszego problemu, takiego jak nie wypuszczanie innych zasobów (takich jak otwarte pliki). Może się nawet okazać, że nieszkodliwy wyciek okaże się dość niebezpieczny w scenariuszach użytkowania, których jeszcze nie przetestowałeś.

Tak, to ma znaczenie. Każdy mały przeciek się sumuje.

Po pierwsze, jeśli twój nieszczelny kod jest używany w kontekście, w którym jest wielokrotnie używany i za każdym razem trochę przecieka, te małe bity sumują się. Nawet jeśli wyciek jest mały i Rzadki, te rzeczy mogą sumować się do znacznych ilości w długim okresie czasu.

Wtórnie... jeśli piszesz kod, który ma wycieki pamięci, , to ten kod ma problemy . Nie twierdzę, że dobry kod nie od czasu do czasu ma wycieki pamięci, ale fakt ich istnienia oznacza, że występują poważne problemy. Wiele, wiele luk w zabezpieczeniach wynika właśnie z tego rodzaju niedopatrzenia(nieograniczona Kopia ciągów, ktokolwiek?).

Najważniejsze jest to, że jeśli wiesz o tym, a nie robisz wszystkiego, co możesz, aby go wyśledzić i naprawić, to sprawiasz problemy.

Wycieki pamięci nigdy nie są w porządku w żadnym programie, bez względu na to, czy są małe. Powoli będą się sumować, aby wypełnić całą pamięć. Załóżmy, że masz system wywołujący, który wycieka około 4 bajtów pamięci na każde wywołanie, które obsługuje. Możesz obsłużyć powiedzmy 100 połączeń na sekundę( jest to bardzo mała liczba), więc kończy się wyciekiem 400 bajtów na sekundę lub 400x60x60(1440000b) na godzinę. Tak więc nawet mały wyciek nie jest akceptowalny. A jeśli nie znasz źródła przecieku, to może to być jakiś poważny problem i skończysz posiadanie wadliwego oprogramowania. Ale zasadniczo sprowadza się to do pytań takich jak, przez ile czasu program działa i ile razy zdarza się wyciek. Tak więc może być w porządku, że przecieka bardzo mała ilość i nie powtarza się, ale nadal wyciek może być małą częścią większego problemu. Więc czuję, że wycieki pamięci nigdy nie są w porządku.

To tak jakby zapytać, czy w tamie było pęknięcie. Nie! Nigdy! Unikaj wycieków pamięci, jakby od tego zależało twoje życie, ponieważ gdy aplikacja rośnie i staje się bardziej użyteczna, ten wyciek zamieni się w powódź i prędzej czy później ktoś lub coś się w niej utopi. To, że możesz mieć dużo pamięci, nie oznacza, że możesz używać skrótów z kodem. Gdy znajdziesz przeciek, zrób co możesz, aby go rozwiązać, a jeśli nie możesz go rozwiązać, upewnij się, że wracasz do dopóki nie zostanie naprawiony.

Jeśli nie możesz usunąć przecieku, spróbuj sprawdzić, czy możesz po nim posprzątać. Większe problemy pojawiają się, gdy przeciek jest powtarzalny.

Ostatnia uwaga: jeśli kiedykolwiek przekażesz oprogramowanie komuś innemu, a wyciek nadal tam jest, może upłynąć dużo czasu, zanim ktoś inny go znajdzie i / lub naprawi.

Nie martwiłbym się tak ilością, ale częstotliwością wycieku pamięci, ale jeśli wycieknie nawet kilka bajtów bardzo często, struktury danych Twojego malloca będą rosły i mogą znacznie spowolnić ich przemieszczanie, przydzielanie nowej pamięci i wolne. Jeśli nie trafisz na granicę, w której wyciekł więcej niż niewielki ułamek pamięci RAM, głównie Twój program ucierpi z powodu tych problemów z wydajnością, a nie całego systemu. Nie dotyczy nawet zdalnie systemy oparte na dlmalloc (FreeBSD, Linux, etc), tam to po prostu nie obchodzi, wszystko, co tracisz jest pamięć (może kilka razy więcej niż ilość myślisz), a nie Wydajność.

Pojedynczy przydział, który nie jest odzyskany przez twój program, wcale nie jest wyciekiem. Jeśli napiszesz małe narzędzie wiersza poleceń, które zajmuje sekundę, możesz nie potrzebować nawet odzyskać pamięci. Po zakończeniu, system operacyjny odzyskuje pamięć RAM, uchwyty plików, powinny w zasadzie mieć zastosowanie do każdego rodzaju systemu zasób, ale nie można polegać na niektórych systemach operacyjnych tak samo jak na innych, ale tak długo, jak to tylko pamięć, nawet Windows 95 będzie zarządzać nim w sam raz.

Aha i z tego wynika jeszcze jedno, jeśli wycieknie Ci pamięć, nie trudź się czyszczeniem po zakończeniu programu lub po długim czasie wykonania, bo po prostu zmarnujesz jeszcze więcej czasu procesora. Zawsze naprawiaj przecieki tak blisko punktu czasowego, w którym są tworzone, jak to możliwe. Inny powód: malloc wolą zachować pamięć RAM, którą dostali z System operacyjny dla przyszłych alokacji zamiast oddawać go z powrotem. Może również wystąpić fragmentacja przestrzeni adresowej.

Jeśli ktoś mówi, że wycieki pamięci są ok w małych ilościach i tak długo, jak to nie crash aplikacji, to tak jakby powiedzieć, kradzież jest ok, jeśli w małych ilościach i tak długo, jak nie zostaną złapani:)

Wycieki pamięci są bardzo ważne w aplikacjach 32-bitowych ponieważ aplikacja jest ograniczona do 2^32 bajtów pamięci, czyli około 4 GB. Gdy aplikacja 32-bitowa spróbuje przeznaczyć więcej niż 2^32 bajty pamięci, aplikacja może się zawiesić lub zawiesić.

Wycieki pamięci są nie tak ważne w aplikacjach 64-bitowych ponieważ aplikacja jest ograniczona do 2^64 bajtów pamięci, czyli około 16 EB; więc z aplikacją 64 bitową jesteś więcej-tak ograniczone przez sprzęt, ale system operacyjny nadal prawdopodobnie nałoży sztuczne ograniczenie w pewnym momencie.

Najważniejsze jest to, że wyciek pamięci w kodzie jest złym programowaniem; więc napraw to i bądź lepszym programistą.