Blazkowiczwnoiseхмм. действительно под 1.5 не отдается память в win7. Четко помню, что был такой тест, но правда не помню когда это было:)

Не важно. Вы могли, например, обратить внимание только на RAM, без учета виртуальной памятию

wnoiseС другой стороны виртуальная память для процесса может уменьшаться - я так понимаю это когда jvm стартует выполнение gc сама?

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

wnoiseЕще спрашивал: можно ли программно получить heapdump?
Гугл говорит, что можно. Вопрос - зачем?
http://code.google.com/p/perfbench/source/browse/trunk/perfbench/jmeter-utils/src/main/java/jmeterutils/JmxHeapDumper.java
http://blogs.oracle.com/sundararajan/entry/programmatically_dumping_heap_from_java
http://www.java-community.de/archives/85-Java-heap-dumps.html

я про столбец "объем виртуальной памяти" в диспетчере задач в винде (xp,2003)

а еще где хранятся int, long и прочие простые типы?

Зачем - чтобы у клиентов не тусить постоянно и их не просить делать какие то действия.

BlazkowiczwnoiseЗачем - чтобы у клиентов не тусить постоянно и их не просить делать какие то действия.
Ну, существуют внятные средства мониторинга. Зачем обязательно хип дампить?

раз уж поставили знак вопроса в конце :) - а что имеется в виду под внятными средствами мониторинга?

Blazkowiczwnoiseрасскажете вкратце?

Там разные варианты есть.
Во-первых исключение кидается, когда после полной сборки мусора свободного места в хипе осталось меньше определенного порога. Порог можно настроить.
Во-вторых исключение кидается, когда уборка занимает радикально много времени ( то ли по сравнению с остальной работой JVM, то ли в абсолютной величине, не помню точно.) Тоже настраивается.
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

ну если java.lang.OutOfMemoryError: Java heap space - это ведь собственно оно - нехватка места в куче? Другими словами приближение (или попытка превышения) к параметру Xmx.

Blazkowicz,

Спасибо большое. Приятно поговорить с умным человеком :)

Если бы еще вот про внятные средства мониторинга просветили ;)

Blazkowicz,

сеть клиента с приложением под страхом смерти недоступна снаружи.

Я конечно извиняюсь за глупый вопрос :). А если я задал например параметр Xmx=1300, то какие параметры по памяти в диспетчере задач нужно мониторить, чтобы сделать вывод о приближении к опасной черте :)

svenomwnoiseЯ конечно извиняюсь за глупый вопрос :). А если я задал например параметр Xmx=1300, то какие параметры по памяти в диспетчере задач нужно мониторить, чтобы сделать вывод о приближении к опасной черте :)Никак, для этого надо профайлерами пользоваться, а не диспетчером.

Это провал :). Система у заказчика и его It хочет мониторить самостоятельно память, чтобы принимать определенные меры. Профайлером он пользоваться не будет :(

Спасибо.

Blazkowiczwnoise Это провал :). Система у заказчика и его It хочет мониторить самостоятельно память, чтобы принимать определенные меры. Профайлером он пользоваться не будет :(
Что именно он хочет мониторить? Куча может бы заполнена и приложение при этом будет нормально работать. Напишите ему простейший монитор на базе GarbageCollectorMXBean и MemoryMXBean. И пусть мониторит, хоть до посинения.

а поясните плиз:

выше шла речь о том, что jvm очень неохотно освобождает память. Соответственно если взять




, то он тоже неохотно освобождается пока не попросишь под другие задачи или явно не вызовешь:




Соответственно вопрос - так и должно быть? или надо дольше ждать пока не почистится? (смотрел на jvm 1.5)

Blazkowicz http://habrahabr.ru/blogs/java/137641/

Спасибо. Вопрос все таки немного в другом. Приложение не тормозит, потому что GC. Есть задача - в рамках приложения реализовать минимальный мониторинг - приближение/удаление от опасной черты, заданной параметром xmx.

Использую

ManagementFactory.getMemoryMXBean().getUsed();

С точки зрения приближения - работает - первая часть задачи решена. Беремся за вторую - удаление от этой опасной черты. Соответственно данные уже не нужны и память никто не требует. В этом случае строчки вроде(при включенном -verbose:gc):

[Full GC 16231K->16197K(33408K), 0.0399266 secs]

не появляются (что логично). А полная сборка мусора происходит только при вызове

ManagementFactory.getMemoryMXBean().gc();

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

ManagementFactory.getMemoryMXBean().getUsed();

будет всегда возвращать пиковое значение и скинуть его можно только вызовом:

ManagementFactory.getMemoryMXBean().gc();

так?