История изменений

Ну смотри. Я тебе как жава разработчик попробую обрисовать ситуацию. Может чего полезного извлечёшь.

Твой главный инструмент по ограничению жора жавы это ключ -Xmx. Это размер кучи, по сути там все жава объекты и лежат. Если ты его задашь слишком маленьким, жава начнёт падать с исключением OutOfMemoryException. Если ты его задашь впритык, падать она не будет, но будет очень много времени тратить на сбор мусора. Если у тебя программа всегда потребляет примерно одинаковый объём памяти, то надо ставить примерно полуторный объём этой памяти, можно уменьшить до 1.2, меньше уже не стоит. Если у тебя есть пиковое потребление памяти, то, понятное дело, надо ставить не меньше этого пика, иначе свалится. Сколько поставишь, столько сожрёт и назад не отдаст, даже если уже не надо, это минус JVM. Если ты его не задашь, он выставится автоматически, в зависимости от объёма памяти на твоём компьютере. Например в 1/4 от общего объёма. Поэтому задавать надо всегда, т.к. тебе видней, сколько надо выделить программе, JVM точно фигню выставит.

Кроме этого жрать память могут нативные библиотеки. Тут ты ничего не сделаешь. Ну только лезть в код, вкуривать, в общем вряд ли.

Кроме этого жрать память может так называемая offheap память. Это когда некоторые разработчики считают себя умней JVM и жрут память вне хипа, самостоятельно управляя ею. Тут тоже ты ничего не сделаешь, ну можно покурить исходники, возможно там разработчики предусмотрели какие-то свои лимиты. В целом это дурной тон и используется редко.

Понятно, что во всех случаях программа может течь. Это баг, который надо исправлять. Если есть желание - запусти с -Xmx поболььше, подожди, чтобы она хорошо так потекла, и сделай дамп. Потом этот дамп отправляй разработчику и проси пофиксить. Чтобы быть уверенным в утечке, лучше подцепиться JConsole к программе и помониторить график хипа, пожмякать кнопочку «GC». Используемая память это именно тот объём, который появляется после GC. Если видно, что с течением времени он ощутимо растёт, а причин этому не заметно, можно этим заняться. Имей в виду, что дамп содержит все данные программы, среди которых могут быть твои приватные данные, пароли, которые ты вводил в эту жава-программу и всё такое прочее.

Ну смотри. Я тебе как жава разработчик попробую обрисовать ситуацию. Может чего полезного извлечёшь.

Твой главный инструмент по ограничению жора жавы это ключ -Xmx. Это размер кучи, по сути там все жава объекты и лежат. Если ты его задашь слишком маленьким, жава начнёт падать с исключением OutOfMemoryException. Если ты его задашь впритык, падать она не будет, но будет очень много времени тратить на сбор мусора. Если у тебя программа всегда потребляет примерно одинаковый объём памяти, то надо ставить примерно полуторный объём этой памяти, можно уменьшить до 1.2, меньше уже не стоит. Если у тебя есть пиковое потребление памяти, то, понятное дело, надо ставить не меньше этого пика, иначе свалится. Сколько поставишь, столько сожрёт и назад не отдаст, даже если уже не надо, это минус JVM. Если ты его не задашь, он выставится автоматически, в зависимости от объёма памяти на твоём компьютере. Например в 1/4 от общего объёма.

Кроме этого жрать память могут нативные библиотеки. Тут ты ничего не сделаешь. Ну только лезть в код, вкуривать, в общем вряд ли.

Кроме этого жрать память может так называемая offheap память. Это когда некоторые разработчики считают себя умней JVM и жрут память вне хипа, самостоятельно управляя ею. Тут тоже ты ничего не сделаешь, ну можно покурить исходники, возможно там разработчики предусмотрели какие-то свои лимиты. В целом это дурной тон и используется редко.

Понятно, что во всех случаях программа может течь. Это баг, который надо исправлять. Если есть желание - запусти с -Xmx поболььше, подожди, чтобы она хорошо так потекла, и сделай дамп. Потом этот дамп отправляй разработчику и проси пофиксить. Чтобы быть уверенным в утечке, лучше подцепиться JConsole к программе и помониторить график хипа, пожмякать кнопочку «GC». Используемая память это именно тот объём, который появляется после GC. Если видно, что с течением времени он ощутимо растёт, а причин этому не заметно, можно этим заняться. Имей в виду, что дамп содержит все данные программы, среди которых могут быть твои приватные данные, пароли, которые ты вводил в эту жава-программу и всё такое прочее.

Ну смотри. Я тебе как жава разработчик попробую обрисовать ситуацию. Может чего полезного извлечёшь.

Твой главный инструмент по ограничению жора жавы это ключ -Xmx. Это размер кучи, по сути там все жава объекты и лежат. Если ты его задашь слишком маленьким, жава начнёт падать с исключением OutOfMemoryException. Если ты его задашь впритык, падать она не будет, но будет очень много времени тратить на сбор мусора. Если у тебя программа всегда потребляет примерно одинаковый объём памяти, то надо ставить примерно полуторный объём этой памяти, можно уменьшить до 1.2, меньше уже не стоит. Если у тебя есть пиковое потребление памяти, то, понятное дело, надо ставить не меньше этого пика, иначе свалится. Сколько поставишь, столько сожрёт и назад не отдаст, даже если уже не надо, это минус JVM.

Кроме этого жрать память могут нативные библиотеки. Тут ты ничего не сделаешь. Ну только лезть в код, вкуривать, в общем вряд ли.

Кроме этого жрать память может так называемая offheap память. Это когда некоторые разработчики считают себя умней JVM и жрут память вне хипа, самостоятельно управляя ею. Тут тоже ты ничего не сделаешь, ну можно покурить исходники, возможно там разработчики предусмотрели какие-то свои лимиты. В целом это дурной тон и используется редко.

Понятно, что во всех случаях программа может течь. Это баг, который надо исправлять. Если есть желание - запусти с -Xmx поболььше, подожди, чтобы она хорошо так потекла, и сделай дамп. Потом этот дамп отправляй разработчику и проси пофиксить. Чтобы быть уверенным в утечке, лучше подцепиться JConsole к программе и помониторить график хипа, пожмякать кнопочку «GC». Используемая память это именно тот объём, который появляется после GC. Если видно, что с течением времени он ощутимо растёт, а причин этому не заметно, можно этим заняться. Имей в виду, что дамп содержит все данные программы, среди которых могут быть твои приватные данные, пароли, которые ты вводил в эту жава-программу и всё такое прочее.