Пустое пространство Java из памяти

Нет возможности динамически увеличивать кучу программно, поскольку куча выделяется при запуске виртуальной машины Java.

Однако вы можете использовать эту команду

java -Xmx1024M YourClass 

для установки памяти на 1024

или вы можете установить минимальное значение max

 java -Xms256m -Xmx1024m YourClassNameHere 

Если вы используете большую часть памяти и сталкиваетесь с утечками памяти, вы можете проверить, используете ли вы большое количество ArrayList или HashMap s со многими элементами.

ArrayList реализуется как динамический массив . Исходный код Sun / Oracle показывает, что при вставке нового элемента в полный массив ArrayList создается новый массив размером в 1,5 раза от исходного массива, а элементы копируются. Это означает, что вы можете тратить до 50% пространства в каждом используемом вами ArrayList , если вы не вызываете его метод trimToSize . Или еще лучше, если вы знаете количество элементов, которые вы собираетесь вставить перед началом, затем вызовите конструктор с начальной емкостью в качестве аргумента.

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

Существуют различные инструменты, которые можно использовать для диагностики этой проблемы. JDK включает JVisualVM , который позволит вам подключиться к вашему запущенному процессу и показать, какие объекты могут выходить из-под контроля. У Netbeans есть обертка вокруг, которая работает достаточно хорошо. Eclipse имеет анализатор памяти Eclipse, который я использую чаще всего, просто кажется, что обрабатывает большие файлы дампов немного лучше. Также есть опция командной строки, -XX: + HeapDumpOnOutOfMemoryError , которая даст вам файл, который в основном представляет собой моментальный снимок вашей памяти процесса при сбое вашей программы. Вы можете использовать любой из вышеупомянутых инструментов, чтобы посмотреть на него, это может очень помочь при диагностике подобных проблем.

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

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

-> Щелкните правой кнопкой мыши на проекте, выберите RunAs -> Run configurations

Выберите проект как BaseDirectory. Вместо целей дают eclipse: eclipse install

-> Во второй вкладке укажите -Xmx1024m как аргументы VM.

Я хотел бы добавить, что эта проблема похожа на обычную утечку памяти Java.

Когда сборщик мусора JVM не сможет очистить «отработанную» память вашего приложения Java / Java EE с течением времени, результатом станет Outpost OutOfMemoryError: Java .

Важно сначала провести надлежащую диагностику:

• Включить подробный: gc . Это позволит вам понять структуру памяти с течением времени.
• Создайте и проанализируйте дамп кучи JVM . Это позволит вам понять объем памяти приложения и определить источник утечки памяти.
• Вы также можете использовать профилировщики Java и анализатор утечки памяти во время работы, такие как Plumbr, чтобы помочь вам в решении этой задачи.

Попробуйте добавить -Xmx для большей памяти ( java -Xmx1024M YourClass ) и не забудьте перестать ссылаться на переменные, которые вам больше не нужны (утечки памяти).

Поддерживаете ли вы ссылки на переменные, которые вам больше не нужны (например, данные из предыдущих симуляций)? Если это так, у вас есть утечка памяти. Вам просто нужно найти, где это происходит, и убедиться, что вы удалите ссылки на переменные, когда они больше не нужны (это произойдет автоматически, если они выйдут из области).

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

Предполагается, что Java очищает пространство кучи, когда все объекты больше не ссылаются. Обычно он не отпустит его обратно в ОС, но он сохранит эту память для собственного внутреннего повторного использования. Возможно, проверьте, есть ли у вас какие-то массивы, которые не очищаются или что-то в этом роде.

Нет. Куча очищается сборщиком мусора всякий раз, когда ему кажется. Вы можете попросить его запустить (с помощью System.gc() ), но это не гарантируется.

Сначала попробуйте увеличить память, установив -Xmx256m