Утечка памяти LDAP PermGen

Question

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

Я создал простой веб-приложение, демонстрирующее утечку, она включает в себя только этот класс:

@WebListener 
public class LDAPLeakDemo implements ServletContextListener { 
    public void contextInitialized(ServletContextEvent sce) { 
     useLDAP(); 
    } 

    public void contextDestroyed(ServletContextEvent sce) {} 

    private void useLDAP() { 
     Hashtable<String, Object> env = new Hashtable<String, Object>(); 
     env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); 
     env.put(Context.PROVIDER_URL, "ldap://ldap.forumsys.com:389"); 
     env.put(Context.SECURITY_AUTHENTICATION, "simple"); 
     env.put(Context.SECURITY_PRINCIPAL, "cn=read-only-admin,dc=example,dc=com"); 
     env.put(Context.SECURITY_CREDENTIALS, "password"); 
     try { 
      DirContext ctx = null; 
      try { 
       ctx = new InitialDirContext(env); 
       System.out.println("Created the initial context"); 
      } finally { 
       if (ctx != null) { 
        ctx.close(); 
        System.out.println("Closed the context"); 
       } 
      } 
     } catch (NamingException e) { 
      e.printStackTrace(); 
     } 
    } 
} 

Исходный код доступен here. Я использую a public LDAP test server для этого примера, поэтому он должен работать для всех, если вы хотите попробовать. Я попробовал это с последними версиями JDK 7 и 8 и Tomcat 7 и 8 с таким же результатом - когда я нажимаю «Обновить» в Tomcat Web Application Manager, а затем «Найти утечки», Tomcat сообщает, что есть утечка, и профайлеры подтверждают это.

В этом примере утечка едва заметна, но она вызывает OutOfMemory в большом веб-приложении. Я не нашел никаких открытых ошибок JDK.

UPDATE 1

Я пытался использовать Jetty 9.2 вместо Tomcat, и я до сих пор вижу утечку, так это не вина Tomcat. Либо это ошибка JDK, либо я делаю что-то неправильно.

UPDATE 2

Хотя мой пример демонстрирует утечку, он не демонстрирует отказ от ошибки памяти, поскольку он имеет очень маленький PermGen след. Я создал another branch, который должен иметь возможность воспроизводить OutOfMemoryError. Я просто добавил зависимости Spring, Hibernate и Logback к проекту, чтобы увеличить потребление PermGen. Эти зависимости не имеют ничего общего с утечкой, и я мог бы использовать любые другие. Единственная цель - сделать потребление PermGen достаточно большим, чтобы получить OutOfMemoryError.

Действия по воспроизведению OutOfMemoryError:

1. Скачать или клонировать outofmemory-demo branch.

2. Убедитесь, что у вас есть JDK 7 и любая версия Tomcat и Maven (я использовал последние версии - JDK 1.7.0_79 и Tomcat 8.0.26).

3. Уменьшите размер PermGen, чтобы увидеть сообщение об ошибке после первой перезагрузки. Создайте setenv.bat (Windows) или setenv.sh (Linux) в каталоге bin Tomcat и добавьте set "JAVA_OPTS=-XX:PermSize=24m -XX:MaxPermSize=24m" (Windows) или export "JAVA_OPTS=-XX:PermSize=24m -XX:MaxPermSize=24m" (Linux).

4. Перейдите в каталог confc Tomcat, откройте tomcat-users.xml и добавьте <role rolename="manager-gui"/><user username="admin" password="1" roles="manager-gui"/> внутри <tomcat-users></ tomcat-users>, чтобы иметь возможность использовать Tomcat Web Application Manager.

5. Перейдите в каталог проекта и используйте mvn package, чтобы построить .war.

6. Перейдите в каталог webapps Tomcat, удалите все, кроме каталога менеджера, и скопируйте здесь .war здесь.

7. Run для Tomcat сценарий запуска (бен \ startup.bat или бен/startup.sh) и открытым http://localhost:8080/manager/, используйте имя пользователя и пароль администратора 1.

8. Кликните на Reload, и вы должны увидеть java.lang.OutOfMemoryError: пространство PermGen в консоли Tomcat.

9. Остановить Tomcat, открыть исходный файл проекта src\main\java\org\example\LDAPLeakDemo.java, удалить useLDAP(); и сохранить его.

10. Повторите шаги 5-8, только на этот раз нет OutOfMemoryError, потому что код LDAP никогда не вызывается.

Answer 1

Прежде всего: Да, API LDAP, предоставляемый Sun/Oracle, может вызывать утечки ClassLoader. Он находится на my list of known offenders, потому что если системное свойство com.sun.jndi.ldap.connect.pool.timeout> 0 com.sun.jndi.ldap.LdapPoolManager будет порождать новый поток, запущенный в веб-приложении, который первым вызвал LDAP.

Это, как говорится, я добавил ваш пример кода в качестве тестового примера в моем ClassLoader Leak Prevention library, так что я получил бы автоматический сброс кучи утечки. Согласно моему анализу, на самом деле нет никакой утечки в вашем коде, однако, похоже, для принятия рассматриваемого класса ClassLoader требуется несколько циклов сбора мусора. GC: ed (возможно, из-за переходных ссылок) не вникнул в него, что много). Вероятно, это позволяет Томкату полагать, что есть утечка, даже если ее нет.

Однако, так как вы говорите, что в конце концов получаете OutOfMemoryError, либо я ошибаюсь, либо что-то еще в вашем приложении вызывает эти утечки. Если вы добавите my ClassLoader Leak Prevention library в свое приложение, оно все еще течет/вызывается OOME s? Предотвращает ли предупреждение предупреждение?

Если вы настроили сервер приложений для создания дампа кучи всякий раз, когда есть OOME, вы можете искать утечку с помощью Eclipse Memory Analyzer. Я подробно объяснил процесс here.