Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
продолжение будет? к примеру выгрузка старого модуля и загрузка нового? описание каких-то других нетривиальных особенностей?
на практике, к сожалению, часто бывает OutOfMemoryError: PermGen space
причина явно не в принципе динамической реализации загрузки классов, а в частной реализации
При любой реализации после загрузки/выгрузки определенного количества более-менее сложного кода случится Perm.
у меня в одном из проектов есть реализация сложного механизма класс-лоадеров, все работает замечательно. Главное правильно сделать все. Т.е. проблема решается. К примеру, в Rhino (имплементация javascript на java) была указанная вами проблема, однако, залез внутрь переписал одно из мест, работает отлично.
А что именно в Rhino приводило к проблеме? Сам именно в Rhino не столкнулся, хотя и предполагал, что может начаться.
при каждом вызове скрипта Rhino генерит один из классов который отвечает за работу оператора print, причем этот класс постоянно имеет новое имя. При периодическом вызове скрипта каждую секунду, сервак падал с ошибкой OutOfMemoryError, после рефактиринга работает многие сутки напролет.
Или вы имеете в виду частную реализацию JVM? Тогда да, но ни одна из распространенных этой проблемы не избежала.
Говорят JRockIt умеет. Думаете маркетинг?
Сам не сталкивался, однако знаю от коллег, что многократный ридиплой в аппсервер на ней так же приводит к ошибке. Даже если там нет прямого эквивалента сановского Perm, что-то приводит к аналогичному сбою управления кучей (или где там у них лежат классы).
Считаю нужным пояснить, что в первом комментарии я скорее имел в виду, что JVM склонны давать такую ошибку не смотря на принимаемые меры в виде аккуратного кодирования, правильной работы с загрузчиками и настройки машины свичами и т.п. Как показывает практика, эти меры имеют разный эффект для разных машин, и проблема скорее лежит в том, что поведение загрузчиков не специфицировано должным образом. Поэтому динамическая подгрузка классов может быть компромиссом между надежностью системы и сложностью развертывания, и в некоторых случаях неизбежна.
Считаю нужным пояснить, что в первом комментарии я скорее имел в виду, что JVM склонны давать такую ошибку не смотря на принимаемые меры в виде аккуратного кодирования, правильной работы с загрузчиками и настройки машины свичами и т.п. Как показывает практика, эти меры имеют разный эффект для разных машин, и проблема скорее лежит в том, что поведение загрузчиков не специфицировано должным образом. Поэтому динамическая подгрузка классов может быть компромиссом между надежностью системы и сложностью развертывания, и в некоторых случаях неизбежна.
Нет. В Hotspot объем class metadata ограничен размером Permanent Generation (по умолчанию 64Mb). В JRockit объем class metadata не ограничен, т.е. классы будут загружаться, пока есть свободная физическая и/или виртуальная память. Таким образом, JRockit лишь откладывает проявление утечек памяти, но не избавляет от них насовсем.
на практике, к сожалению, часто бывает OutOfMemoryError: PermGen space
Только в случае утечки памяти. Но на практике, тут Вы правы, утечки памяти бывают часто, даже у опытных Java программистов. Тем не менее, при выгрузке классов Hotspot вычищает из PermGen ВСЕ, что к ним относится, т.е. приложение с правильной организацией динамической загрузки может работать сколь угодно долго.
P.S. Кстати, хорошая новость: скоро PermGen исчезнет из Hotspot'а насовсем.
Стоит отметить, что выгрузка классов производится только после того, как соответствующий загрузчик стал недостижим.
Поскольку в данном примере загрузчик живет все время работы приложения, то вероятность такой ошибки при большом числе модулей достаточно велика.
Чтобы ее не происходил можно, например, менять загрузчик после загрузки каждых N модулей.
Поскольку в данном примере загрузчик живет все время работы приложения, то вероятность такой ошибки при большом числе модулей достаточно велика.
Чтобы ее не происходил можно, например, менять загрузчик после загрузки каждых N модулей.
Не очень понятна семантика Module.unload(), а вообще да, пишите продолжение. Не забудьте про зависимости между модулями и грабли в виде ClassCastException. И ссылку на OSGi или что-нибудь подобное.
Эх… помню, как в зеленой юности писал свой загрузчик с собственным кэшем загруженных классов.
Потом почитал спецификацию java машины, и все переделал в несколько строк, примерно как в этой статье =)
Потом почитал спецификацию java машины, и все переделал в несколько строк, примерно как в этой статье =)
Если кому интересно, то я когда-то по теме заметку опубликовал — «Java :: classpath менеджмент во время выполнения» — itfreak.ru/21
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Загрузка классов в Java. Практика