Вы справляетесь с условиями нехватки памяти?

Что вы делаете, когда mallocвозвращает 0 или исключение новых бросков? Просто остановить или попытаться выжить в состоянии OOM / сохранить работу пользователя?

Я бы избежал ООМ, как избежать крушения.

Старайтесь не выполнять огромную часть работы (и выделять огромную часть памяти) сразу. Сохраняйте данные на диске, доверяйте кешу диска ОС и максимально используйте отображенный в памяти ввод-вывод и работайте только с небольшой частью данных одновременно. Если большие объемы данных должны находиться в режиме онлайн (обслуживаться с низкой задержкой), сохраняйте их в памяти на нескольких компьютерах, как это делают все крупные поисковые системы. Или купить SSD.

Большинство людей, отвечающих на этот вопрос, вероятно, никогда не работали на встроенных системах, где malloc возвращает 0 - вполне реальная возможность. В системе, над которой я сейчас работаю, имеется 4,25 КБ ОЗУ (это 4352 байта). Я выделяю 64 байта для стека, и в настоящее время у меня есть куча 1600 байтов. Буквально вчера я отлаживал процедуру обхода кучи, чтобы следить за распределением и освобождением памяти. Ход кучи использует небольшой (30 байт) статически выделенный буфер для вывода на последовательный порт. Это будет отключено для версии выпуска.

Так как это потребительский продукт, лучше не исчерпывать память после выпуска продукта. Я уверен, что это будет во время разработки. В любом случае, все, что я могу сделать, это пару раз подать звуковой сигнал на динамик и вызвать перезагрузку.

Честно говоря, во всех проектах, которые я делал (имейте в виду, что я еще нигде не работаю), я никогда не думал, что это может произойти, и поэтому я полагаю, что мои программы умрут очень быстро.

Кроме того, обработка OOM требует, чтобы вы предварительно распределили ресурсы для отображения сообщения об ошибке или для сохранения всего, что может быть неудобно.

Я чувствую, что в наши дни память стоит меньше, чем арахис, это не должно случаться часто. На заре защищенной памяти и раньше, может быть, это было проблемой, но сейчас? Единственные ошибки OOM, которые я когда-либо видел, были из ошибочного кода.

Проверка кодов возврата malloc обычно бессмысленна.

Современные операционные системы перегружают память: они дают процессам больше памяти, чем фактически доступно. Память, предоставленная вашему процессу, является виртуальной, все сопоставлено с одной обнуленной страницей.

Пока вы не запишите в память физическую, уникальную страницу, выделенную для ваших процессов. Если это распределение не удастся, ядро ​​завершит процесс (возможно, ваш!) В попытке найти память. В этот момент вы больше ничего не можете сделать.

Если вы не разрабатываете для встраиваемых систем, систем реального времени или систем, которые настолько критичны, что сбои могут стоить жизни или миллиарды долларов ... Тогда, вероятно, не стоит с финансовой точки зрения беспокоиться о нехватке памяти.

В большинстве случаев мало что можно сделать, когда у вас все равно не хватает памяти, поскольку нет памяти для создания каких-либо новых объектов или выполнения каких-либо задач, которые могут что-то сделать. Вы должны взвесить стоимость приложения, обрабатывающего OOM, и выгоду, которую вы получите от этого.

Я бы всегда проверял на ошибку. Если что-то возвращает условие ошибки, то это должно быть обработано вашей программой. Даже если это сообщение «Недостаточно памяти, надо идти!», Это лучше, чем «Нарушение доступа», «Дамп выгружен» или что-то еще. Одним из них является состояние ошибки, которое вы обрабатываете, другим является ошибка. И пользователь это тоже будет воспринимать.

В вашем конкретном случае вы можете попытаться откатить операцию, освободив ресурсы, которые вы выделили, до достижения точки сбоя, сообщив об ошибке и продолжив выполнение (возможно, когда вы пытаетесь выйти из приложения, вы можете дать возможность выйти сразу). Таким образом, пользователь может решить, что делать, или попытаться высвободить часть памяти, поигравшись, закрыв файлы и т. Д. Конечно, то, как вы справитесь с ситуацией, сильно зависит от вашей программы - программы, которая не должна быть интерактивным, вероятно, просто нужно зарегистрировать ошибку и либо выйти, либо продолжить.