Алгоритмы, которые приводят к java.lang.OutOfMemoryError: ошибка пространства PermGen

Кто-нибудь знает примеры алгоритмов, приводящих к переполнению PermGen?

Да, но какой в ​​этом смысл? если вы хотите исправить это, установите инструмент профилирования памяти, такой как jprobe или лямбда-зонд, и проверьте, где происходит утечка памяти, и исправьте это. Теперь для примера: есть тысячи способов превзойти перманентное пространство. Я заметил в проекте, когда мы унаследовали приложение, в котором они использовали JMS. Соединения jms были оставлены открытыми, приложение рухнуло через несколько минут после того, как оно получило много запросов с такой же ошибкой, как и вы. Обратите внимание: когда мы перешли на weblogic с jboss (перешли на beajrockit), он удивительным образом исправился или, по крайней мере, принял на себя удар технического долга. Мой совет, независимо от этого, сначала следует исправить плохой код с утечками памяти, а затем возиться с серверами приложений и параметрами распределения пространства в куче.

Вот полезная ссылка с некоторой информацией об исключении, которое вы получаете. http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang

ИЗМЕНИТЬ

Эта ссылка может быть полезна http://www.precisejava.com/javaperf/j2ee/JMS.htm

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

    Random rnd = new Random();
    List<String> interned = new ArrayList<String>();
    for (;;) {
        int length = rnd.nextInt(100);
        StringBuilder builder = new StringBuilder();
        String chars = "abcdefghijklmnopqrstuvwxyz";
        for ( int i = 0; i < length; i++ ) {
            builder.append(chars.charAt(rnd.nextInt(chars.length())));
        }
        interned.add(builder.toString().intern());
    }

Вкратце: интернирование строк — это то, что может съесть память PermGen.

Есть две вещи, которые могут привести к проблемам с пространством PermGen:

1. Метод String.intern(String) создает строки в куче PermGen. Если вы много интернируете и прямо (или косвенно) сохраняете ссылки на интернированные строки, вы можете заполнить PermGen.

2. Загрузчики классов создают внутренние дескрипторы классов JVM и сегменты кода в куче PermGen. Если ваше приложение выполняет большую динамическую загрузку классов, а объекты класса не удаляются сборщиком мусора, вы можете заполнить PermGen.

Горячее повторное развертывание веб-приложений Java основано на динамической загрузке и является распространенным источником проблем PermGen. Основной причиной обычно является утечка памяти, связанная со скрытой ссылкой какого-либо объекта на старый загрузчик классов. (Tomcat часто получает за это "палку", но реальная проблема обычно заключается в перераспределяемом веб-приложении.)

Насколько мне известно, случай с прокси, упомянутый @Michael Borgwardt, также является результатом того, что реализация Proxy генерирует файлы классов и загружает их на лету.

Если вы используете java.lang.reflect.Proxy очень интенсивно, что также может занять место в PermGen.

Проверьте анализатор памяти — http://www.eclipse.org/mat/. Это анализатор дампа памяти Java. Это очень полезно после неожиданной ошибки.

Вы используете другой сборщик мусора?

Сборщик пропускной способности выдаст исключение нехватки памяти, если на сборку мусора тратится слишком много времени. Например, если JVM тратит более 98 % общего времени на сборку мусора и восстанавливает менее 2 % кучи, это вызовет ожидание нехватки памяти. Реализация этой функции изменилась в версии 1.5. Политика та же, но могут быть небольшие отличия в поведении из-за новой реализации». «В версии 1.5 платформы J2SE сборщик пропускной способности будет выбран в качестве сборщика мусора на машинах серверного класса». http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Ознакомьтесь с некоторыми инструкциями на этом< /а> страница.