Огромный Пермский ген по сравнению с размером приложения, это нормально?

Question

Я развернул веб-приложение на сервере Glassfish, которое состоит из множества сервисов REST JAX-RS и обработки баз данных через JPA. Файл WAR, который я использовал для развертывания, составляет около 2 МБ, и у него очень мало трафика (всего несколько запросов на тестирование). Из любопытства, я побежал jmap, чтобы взглянуть на использование памяти, и я получил это

using thread-local object allocation. 
Parallel GC with 2 thread(s) 

Heap Configuration: 
MinHeapFreeRatio = 0 
MaxHeapFreeRatio = 100 
MaxHeapSize  = 536870912 (512.0MB) 
NewSize   = 1310720 (1.25MB) 
MaxNewSize  = 17592186044415 MB 
OldSize   = 5439488 (5.1875MB) 
NewRatio   = 2 
SurvivorRatio = 8 
PermSize   = 21757952 (20.75MB) 
MaxPermSize  = 201326592 (192.0MB) 
G1HeapRegionSize = 0 (0.0MB) 

Heap Usage: 
PS Young Generation 
Eden Space: 
capacity = 99090432 (94.5MB) 
used  = 36256552 (34.576942443847656MB) 
free  = 62833880 (59.923057556152344MB) 
36.589357083436674% used 
From Space: 
capacity = 38797312 (37.0MB) 
used  = 13067872 (12.462493896484375MB) 
free  = 25729440 (24.537506103515625MB) 
33.68241593644426% used 
To Space: 
capacity = 37748736 (36.0MB) 
used  = 0 (0.0MB) 
free  = 37748736 (36.0MB) 
0.0% used 
PS Old Generation 
capacity = 70254592 (67.0MB) 
used  = 59577728 (56.8177490234375MB) 
free  = 10676864 (10.1822509765625MB) 
84.80261048274254% used 
PS Perm Generation 
capacity = 135266304 (129.0MB) 
used  = 88929544 (84.80982208251953MB) 
free  = 46336760 (44.19017791748047MB) 
65.74404812598414% used 

Я был очень удивлен, увидев, что Пермь Gen занимает около 84MB памяти для такого маленького приложения. Это число снизилось, когда я перезапустил сервер (это было как раньше 100 МБ, что уже выглядит странным, так как я читал, что perm gen никогда не собирает мусор, так как он может упасть?). Я сомневаюсь: нормально ли получать такое большое количество с таким маленьким приложением? Я фактически развернул и перераспределил приложение довольно много раз в течение прошлых недель, так может ли это быть из-за этого? Приложение работает отлично, поэтому у меня нет особых проблем для решения, я просто задавался вопросом, может ли это вызвать проблемы в будущем. Даже номер пространства Eden для меня большой, 34 МБ используется для приложения, на котором есть один пользователь на данный момент, с пустой базой данных, которая в основном ничего не делает!

EDIT: Я сейчас не развернул приложение и перезапустил сервер (который теперь работает под другим pid). Удивительно для меня, я запустил еще один jmap, и у меня очень похожие числа для perm gen (например, 70MB). Возможно ли, что это связано только со стеклянной рыбкой, и это не имеет никакого отношения к моему приложению?

Answer 1

Одна проблема с Перми Ген является статическими вещами. Статика выделяется из Перми Ген, но не выпускается до тех пор, пока контейнер (Glassfish, Tomcat, ...) не будет перезапущен.

Если статические точки указывают на другой класс (даже если класс не является статическим), то другой класс никогда не будет выпущен. Если приложение перезапускается без перезагрузки контейнера, то память для этого класса не будет выпущена, а другой экземпляр класса будет выделен для нового экземпляра приложения.

Многие классы имеют статические указатели на другие классы. Вы можете попытаться устранить проблему в своем коде, но многие классы Java имеют эту проблему, поэтому это может быть не под вашим контролем.

Отличное сообщение на эту тему: Classloader Leaks.

Ответ на комментарий Glassfish:

Да, это может быть связано с GlassFish. Каждый класс выделяется пермскому генералу, поэтому многие классы подразумевают много пермского генерала. Даже если ваш класс мал, он стоит на плечах гигантов.