Ну тогда после сборки сам java процесс должен перестать столько

Джава - это менеджед язык. Это означает, что памятью управляет автоматика, всем известная скучная теория: есть хип, в хип всё складывается, когда хип забивается, он очищается сборщиком мусора. Вывод из этого такой, что есть некоторый предельный размер хипа, до которого мы считаем, что потребляется разумное количество памяти, и по достижению очищаем. С первого взгляда кажется что между сборками можно отдавать память обратно операционке, пока хип не забит, чтобы ею могли бы пользоваться другие, но на деле это не имеет смысла: 1. Амортизированное потребление памяти остается таким же вне зависимости от того, отдаете вы пустой хип или нет. Иметь чуть больше памяти в целом приятно, но если у вас например два джава-процесса, у каждого из которых в Xmax 60% доступной оперативки машины - вам нужно идеально синхронизировать их циклы сборщика, чтобы они не нахлестнулись пиковым потреблением, что в общем случае невозможно. Другими словами, даже если отдавать память назад операционке, _гарантированный_ объем свободной памяти остается тем же, а нас с точки зрения стабильности интересует именно он. 2. Отдавать и забирать память в целом не бесплатно и требует времени. Джава, как и любой аналогичный проект, будет конкурировать за mission-critical приложения, и стремиться к тому, чтобы базовые операции типа выделения памяти в общем случае занимали константное время. Если же вы не знаете, займет выделение объекта наносекунды или сотни наносекунд, возле HFT делать вообще нечего. Отсюда еще вытекает -XX:AlwaysPreTouch. 3. Отдавать и забирать память ведет к фрагментированию памяти процесса относительно физической памяти (т.е. если постоянно забирается и отпускается четыре страницы, то вероятность того, что они через какое-то время будут лежать последовательно, на реальной системе околонулевая). Вообще само по себе это не трагедия автоматом, но можно добиться случая, когда оперативки свободной много, а длинный кусок из нее выделить нельзя. 4. Наконец, не каждый ГЦ дефрагментирует хип, поэтому отдавать может быть вообще не так много - есть страница, на странице лежит одинокий объект, обратно ты её уже не вернешь. Наконец, как происходит работа с памятью в самой операционке. Выделение памяти происходит в два этапа - сначала приложение запрашивает память, и операционка просто отмечает, какие адреса приложению теперь доступны, а потом приложение начинает реально по этим адресам читать и писать - и вот только тут операционка начинает реально выделять память. Поэтому никто не мешает джаве или любому другому процессу выделить больше памяти, чем есть вообще на хосте, и просто никогда ею не пользоваться - в этом случае реально занимать память никто не будет (гуглить go 10gb hack). Поэтому изначальный вопрос про потребление памяти сводится не к тому, чтобы взять рандомной показатель потребления, а именно либо резидентную память, либо, еще лучше, запросить у джавы реальный размер хипа, потому что в общем случае нас не интересуют траты на инфраструктуру типа метаспейсов и прочего, в 99% проблема не в жвм, а в приложении, на нем бегущем.

0

13.05.2022

Владислав Хакин

Etki
Джава - это менеджед язык. Это означает, что памят...

Пойду переваривать, спасибо

0

13.05.2022

Etki · Accepted Answer

Etki

Идти и читать, идти и читать

0

13.05.2022

170 похожих чатов

Ну тогда после сборки сам java процесс должен перестать столько

5 ответов

Похожие вопросы