Odpowiedzi:
Unikałbym OOM jak uniknięcie wypadku.
Unikaj wykonywania dużej ilości pracy (i przydzielania dużej ilości pamięci) jednocześnie. Przechowuj dane na dysku, zaufaj pamięci podręcznej dysku systemu operacyjnego i korzystaj z mapowania pamięci IO w jak największym stopniu, i operuj tylko niewielką częścią danych na raz. Jeśli duże ilości danych muszą być dostępne online (podawane z małym opóźnieniem), przechowuj je w pamięci na kilku komputerach, tak jak robią to duże firmy wyszukiwarek. Lub kup dysk SSD.
Większość osób odpowiadających na to pytanie prawdopodobnie nigdy nie pracowała na systemach wbudowanych, w których malloc zwracanie 0 jest bardzo realną możliwością. W systemie, nad którym obecnie pracuję, jest w sumie 4,25 tys. Bajtów pamięci RAM (4352 bajtów). Przydzielam 64 bajty dla stosu, a obecnie mam stertę 1600 bajtów. Wczoraj debugowałem procedurę marszu, aby śledzić przydzielanie i zwalnianie pamięci. Spacer po stosie wykorzystuje mały (30 bajtów) statycznie przydzielony bufor do wysyłania danych do portu szeregowego. Zostanie wyłączony dla wersji.
Ponieważ jest to produkt konsumencki, lepiej nie zabraknąć pamięci po wydaniu produktu. Jestem pewien, że tak będzie podczas programowania. W każdym razie wszystko, co mogę zrobić, to kilka razy wydać sygnał z głośnika i wymusić ponowne uruchomienie.
Szczerze mówiąc, we wszystkich projektach, które wykonałem (pamiętajcie, że nigdzie jeszcze nie pracuję), nigdy nie myślałem, że może się to zdarzyć, i dlatego przypuszczam, że moje programy umrą bardzo szybko.
Poza tym obsługa OOM wymaga wcześniejszego przydzielenia zasobów w celu wyświetlenia komunikatu o błędzie lub zapisania wszystkiego, co może być nieco niewygodne.
Wydaje mi się, że w dzisiejszych czasach, pamięć kosztuje mniej niż orzeszki ziemne, nie jest to coś, co powinno się często zdarzać. O świcie chronionej pamięci i wcześniej może to stanowiło problem, ale teraz? Jedyne błędy OOM, jakie kiedykolwiek widziałem, to błędy w kodzie.
Sprawdzanie kodów powrotu Malloc jest zwykle bezcelowe.
Współczesne systemy operacyjne przeciążają pamięć: zapewniają procesom więcej pamięci, niż jest w rzeczywistości dostępna. Pamięć przyznana procesowi jest wirtualna, a wszystkie są zmapowane na pojedynczą stronę zerowaną.
Dopiero gdy napiszesz do pamięci, fizyczna, unikalna strona jest przydzielana dla twoich procesów. Jeśli alokacja nie powiedzie się, jądro zakończy proces (być może twój!) W celu znalezienia pamięci. W tym momencie nic więcej nie możesz zrobić.
Jeśli nie tworzysz systemów wbudowanych, systemów czasu rzeczywistego lub systemów, które są tak krytyczne, że awarie mogą kosztować życie lub miliardy dolarów ... To prawdopodobnie nie warto finansowo martwić się brakiem pamięci.
W większości przypadków niewiele można zrobić, gdy brakuje pamięci, ponieważ nie ma pamięci do tworzenia nowych obiektów lub wykonywania zadań, które mogą coś zrobić. Musisz porównać koszty obsługi aplikacji OOM z korzyściami, jakie możesz z tego zrobić.
Zawsze sprawdzałbym pod kątem błędu. Jeśli coś zwróci warunek błędu, musi to zostać obsłużone przez Twój program. Nawet jeśli jest to komunikat „Brak pamięci, muszę iść!”, Jest lepszy niż „Naruszenie dostępu”, „zrzut pamięci” lub cokolwiek innego. Jeden to błąd, który rozwiązujesz, drugi to błąd. I użytkownik również to postrzega.
W konkretnym przypadku możesz spróbować cofnąć operację, zwolnić przydzielone zasoby do momentu wystąpienia awarii, zgłosić błąd i kontynuować wykonywanie (być może, gdy próbujesz zamknąć aplikację, możesz podać opcja natychmiastowego wyjścia). W ten sposób użytkownik może zdecydować, co robić, lub spróbować zwolnić trochę pamięci, bawiąc się, zamykając pliki itp. Oczywiście sposób radzenia sobie z sytuacją jest wysoce zależny od programu - programu, który nie powinien być interaktywnym, prawdopodobnie wystarczy zarejestrować błąd i albo wyjść, albo kontynuować.