Руководство Как работает управление памятью в Java

Практически каждый день в чатах хостингов, на форумах, и других сообществах задаются вопросы, касающиеся высокого потребления оперативной памяти или её скачков, при этом задают их зачастую и весьма продвинутые пользователи. В этой статье мы разберёмся на самом простом языке, почему потребление озу на вашем сервере постоянно скачет, почему аргументы запуска Xmx и Xms стоит выставлять одинаковыми, почему выделять много оперативной памяти плохая идея, и когда стоит поднимать тревогу.

Скачки памяти (Сборщик мусора)

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

Именно это мы и видим при работе сервера - память растёт из-за скопления "огрызков", после чего сборщик собирает мусор и потребление падает.

Почему Xms и Xmx стоит выставлять одинаковыми?

За что ответственны эти аргументы?

• Xms - это начальный размер "стола".
• Xmx - это максимальный размер "стола".

Если Xms меньше Xmx, Java будет постоянно пытаться "раздвинуть" стол в зависимости от количества яблок. Каждое такое изменение размера требует определённых усилий, поэтому стол и нужно ставить сразу "раздвинутым".

Почему выделять много памяти - плохо?

Вы купили огромный стол, на который умещается много яблок. Вы едите их в своё удовольствие, до момента, пока стол не заполнится. И вот, вам нужно убирать огрызки, только их уже не кучка, а целая гора. В этот момент ваш сервер может зависнуть, а в некоторых случаях даже упасть.

Когда стоит поднимать тревогу?

Утечка памяти:
Вы сидите за столом вместе с другом, и он запрещает вам выкидывать свои огрызки. Если после каждой сборки мусора количество памяти растёт без весомых на то причин, стоит задуматься о возможном появлением утечки.