Приложение Android продолжает закрываться из-за ошибки OutofMemory [дубликат]

Если эта проблема происходит в Wildfly 8 и JDK1.8, нам нужно указать параметры MaxMetaSpace вместо параметров PermGen.

Например, нам нужно добавить ниже конфигурацию в файле setenv.sh wildfly , JAVA_OPTS="$JAVA_OPTS -XX:MaxMetaspaceSize=256M"

Для получения дополнительной информации, пожалуйста, проверьте Wildfly Heap Issue

аргумент VM работал для меня в eclipse. Если вы используете eclipse версии 3.4, выполните следующие

, перейдите к Run --> Run Configurations -->, затем выберите проект в разделе maven build ->, затем выберите вкладку «JRE» ->, затем введите -Xmx1024m.

В качестве альтернативы вы можете сделать Run --> Run Configurations --> select the "JRE" tab -->, а затем ввести - Xmx1024m

Это должно увеличить кучу памяти для всех сборок / проектов. Вышеуказанный размер памяти составляет 1 ГБ. Вы можете оптимизировать то, что хотите.

Запустите Java с параметром командной строки -Xmx, который устанавливает размер maximum кучи.

Подробнее см. здесь. .

Да, с -Xmx вы можете настроить больше памяти для JVM. Убедитесь, что вы не просачиваетесь и не теряете память. Возьмите кучу кучи и используйте анализатор памяти Eclipse , чтобы проанализировать потребление памяти.

Если вам нужно отслеживать использование вашей памяти во время выполнения, пакет java.lang.management предлагает MBeans, который может использоваться для мониторинга пулов памяти в вашей виртуальной машине (например, пространство с эденом, поколение и т. д.), а также сбор мусора поведение.

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

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

. Легкий способ решить OutOfMemoryError в java - увеличить максимальный размер кучи, используя опции JVM -Xmx512M, это немедленно решит ваш OutOfMemoryError. Это мое предпочтительное решение, когда я получаю OutOfMemoryError в Eclipse, Maven или ANT при построении проекта, потому что в зависимости от размера проекта вы можете легко исчерпать память.

Вот пример увеличения максимального размера кучи JVM , Также лучше сохранить -Xmx -Xms ration либо 1: 1, либо 1: 1.5, если вы задаете размер кучи в своем java-приложении.

export JVM_ARGS="-Xms1024m -Xmx1024m"

Ссылка Ссылка

По умолчанию для разработки JVM использует небольшие размеры и небольшую конфигурацию для других функций, связанных с производительностью. Но для производства вы можете настроить, например. (Кроме того, может существовать конкретная конфигурация сервера приложений) -> (Если памяти недостаточно, чтобы удовлетворить запрос, а куча уже достигла максимального размера, произойдет выход OutOfMemoryError)

-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size

-XX:ParallelGCThreads=8
-XX:+CMSClassUnloadingEnabled
-XX:InitiatingHeapOccupancyPercent=70
-XX:+UnlockDiagnosticVMOptions
-XX:+UseConcMarkSweepGC
-Xms512m
-Xmx8192m
-XX:MaxPermSize=256m (in java 8 optional)

Например: В предпочтительной настройке для платформы Linux для режима производства.

После загрузки и настройки сервера таким образом http://www.ehowstuff.com/how-to-install-and-setup-apache-tomcat-8-on-centos-7- 1-rhel-7 /

1.create setenv.sh файл в папке / opt / tomcat / bin /

   touch /opt/tomcat/bin/setenv.sh

2.Откройте и напишите этот параметр для настройки предпочтительного режима.

nano  /opt/tomcat/bin/setenv.sh 

export CATALINA_OPTS="$CATALINA_OPTS -XX:ParallelGCThreads=8"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+CMSClassUnloadingEnabled"
export CATALINA_OPTS="$CATALINA_OPTS -XX:InitiatingHeapOccupancyPercent=70"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UnlockDiagnosticVMOptions"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseConcMarkSweepGC"
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxMetaspaceSize=256M"

3. service tomcat restart

Обратите внимание, что JVM использует больше памяти, чем только кучу. Например, методы Java, стеки потоков и собственные дескрипторы выделяются в памяти отдельно от кучи, а также внутренние структуры данных JVM.

