2015-08-20 4 views
4

У меня есть приложение, которое при запуске запрашивает определенный объем ОЗУ с помощью следующей команды.Java JVM Размер кучи

java -Xms512m -Xmx985m -jar someJarfile.jar 

Эта команда не запускается на моем компьютере с 8.0GB оперативной памяти, поскольку он не может создать объект кучи указанного размера. Если я опустил максимальный диапазон до уровня менее 700 МБ, он отлично работает.

Что еще странно, так это то, что даже простое java -Xmx768m -version терпит неудачу, когда значение флага -Xmx превышает 700 м. Я пытаюсь запустить его с Java 1.7Uu67 32-bit (это то, с чем была построена банка) и даже более новые версии Java 1.7 и event Java 1.8. Я бы понял, была ли максимальная куча выше, и я использовал 32-битную, но она не выше кепки ~ 1,4 ГБ 32-битной java

Есть ли параметр конфигурации, который я где-то пропал без вести, какое-то программное обеспечение, которое может мешать? Для меня не имеет смысла, почему я не могу выделить 700 МБ ОЗУ на машине с 8,0 ГБ ОЗУ. I

Следует также отметить, что никаких других процессов не выполняется, которые занимают всю мою оперативную память. Это новая установка Windows 7.

+1

Вы пробовали 64-битную виртуальную машину? – the8472

+1

Попробуйте использовать версию java x64 –

+1

Java требует большой смежной области виртуальной памяти для кучи, с которой 32 бит Windows борется. –

ответ

3

Вам следует попробовать использовать 64-битное Java Runtime. Вероятно, что в 32-разрядном адресном пространстве вашего компьютера нет свободного объема памяти объемом 985 МБ (32-битное адресное пространство 4 ГБ). Когда вы используете 64-битное Java Runtime, Java может выделять память в 64-разрядном адресном пространстве, в котором свободная память гораздо более доступна.

Не имеет значения, что ваш файл JAR был создан с использованием 32-разрядной версии.

+0

@ MZimmerman6 это короткий ответ, я дал более длинный ответ, почему вы действительно не должны использовать 32-бит, если у вас нет выбора. Устаревшие 32-разрядные библиотеки DLL являются одной из причин. –

+0

@PeterLawrey См. Проблему: я не знаю, есть ли 32-битные вещи в этом файле .jar. Кажется, он не хочет работать с 64-битным – MZimmerman6

+0

@ MZimmerman6, возможно, вы могли бы попытаться решить эти проблемы. –

4

Хотя 700 МБ довольно низкое, это не удивительно.

32-разрядный эмулятор Windows XP в Windows работает так же, как Windows XP со всеми его ограничениями. Это означает, что вы потеряете 2 ГБ или потенциал 4 ГБ для ОС. Это означает, что уже запущенные программы используют пространство виртуальной памяти. Кроме того, если ваша программа использует разделяемые библиотеки или хранилище кучи, например прямую память и файлы с отображением памяти, это означает, что вы потеряете виртуальную память для кучи. Эффективно вы ограничены 1,4 ГБ виртуальной памяти для своих приложений независимо от того, сколько памяти у вас на самом деле.

Простой способ использования 64-разрядной JVM, который работает в вашей 64-разрядной ОС, а также ограничен, но вместо этого - 192 ТБ виртуальной памяти в Windows.

+0

Я понятия не имел, что, когда вы используете 32-битную версию части программного обеспечения, которую она должна эмулировать 32-битные окна, а затем она предоставляет ограничения – MZimmerman6

+0

@ MZimmerman6, она должна сделать это, чтобы обеспечить максимальную совместимость. –

2

Ответ на ваш вопрос может заключаться в том, что Windows пытается и не может найти непрерывный блок памяти, достаточно большой: см. http://javarevisited.blogspot.nl/2013/04/what-is-maximum-heap-size-for-32-bit-64-JVM-Java-memory.html. (Хотя это говорит о том, что другие процессы забивают память, что, кажется, противоречит вашему последнему замечанию.)