Apakah Anda menangani kondisi Di Luar Memori?

Apa yang Anda lakukan ketika mallocmengembalikan 0 atau pengecualian lemparan baru? Hanya berhenti atau mencoba bertahan kondisi OOM / menyelamatkan pekerjaan pengguna?

Saya akan menghindari OOM seperti menghindari kecelakaan.

Hindari melakukan banyak pekerjaan (dan alokasikan banyak memori) sekaligus. Simpan data pada disk, percayakan cache disk OS dan gunakan IO yang dipetakan di memori sebanyak mungkin, dan hanya beroperasi pada sebagian kecil data pada satu waktu. Jika sejumlah besar data harus on-line (disajikan dengan latensi rendah) maka simpan di memori di beberapa mesin, seperti yang dilakukan semua perusahaan mesin pencari besar. Atau beli SSD.

Sebagian besar orang yang menjawab pertanyaan ini mungkin belum pernah bekerja pada sistem embedded, di mana malloc mengembalikan 0 adalah kemungkinan yang sangat nyata. Pada sistem yang sedang saya kerjakan, ada total 4,25K byte RAM (yaitu 4352 byte). Saya mengalokasikan 64 byte untuk stack, dan saat ini memiliki tumpukan 1600 byte. Baru kemarin saya men-debug heap walk rutin sehingga saya bisa mengikuti alokasi dan membebaskan memori. Heap walk menggunakan buffer kecil (30 byte) yang dialokasikan secara statis untuk output ke port serial. Ini akan dimatikan untuk versi rilis.

Karena ini adalah produk konsumen, lebih baik tidak kehabisan memori begitu produk telah dirilis. Saya yakin itu akan selama pengembangan. Bagaimanapun, yang bisa saya lakukan adalah membunyikan bip speaker beberapa kali, dan memaksa reboot.

Sejujurnya, dalam semua proyek yang telah saya lakukan (ingat saya belum bekerja di mana pun), saya tidak pernah mempertimbangkan bahwa itu bisa terjadi, dan dengan demikian saya kira program saya akan mati dengan sangat cepat.

Selain itu, menangani OOM mengharuskan Anda melakukan pra-alokasi sumber daya untuk menampilkan pesan kesalahan atau menyimpan semuanya, yang bisa jadi agak merepotkan.

Saya merasa bahwa hari-hari ini, ingatan lebih murah daripada kacang, itu bukan sesuatu yang harus sering terjadi. Pada awal ingatan yang dilindungi dan sebelumnya, mungkin itu yang menjadi perhatian, tapi sekarang? Satu-satunya kesalahan OOM yang pernah saya lihat berasal dari kode yang disadap.

Memeriksa kode pengembalian malloc biasanya tidak ada gunanya.

Sistem operasi modern memori overcommit: Mereka memberikan proses lebih banyak memori daripada yang sebenarnya tersedia. Memori yang diberikan proses Anda adalah virtual, semua dipetakan ke satu halaman zeroed-out.

Tidak sampai Anda menulis ke memori bahwa halaman fisik, unik, dialokasikan untuk proses Anda. Jika alokasi ini gagal, kernel akan menghentikan proses (mungkin milik Anda!) Dalam upaya mencari memori. Pada saat itu tidak ada yang dapat Anda lakukan lagi.

Kecuali jika Anda mengembangkan untuk sistem embedded, sistem real-time, atau sistem yang sangat kritis sehingga kegagalan dapat menelan korban jiwa, atau miliaran dolar ... Maka mungkin tidak layak secara finansial untuk khawatir tentang kondisi kehabisan memori.

Dalam kebanyakan kasus, ada sedikit yang dapat dilakukan ketika Anda kehabisan memori, karena tidak ada memori untuk membuat objek baru atau melakukan tugas apa pun yang dapat melakukan sesuatu. Anda harus mempertimbangkan biaya aplikasi menangani OOM versus manfaat yang Anda dapatkan dari melakukannya.

Saya akan selalu memeriksa kesalahan. Jika sesuatu mengembalikan kondisi kesalahan, maka itu harus ditangani oleh program Anda. Bahkan jika itu adalah pesan yang mengatakan "Kehabisan memori, harus pergi!", Itu lebih baik daripada "pelanggaran akses", "core dumped", atau apa pun. Salah satunya adalah kondisi kesalahan yang Anda tangani, yang lainnya adalah bug. Dan pengguna akan melihatnya juga.

Untuk kasus spesifik Anda, Anda dapat mencoba untuk memutar kembali operasi, membebaskan sumber daya yang telah Anda alokasikan hingga mencapai titik kegagalan, melaporkan kesalahan, dan melanjutkan eksekusi (mungkin ketika Anda mencoba untuk keluar dari aplikasi, Anda dapat memberikan opsi untuk keluar segera). Dengan cara ini, pengguna dapat memutuskan apa yang harus dilakukan, atau mencoba membebaskan sebagian memori dengan mengutak-atik, menutup file, dll. Tentu saja, bagaimana Anda dapat menangani situasinya sangat tergantung pada program Anda - program yang tidak seharusnya bersifat interaktif mungkin hanya perlu mencatat kesalahan dan berhenti, atau melanjutkan.