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