Я считаю полезным подумать об этом: память - это дисковое пространство. RAM - быстрый кеш. Вместо того, чтобы думать «когда у меня не хватает ОЗУ, система подкачает ее на диск», я думаю «когда у меня будет доступная ОЗУ, система переместит в нее мою дисковую память».
Это отстает от того, как большинство людей думают об этом, но я считаю, что это помогает. RAM - это просто оптимизация производительности; реальный предел того, сколько памяти вы можете выделить, - это доступное дисковое пространство.
Конечно, это сложнее, чем это. В 32-разрядных операционных системах каждый процесс получает 2 миллиарда байт адресного пространства пользователя . (И то же самое для адресного пространства ядра, но давайте проигнорируем это.) Каждая страница памяти, к которой вы можете обращаться, находится ли она в ОЗУ или на диске, должна быть в этом адресном пространстве. Вы можете выделить более 2 миллиардов байтов, нет проблем. Но вы можете использовать только 2 ГБ за раз. Если у вас выделено 10 ГБ, то по крайней мере 8 ГБ не будут отображаться в адресное пространство. В этом случае вам нужно unmap что-то еще, а затем отобразить то, что вы хотите, в адресное пространство, чтобы добраться до него.
Более того, многие вещи должны находиться в непрерывном адресном пространстве. Например, если у вас есть стек размером 1 МБ, то в адресном пространстве должен быть миллион непрерывных байтов.
Когда людям «не хватает памяти», им не хватает ОЗУ; ОЗУ - это просто быстрый кеш на диске. И им не хватает места на диске; есть много этого. Они почти всегда находятся в ситуации, когда смежного адресного пространства недостаточно для удовлетворения спроса.
Менеджер памяти CLR не реализует эти причудливые стратегии map-and-unmap для вас; в основном, вы получаете 2 ГБ адресного пространства и все. Если вы хотите сделать что-то причудливое, скажем, с отображенными в память файлами, вы сами должны написать код для управления памятью.