Что случится с программой (Go, Python, JS, PHP), если потребуется выделить память, а оперативная память в ОС закончилась?
===========================================================================================================================

 Ситуация:  

1. Из сети (диска) читается файл чанками  

2. Все это складыватся в переменную  

3. Файл большой - оперативная память заканчивается  

4. Что произойдет с программой (если нет никаких доп. обработок)? Будет выделено место на диске (операционной системой)? А если этого места нет больше нигде? 

 Сначала swap, а потом out of memory exception 

 Ответ на ваш вопрос складывается из ответа на два других:  

- В чем суть работы менеджера виртуальной памяти?  

- Может ли один процесс запросить у менеджера памяти больше, чем процессор в состоянии адресовать, исходя из его архитектуры?  

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

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

Вместо резюме: реакция ОС на "прожорливость" процесса может различаться. У linux есть OOM killer, который прибивает "зажравшиеся" процессы. Форточки позволяют запрашивать память пока место на диске не заканчивается исключительно потому, что работает, обычно, более одного процесса, и каждый из них может занять до максимально адресуемого, для текущей архитектуры, куска виртуальной памяти. 

 Будет задействован swap файл.  

Если места больше нет, то будет out of memory exception и программа крашнется.  

А вообще огромные файлы полностью класть в оперативную память это плохо. 

 Не имеет значения какой язык программирования будет использован. ОС, прежде всего, постарается обслужить аппетиты программы. И если доступной ОЗУ не хватит, полезет в файл/раздел подкачки (swap).  

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

  

А если программа не умеет обрабатывать ошибки нехватки памяти, то она просто зависнет или рухнет с посмертным дампом.  

  

> 1. Из сети (диска) читается файл чанками

Ух, замечательно!  

  

> 2. Все это складыватся в переменную

Что?! Зачем это понадобилось? Это как если бы в строительстве ставили *кирпичный* дом на фундамент целиком, а не по частям. 

 Зачем его в память читать? Почему не читать из сети сразу на диск?  

  

А если твоя программа 32бит, то ты вообще не сможешь задействовать всю ОЗУ, если у тебя её больше 3гб. 

 Не знаю как на других OS-ях, но Windows не выделит скорее всего. Там есть лимит 

 Зависит от того сколько требуется, если немного, то в своп запишется, если много (думаю когда объем требуемой памяти превышает своп), то система может крашнуться. Я как-то раз решил проверить это (не советую это делать), создал массив, который мог занять несколько десятков гигов и начал заполнять его в цикле, в итоге система упала с ошибкой (всего в ней было 4гб озу), тестил на 10 винде. 

 В общем всем спасибо.  

В swarm-режиме в докере, как оказалось, все падает с кодом 137 - в swap по-умолчанию не выделяется, чтобы выделилось, нужно писать доп. параметры. Но это, конечно, спорный момент - если приложение неукротимо прожорливо, тогда это бессмысленно.  

  

Подробнее здесь:  

[https://docs.docker.com/config/containers/resource...](https://docs.docker.com/config/containers/resource_constraints/)