В настоящее время я тестирую свое доказательство концептуального прототипа, имеющего дело со схемой XML, и построена на очень ресурсоемкой внешней библиотеке для древовидных автоматов (для которой яу меня есть источники), яхотел бы сюжетнастоящий пик " (куча) потребление памяти различными прогонами с увеличением размеров схемы (используемая метрика подходит моему балансу и не влияет на вопрос), или, по крайней мере, разумное приближение к нему.

Чтобы получить порядок величины для прогона с реальным пиком в 100 МБ (я тестировал несколько раз точно такую же конфигурацию ввода / параметров, заставляя память jvm с -Xmx и -Xms уменьшать значение, я получаюИсключение в теме "главный" java.lang.OutOfMemoryError: Превышен лимит накладных расходов GC < 100 МБ, со стабильными и воспроизводимыми результатами), он занимает около 1,1 ГБ, чтоВот почему для меня крайне важно получить реальные цифры, потому что они сильно отличаются!

я провел последние 10 дней, читая вопросы в Интернете и в stackoverflow, что я на самом деле знаю:

System.gc () "предложить" GC запускается, не вынуждает его каким-либо образом, поэтому на него нельзя положиться для обнаружения пиков использования памяти

Обычно предлагается подсчитать занятость объекта (я виделРазмер проект для этого, я попробовал и работает отлично, даже если он не соответствует моим потребностям), это не представляется возможным для меня, потому что интенсивное распределение памяти происходит из-за создания большого количества итераторов коллекции (набор, список и карта) в разных методы, вызываемые очень большое количество раз (скажем, по миллионам каждый за 10 минут, что я помню), поэтому было бы крайне сложно обнаружить все вовлеченные объекты и выполнить суммы (я отлаживал много раз за несколько дней с графики потребления памяти без возможности идентифицировать только одну бутылочную горловину)

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

Дело в том, что я сам испытал, что вызовы System.gc () ненадежны (например, разные прогоны одной и той же конфигурации, разное чтение памяти после System.gc () из-за того, что GC действительно вызывается или нет), но когда Я нажимаюКнопка GC " в JVisualVM или Jconsole этоникогда не запускает GC или отказывается это делать.

Итак, мой вопрос: вызывая их реализацию этой кнопки (я непока не попробую, но для чего яВы читали до сих пор, кажется возможным с помощью jconsole.jar сприложить API) будет отличаться от вызова System.gc () непосредственно из моего кода, что решит мою проблему? Если нет, то как вы объяснитедетерминированное поведение " этой кнопки?

До сих пор я проводил ручное тестирование реального пика памяти при 10 увеличивающихся размерах схем (для этого вида измерений схемы генерируются автоматически из одного "параметр сложности ") и я построил ожидаемую кривую, если я не смогу найти лучшего решения, я хочу запустить свой код в качестве внешнего jar с -Xmx / -Xms, равным немного меньшему, чем мой прогноз ожидаемого пика памяти, ловя OutMemoryException во внешнем процессе ErrorStream и перезапуск с увеличенным объемом памяти до полного выполнения. (Если наивный прогноз памяти не будет достаточно надежным, я буду применять соответствующие методы машинного обучения). Я знаю, что это не элегантное решение, но в моем сценарии (академическом) я могу позволить себе потратить дополнительное время на эти измерения. Если у вас есть другие предложения или улучшения к этому методу грубой силы, вы (крайне) можете поделиться ими.

Информация о системе (машина Fedora 17, 64 бит):

Java-версия "1.7.0_04" Java (TM) SE Runtime Environment (сборка 1.7.0_04-b20) Java HotSpot (TM) 64-битная виртуальная машина сервера (сборка 23.0-b21, смешанный режим)

Заранее спасибо, Алессандро