Я читал где-то еще, что вы можете попробовать - поймать java.lang.OutOfMemoryError и в блоке catch вы можете освободить все ресурсы, которые, как вы знаете, могут использовать много памяти, тесные соединения и т. д., затем выполните System.gc () затем повторите попытку, что бы вы не сделали.

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

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

//Mimimum acceptable free memory you think your app needs
long minRunningMemory = (1024*1024);

Runtime runtime = Runtime.getRuntime();

if(runtime.freeMemory()<minRunningMemory)
 System.gc();

Большое оговорку ---- в моем офисе мы обнаружили, что (на некоторых машинах Windows) мы не могли выделить более 512 м для кучи Java. Это оказалось связано с тем, что на некоторых из этих компьютеров установлен антивирус Касперского. После удаления этого AV-продукта мы обнаружили, что мы могли бы выделить не менее 1,6 ГБ, т. Е. -Xmx1600m (m является обязательным, иначе он приведет к другой ошибке «Слишком маленькая начальная куча»).

Нет идеи если это происходит с другими AV-продуктами, но, по-видимому, это происходит, потому что программа AV резервирует небольшой блок памяти в каждом адресном пространстве, тем самым предотвращая одно очень большое выделение.

Выполните следующие шаги:

1. Откройте файл catalina.sh из tomcat / bin.
2. Chnage JAVA_OPTS в

   JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1536m 
   -Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m 
   -XX:MaxPermSize=256m -XX:+DisableExplicitGC"
   

3. Перезапустите ваш tomcat

Вы можете указать для каждого проекта, сколько места кучи хочет ваш проект

Ниже приводится для Eclipse Helios / Juno / Kepler:

Щелкните правой кнопкой мыши на

 Run As - Run Configuration - Arguments - Vm Arguments, 

, затем добавьте это

-Xmx2048m

Если вы продолжаете выделять & amp; сохраняя ссылки на объект, вы будете заполнять любой объем памяти, который у вас есть.

Один из вариантов заключается в том, чтобы закрыть прозрачный файл & amp; открываются, когда они переключают вкладки (вы сохраняете только указатель на файл, а когда пользователь переключает вкладку, вы закрываете и очищаете все объекты ... это заставит файл менять медленнее ... но ...), и, возможно, хранить только 3 или 4 файла в памяти.

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

Ваша идея динамически расширяющейся виртуальной памяти не решает проблему, поскольку машина ограничена ресурсами, поэтому вы должны быть осторожны и amp; [или g3]

Несколько советов, которые я видел с утечками памяти:

-> Имейте в виду, что если вы поместите что-то в коллекцию, а потом забудьте об этом, вы все еще имеете к ней сильную ссылку, поэтому уничтожаете коллекцию, очищаете ее или делаете что-то с ней ... если нет, вам будет трудно найти утечку памяти.

-> Возможно, использование коллекций со слабыми ссылками (weakhashmap ...) может помочь в проблемах с памятью, но вы должны быть осторожны с ним, поскольку вы можете обнаружить, что объект, который вы искали, был собран.

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

Я столкнулся с такой же проблемой размера кучи java. У меня есть два решения, если вы используете java 5 (1.5).

1st: просто установите jdk1.6 и перейдите к настройкам eclipse и установите jre-путь jav1 1.6 по мере того, как вы установили

2nd: -Проверьте свой аргумент VM и пусть он будет тем, чем он является. просто добавьте одну строку ниже всех аргументов, присутствующих в аргументах VM, как -Xms512m -Xmx512m -XX: MaxPermSize = ... m (192m).

Я думаю, что это сработает ...

Обратите внимание, что если вам это нужно в ситуации развертывания, подумайте о том, чтобы использовать Java WebStart (с версией «ondisk», а не сетевой, возможно в Java 6u10 и более поздней версии), поскольку он позволяет вам указать различные аргументы JVM в кросс-платформенном способе.

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

Что касается netbeans, вы можете установить максимальный размер кучи, чтобы решить проблему. Во-первых, перейдите в «Выполнить», затем -> «Настроить конфигурацию проекта» -> «Настроить» -> «Запустить» его всплывшего окна -> «Вариант VM» -> заполнить '-Xms2048m - Xmx2048m.