Che cosa fai quando malloc restituisce 0 o una nuova eccezione? Basta interrompere o provare a sopravvivere alla condizione OOM / salvare il lavoro dell'utente?
Eviterei OOM come evitare un arresto anomalo.
Evita di fare enormi quantità di lavoro (e di allocare enormi quantità di memoria) contemporaneamente. Conservare i dati sul disco, fidarsi della cache del disco del sistema operativo e utilizzare il più possibile l'IO della memoria mappata e operare solo su una piccola parte di dati alla volta. Se una grande quantità di dati deve essere on-line (servita con bassa latenza), quindi tenerli in memoria su più macchine, come fanno tutte le grandi aziende di motori di ricerca. O acquista un SSD.
La maggior parte delle persone che rispondono a questa domanda probabilmente non hanno mai lavorato su sistemi embedded, dove malloc che restituisce 0 è una possibilità molto reale. Su un sistema al momento sto lavorando, c'è un totale di 4,25 KB di RAM (vale a dire 4352 byte). Sto allocando 64 byte per lo stack e attualmente ho un heap da 1600 byte. Proprio ieri stavo eseguendo il debug di una routine di heap walk in modo da poter seguire l'allocazione e la liberazione della memoria. L'heap walk utilizza un piccolo buffer (30 byte) assegnato staticamente per l'output su una porta seriale. Sarà disattivato per la versione di rilascio.
Poiché si tratta di un prodotto di consumo, è meglio non esaurire la memoria una volta che il prodotto è stato rilasciato. Sono sicuro che lo farà durante lo sviluppo. In ogni caso, tutto ciò che posso fare è emettere un segnale acustico per un paio di volte e forzare il riavvio.
Per essere onesto, in tutti i progetti che ho fatto (tieni presente che non sto ancora lavorando da nessuna parte), non ho mai pensato che potesse accadere, e quindi suppongo che i miei programmi morirebbero molto velocemente .
Inoltre, la gestione di una OOM richiede che tu abbia preassegnato le risorse per visualizzare il messaggio di errore o per salvare tutto, il che può essere un po 'scomodo.
Sento che in questi giorni, la memoria costa meno delle noccioline, non è qualcosa che dovrebbe accadere frequentemente. All'alba della memoria protetta e prima, forse quella era una preoccupazione, ma ora? Gli unici errori OOM che ho mai visto provengono da codice bugged.
Il controllo dei codici di ritorno di malloc è comunque inutile.
I moderni sistemi operativi sovraccaricano la memoria: danno ai processi più memoria di quanto sia effettivamente disponibile. La memoria a cui viene concesso il processo è virtuale, tutti mappati su una singola pagina a zero.
Non è finché non scrivi alla memoria che una pagina fisica, unica, è allocata per i tuoi processi. Se questa allocazione fallisce, il kernel terminerà un processo (forse il tuo!) Nel tentativo di trovare memoria. A quel punto non c'è più niente che puoi fare.
A meno che tu non stia sviluppando sistemi embedded, sistemi in tempo reale o sistemi che sono così importanti che i guasti possono costare vite, o miliardi di dollari ... Quindi probabilmente non vale la pena preoccuparsi delle condizioni di memoria insufficienti .
Nella maggior parte dei casi, c'è poco che si possa fare quando si è fuori dalla memoria comunque, poiché non c'è memoria per creare nuovi oggetti o eseguire attività che potrebbero fare qualcosa. Devi valutare il costo della gestione delle applicazioni OOM rispetto al vantaggio derivante dal farlo.
Vorrei sempre controllare l'errore. Se qualcosa restituisce una condizione di errore, deve essere gestita dal programma. Anche se è un messaggio che dice "Memoria esaurita, devo andare!", È meglio di "Violazione dell'accesso", "core scaricato" o qualsiasi altra cosa. Uno è una condizione di errore che gestisci, l'altro è un bug. E l'utente lo percepirà come tale.
Per il tuo caso specifico, puoi provare a eseguire il rollback dell'operazione, liberando le risorse che hai allocato fino a raggiungere il punto di errore, riportando l'errore e continuando l'esecuzione (forse quando stai provando ad uscire dall'applicazione, può dare l'opzione di uscire immediatamente). In questo modo, l'utente può decidere cosa fare, o provare a liberare memoria spostando, chiudendo i file, ecc. Naturalmente, il modo in cui gestire la situazione dipende molto dal programma, un programma che non dovrebbe essere interattivo probabilmente deve solo registrare l'errore e uscire o continuare.
Leggi altre domande sui tag programming-practices exceptions