Работа с ошибкой &quot;java.lang.OutOfMemoryError: PermGen space&quot;

Источник

user1087971 08 дек '11 в 14:51

jrockit решил и это для меня; Тем не менее, я заметил, что время перезапуска сервлета было намного хуже, поэтому, хотя он был лучше в производстве, это было своего рода тормозом в развитии.

Источник

user4276 18 сен '08 в 02:09

Задавать -XX:PermSize=64m -XX:MaxPermSize=128m, Позже вы также можете попробовать увеличить MaxPermSize, Надеюсь, это сработает. То же самое работает для меня. Настройка только MaxPermSize не работал для меня.

Источник

user327487 28 апр '10 в 04:51

У меня есть комбинация Hibernate+Eclipse RCP, пробовал использовать -XX:MaxPermSize=512m а также -XX:PermSize=512m и это, кажется, работает для меня.

Источник

01 июл '09 в 04:54

Они говорят, что последняя версия Tomcat (6.0.28 или 6.0.29) намного лучше справляется с задачей повторного развертывания сервлетов.

Источник

user449693 19 сен '10 в 12:31

Первый шаг в таком случае - проверить, разрешено ли GC выгружать классы из PermGen. Стандартная JVM довольно консервативна в этом отношении - классы рождены, чтобы жить вечно. Поэтому после загрузки классы остаются в памяти, даже если их больше не использует ни один код. Это может стать проблемой, когда приложение динамически создает много классов, и сгенерированные классы не нужны в течение более длительных периодов времени. В таком случае может помочь JVM выгрузить определения классов. Это может быть достигнуто путем добавления только одного параметра конфигурации в ваши сценарии запуска:

-XX:+CMSClassUnloadingEnabled

По умолчанию для этого параметра установлено значение false, поэтому для его включения необходимо явно указать следующую опцию в параметрах Java. Если вы включите CMSClassUnloadingEnabled, GC также будет сканировать PermGen и удалять классы, которые больше не используются. Имейте в виду, что этот параметр будет работать только в том случае, если UseConcMarkSweepGC также включен с использованием указанного ниже параметра. Поэтому при запуске ParallelGC или, не дай Бог, Serial GC, убедитесь, что вы установили GC на CMS, указав:

-XX:+UseConcMarkSweepGC

Источник

user2680640 05 янв '16 в 01:04

Назначение Tomcat дополнительной памяти НЕ является правильным решением.

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

Если ваш сервер Tomcat/Webapp сообщает, что не удалось отменить регистрацию драйверов (JDBC), отмените их регистрацию. Это остановит утечки памяти.

Вы можете создать ServletContextListener и настроить его в своем файле web.xml. Вот пример ServletContextListener:

import java.sql.Driver;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.apache.log4j.Logger;

import com.mysql.jdbc.AbandonedConnectionCleanupThread;

/**
 * 
 * @author alejandro.tkachuk / calculistik.com
 *
 */
public class AppContextListener implements ServletContextListener {

    private static final Logger logger = Logger.getLogger(AppContextListener.class);

    @Override
    public void contextInitialized(ServletContextEvent arg0) {
        logger.info("AppContextListener started");
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0) {
        logger.info("AppContextListener destroyed");

        // manually unregister the JDBC drivers
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
                logger.info(String.format("Unregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                logger.info(String.format("Error unregistering driver %s", driver), e);
            }

        }

        // manually shutdown clean up threads
        try {
            AbandonedConnectionCleanupThread.shutdown();
            logger.info("Shutting down AbandonedConnectionCleanupThread");
        } catch (InterruptedException e) {
            logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
            e.printStackTrace();
        }        
    }
}

И вот вы настраиваете это в своем файле web.xml:

<listener>
    <listener-class>
        com.calculistik.mediweb.context.AppContextListener 
    </listener-class>
</listener>

Источник

user4987783 25 апр '16 в 17:13

Конфигурация памяти зависит от характера вашего приложения.

Что делаешь?

Какое количество транзакций обработано?

Сколько данных вы загружаете?

и т.п.

так далее

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

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

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

Источник

user20654 11 мар '09 в 22:24

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

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

Эта ссылка (также упоминавшаяся ранее) предоставила достаточно внутренностей для решения проблемы. Перемещение jdbc-(mysql)-драйвера из WEB-INF в папку jre/lib/ext/, похоже, решило проблему. Это не идеальное решение, так как обновление до новой JRE потребует переустановки драйвера. Другим кандидатом, который может вызвать аналогичные проблемы, является log4j, так что вы можете захотеть переместить и этот.

Источник

user549635 19 мар '11 в 11:38

У меня была похожая проблема. Мой JDK 7 + Maven 3.0.2 + Struts 2.0 + Google GUICE проект, основанный на внедрении зависимостей.

Всякий раз, когда я пытался бежать mvn clean package команда показала следующую ошибку и произошла ошибка "BUILD FAILURE"

org.apache.maven.surefire.util.SurefireReflectionException: java.lang.reflect.InvocationTargetException; Вложенное исключение - java.lang.reflect.InvocationTargetException: null java.lang.reflect.InvocationTargetException. Причина: java.lang.OutOfMemoryError: пространство PermGen.

Я испробовал все вышеперечисленные полезные советы и рекомендации, но, к сожалению, ни один из них не помог мне. То, что сработало для меня, описано шаг за шагом ниже:=>

Перейти к вашему pom.xml
Ищи <artifactId>maven-surefire-plugin</artifactId>
Добавить новый <configuration> элемент, а затем <argLine> подэлемент, в котором проходят -Xmx512m -XX:MaxPermSize=256m как показано ниже =>

<configuration> <argLine>-Xmx512m -XX:MaxPermSize=256m</argLine> </configuration>

Надеюсь, это поможет, счастливого программирования:)

Источник

user3927323 04 сен '15 в 09:33

Если вы получаете это в Eclipse IDE, даже после установки параметров --launcher.XXMaxPermSize, -XX:MaxPermSizeи т. д., тем не менее, если вы получаете ту же ошибку, скорее всего, затмение использует ошибочную версию JRE, которая была бы установлена некоторыми сторонними приложениями и установлена по умолчанию. Эти версии с ошибками не принимают параметры PermSize, и поэтому независимо от того, что вы установили, вы все равно будете получать эти ошибки памяти. Итак, в ваш eclipse.ini добавьте следующие параметры:

-vm <path to the right JRE directory>/<name of javaw executable>

Также убедитесь, что вы установили JRE по умолчанию в настройках затмения для правильной версии Java.

Источник

user512126 18 ноя '10 в 12:48

"Они" не правы, потому что я работаю 6.0.29 и у меня та же проблема, даже после установки всех параметров. Как сказал Тим Хоулэнд выше, эти варианты только откладывают неизбежное. Они позволяют мне выполнить повторное развертывание 3 раза, прежде чем совершать ошибку, а не каждый раз, когда я повторяю развертывание

Источник

user156588 20 сен '10 в 17:40

Единственный способ, который работал для меня, был с JRockit JVM. У меня есть MyEclipse 8.6.

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