Когда и как Java classloader отмечен для сборки "мусора"?

Мы создаем несколько дочерний classloaders для загрузки в нескольких подприложениях в JAVA-приложение "контейнера", моделируя горячее развертывание. Когда путь к классу конкретного classloader изменился (т.е. банки были добавлены, удалены, обновлены), старый classloader выброшен (не имеющий ссылки), и новый classloader создается для нового пути к классу банок.

После обновления пути к классу, инициировав горячее развертывание, мы взяли дамп "кучи". Дамп "кучи" (использующий Память Анализатор) указывает, что старые classloaders не собирались "мусор". Определенные классы в родителе classloader кэшировали старый classloaders. Следующие вещи были вызваны для очистки этих кэшей:

java.lang.ResourceBundle.clearCache(classLoader);
org.apache.commons.logging.LogFactory.release(classLoader);
java.beans.Introspector.flushCaches();

Даже после очистки вышеупомянутых кэшей, старые classloader все еще не собирались "мусор". Остающиеся ссылки на classloader включали следующее:

• классы загружаются classloader
• java.lang. Пакет создал самим classloader
• java.lang. ProtectionDomain, созданный самим classloader

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