Я работаю в системе, которая выделяет память для кэша ввода-вывода для повышения производительности. Затем, обнаружив OOM, он забирает некоторую часть обратно, чтобы бизнес-логика могла продолжаться, даже если это означает меньший объем кэша ввода-вывода и немного меньшую производительность записи.
Я также работал со встроенными Java-приложениями, которые пытались управлять OOM, форсируя сборку мусора, опционально освобождая некоторые некритические объекты, такие как предварительно извлеченные или кэшированные данные.
Основные проблемы с обработкой OOM:
1) возможность повторной попытки в том месте, где это произошло, или возможность откатиться и повторить попытку с более высокой точки. Большинство современных программ слишком сильно зависят от языка и не могут точно определить, где они находятся, и как повторить операцию. Обычно контекст операции теряется, если он не предназначен для сохранения
2) возможность освободить память. Это означает своего рода менеджер ресурсов, который знает, какие объекты являются критическими, а какие нет, и система сможет повторно запросить освобожденные объекты, когда и если они позже станут критическими
Еще одна важная проблема - возможность откатиться, не вызывая еще одну ситуацию с OOM. Это то, что трудно контролировать в языках более высокого уровня.
Кроме того, базовая ОС должна вести себя предсказуемо в отношении OOM. Linux, например, не будет, если включена избыточная память. Многие системы с поддержкой подкачки умрут раньше, чем сообщат об OOM приложению-нарушителю.
И есть случай, когда не ваш процесс создал ситуацию, поэтому освобождение памяти не помогает, если нарушающий процесс продолжает протекать.
Из-за всего этого часто большие и встраиваемые системы используют эти методы, поскольку они имеют контроль над ОС и памятью, чтобы позволить им, и дисциплину / мотивацию для их реализации.