Простому Hello World требуется 10 ГБ виртуальной памяти на 64-разрядной машине против 1 ГБ на 32-разрядной?

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

Вы можете выбрать оба с помощью параметров командной строки -Xms и -Xmx. .

Виртуальная память действительно не имеет значения для вас.

Основное различие между 32-битной и 64-битной версиями заключается в том, что адресное пространство в 64-битной системе невероятно велико. Если 10 ГиБ кажутся вам много, обратите внимание, что .NET на 64-разрядной версии может использовать такие ТиБы памяти. Тем не менее, в 32-разрядной среде .NET гораздо более консервативен (как и JVM) — адресное пространство составляет всего 4 ГБ — это немного.

Но это не имеет значения - это не имеет значения. Это просто вещь, которая значительно упрощает программирование и не оказывает никакого негативного влияния на основную ОС. Он создает непрерывное адресное пространство для использования виртуальной машиной, а это означает, что вам не нужно фрагментировать кучу (или, что еще хуже, стек, где это более или менее невозможно, но это, как правило, только МиБ или около того) как вам потребуется больше «настоящей» памяти. Когда вы, наконец, выделяете виртуальную память, она становится немного более реальной — в этот момент она более или менее должна поддерживаться некоторым хранилищем данных — будь то файл подкачки (подкачки) или физическая оперативная память.

Дело в том, что физическое расположение памяти не обязательно является непрерывным, но это делается за пределами вашей досягаемости, и отображение, как правило, очень быстрое. С другой стороны, необходимость, скажем, индексировать массив, который на самом деле фрагментирован более чем на 10 различных блоков памяти виртуальных адресов, это (совершенно ненужная) работа.

Итак, у вас есть это - виртуальная память почти свободна на 64-битной версии. Основной подход — «если он есть, используйте его». Вы не ограничиваете другие приложения, и это сэкономит вам немало работы, если вы делаете на самом деле в конечном итоге используете его. Но пока этот момент не наступил, у вас есть только оговорка. Это вообще не переводится ни в какую физическую память. Вы не платите за друзей, которые могут прийти сегодня вечером и сесть за ваш стол, но у вас все еще есть место для них, если они придут, и только когда они наконец придут, вы действительно получите «заряд».

См. этот вопрос для получения дополнительной информации о том, как Java ведет себя на разных машинах и в разных версиях: Каков максимальный размер кучи по умолчанию для JVM Sun из Java SE 6? Максимальный размер кучи также определяет объем зарезервированной виртуальной памяти, поскольку куча должно быть непрерывное адресное пространство. Если бы он не был предварительно зарезервирован, могло бы случиться так, что куча не смогла бы расшириться до этого максимального значения, потому что кто-то еще зарезервировал область адресного пространства в том месте, где куча должна расширяться.

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

Если приложение видит виртуальное адресное пространство размером 10 ГБ, все, что оно сигнализирует приложению, это то, что оно может использовать адреса памяти до 10 ГБ, если захочет. Тем не менее, память фактически не выделяется в физическом ОЗУ до тех пор, пока она не будет фактически записана, и это делается на постраничной основе, где страница представляет собой раздел памяти размером 4 КБ. Виртуальное адресное пространство — это просто виртуальное пространство, пока оно не используется.

Допустим, приложению выделено 10 ГБ адресного пространства, и оно начинает использовать часть из них. Поскольку сначала записывается «свежая» — ранее нетронутая — страница этой виртуальной памяти, система на низком уровне «сопоставляет» эту виртуальную страницу с разделом физической памяти, а затем записывает ее. Но самому этому приложению не нужно беспокоиться о таких деталях, оно просто действует так, как будто оно имеет полный доступ к виртуальной области памяти.

В случае Java-приложений это адресное пространство выделяется не самому приложению, а Java, и Java по умолчанию просто запрашивает огромное адресное пространство — количество, которое оно запрашивает, рассчитывается относительно размера физической памяти, а не потому, что оно имеет любой должен быть консервативным, но только для практичности - приложению вероятно не понадобится достаточный размер кучи, чтобы полностью поставить сервер на колени, поэтому оно работает, исходя из предположения, что этого не произойдет. Как я сказал выше, это не означает, что так много «распределено» или что системе пришлось затратить на это много ресурсов.

Это не ваша программа использует эту память, это виртуальная машина Java резервирует эту память, независимо от того, какая программа загружена.

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

Городской объект - главное воспоминание. Склад — это дисковое пространство.

Выделение 10 Гб виртуальной памяти для нового процесса не означает, что для нового клиента нужно найти место для 10 миллиардов ящиков. Это означает напечатать 10 миллиардов этикеток для коробок со смежными идентификационными номерами.

Это не тот объем физической памяти, который на самом деле использует приложение. Виртуальная память, используемая всеми процессами, может быть на порядки больше, чем объем физической оперативной памяти на машине, без каких-либо явных проблем.

Ваша программа НЕ использует так много памяти. JVM/OS резервирует эту память, т. е. предел, который может использовать ваша программа. Кроме того, как ясно упоминает один из ответов. 32-битные и 64-битные не имеют к этому никакого отношения. 32-разрядная версия означает, что вы можете получить доступ к 2^32 ячейкам физической памяти. а 64 бит означает до 2^64.