Как изменить размер кучи java

Это глубокое погружение в управление памятью Java позволит расширить ваши знания о том, как работает куча, ссылочные типы и сборка мусора.

Вероятно, вы могли подумать, что если вы программируете на Java, то вам незачем знать о том, как работает память. В Java есть автоматическое управление памятью, красивый и тихий сборщик мусора, который работает в фоновом режиме для очистки неиспользуемых объектов и освобождения некоторой памяти.

Поэтому вам, как программисту на Java, не нужно беспокоиться о таких проблемах, как уничтожение объектов, поскольку они больше не используются. Однако, даже если в Java этот процесс выполняется автоматически, он ничего не гарантирует. Не зная, как устроен сборщик мусора и память Java, вы можете создать объекты, которые не подходят для сбора мусора, даже если вы их больше не используете.

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

Для начала давайте посмотрим, как обычно организована память в Java:

Обычно память делится на две большие части: стек и куча. Имейте в виду, что размер типов памяти на этом рисунке не пропорционален реальному размеру памяти. Куча — это огромный объем памяти по сравнению со стеком.

Стек (Stack)

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

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

Возможно, вы заметили, что на картинке выше отображено несколько стеков памяти. Это связано с тем, что стековая память в Java выделяется для каждого потока. Следовательно, каждый раз, когда поток создается и запускается, он имеет свою собственную стековую память и не может получить доступ к стековой памяти другого потока.

Куча (Heap)

Эта часть памяти хранит в памяти фактические объекты, на которые ссылаются переменные из стека. Например, давайте проанализируем, что происходит в следующей строке кода:

StringBuilder builder = new StringBuilder();

Ключевое слово new несет ответственность за обеспечение того, достаточно ли свободного места на куче, создавая объект типа StringBuilder в памяти и обращаясь к нему через «Builder» ссылки, которая попадает в стек.

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

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

Типы ссылок

Если вы внимательно посмотрите на изображение структуры памяти, вы, вероятно, заметите, что стрелки, представляющие ссылки на объекты из кучи, на самом деле относятся к разным типам. Это потому, что в языке программирования Java используются разные типы ссылок: сильные, слабые, мягкие и фантомные ссылки. Разница между типами ссылок заключается в том, что объекты в куче, на которые они ссылаются, имеют право на сборку мусора по различным критериям. Рассмотрим подробнее каждую из них.

1. Сильная ссылка

Это самые популярные ссылочные типы, к которым мы все привыкли. В приведенном выше примере со StringBuilder мы фактически храним сильную ссылку на объект из кучи. Объект в куче не удаляется сборщиком мусора, пока на него указывает сильная ссылка или если он явно доступен через цепочку сильных ссылок.

2. Слабая ссылка

Попросту говоря, слабая ссылка на объект из кучи, скорее всего, не сохранится после следующего процесса сборки мусора. Слабая ссылка создается следующим образом:

WeakReference<StringBuilder> reference = new WeakReference<>(new StringBuilder());

Хорошим вариантом использования слабых ссылок являются сценарии кеширования. Представьте, что вы извлекаете некоторые данные и хотите, чтобы они также были сохранены в памяти — те же данные могут быть запрошены снова. С другой стороны, вы не уверены, когда и будут ли эти данные запрашиваться снова. Таким образом, вы можете сохранить слабую ссылку на него, и в случае запуска сборщика мусора, возможно, он уничтожит ваш объект в куче. Следовательно, через некоторое время, если вы захотите получить объект, на который вы ссылаетесь, вы можете внезапно получить null значение. Хорошей реализацией сценариев кеширования является коллекция WeakHashMap <K, V>. Если мы откроем WeakHashMap класс в Java API, мы увидим, что его записи фактически расширяют WeakReferenceкласс и используют его поле ref в качестве ключа отображения (Map):

/**
    * The entries in this hash table extend WeakReference, using its main ref
    * field as the key.
*/

private static class Entry<K,V> extends WeakReference<Object> implements Map.Entry<K,V> {

    V value;

После сбора мусора ключа из WeakHashMap вся запись удаляется из карты.

3. Мягкая ссылка

Эти типы ссылок используются для более чувствительных к памяти сценариев, поскольку они будут собираться сборщиком мусора только тогда, когда вашему приложению не хватает памяти. Следовательно, пока нет критической необходимости в освобождении некоторого места, сборщик мусора не будет касаться легко доступных объектов. Java гарантирует, что все объекты, на которые имеются мягкие ссылки, будут очищены до того, как будет выдано исключение OutOfMemoryError. В документации Javadocs говорится, что «все мягкие ссылки на мягко достижимые объекты гарантированно очищены до того, как виртуальная машина выдаст OutOfMemoryError».

Подобно слабым ссылкам, мягкая ссылка создается следующим образом:

SoftReference<StringBuilder> reference = new SoftReference<>(new StringBuilder());

4. Фантомная ссылка

Используется для планирования посмертных действий по очистке, поскольку мы точно знаем, что объекты больше не живы. Используется только с очередью ссылок, поскольку .get()метод таких ссылок всегда будет возвращаться null. Эти типы ссылок считаются предпочтительными для финализаторов.

Ссылки на String

Ссылки на тип String в Java обрабатываются немного по- другому. Строки неизменяемы, что означает, что каждый раз, когда вы делаете что-то со строкой, в куче фактически создается другой объект. Для строк Java управляет пулом строк в памяти. Это означает, что Java сохраняет и повторно использует строки, когда это возможно. В основном это верно для строковых литералов. Например: 

String localPrefix = "297"; //1
String prefix = "297";      //2

if (prefix == localPrefix)
{
    System.out.println("Strings are equal" );
}
else
{
    System.out.println("Strings are different");
}Строка  localPrefix  =  «297» ; // 1

При запуске этот код распечатывает следующее:

 Strings are equal

Следовательно, оказывается, что две ссылки типа String на одинаковые строковые литералы фактически указывают на одни и те же объекты в куче. Однако это не действует для вычисляемых строк. Предположим, что у нас есть следующее изменение в строке // 1 приведенного выше кода.

String localPrefix = new Integer(297).toString(); //1

Вывод:

 Strings are different

В этом случае мы фактически видим, что у нас есть два разных объекта в куче. Если учесть, что вычисляемая строка будет использоваться довольно часто, мы можем заставить JVM добавить ее в пул строк, добавив .intern()метод в конец вычисляемой строки:

String localPrefix = new Integer(297).toString().intern(); //1

При добавлении вышеуказанного изменения создается следующий результат:

 Строки равны

Процесс сборки мусора

Как обсуждалось ранее, в зависимости от типа ссылки, которую переменная из стека содержит на объект из кучи, в определенный момент времени этот объект становится подходящим для сборщика мусора.

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

Чтобы углубиться в детали, давайте сначала упомянем несколько вещей:

• Этот процесс запускается автоматически Java, и Java решает, запускать или нет этот процесс.

• На самом деле это дорогостоящий процесс. При запуске сборщика мусора все потоки в вашем приложении приостанавливаются (в зависимости от типа GC, который будет обсуждаться позже).

• На самом деле это более сложный процесс, чем просто сбор мусора и освобождение памяти.

Несмотря на то, что Java решает, когда запускать сборщик мусора, вы можете явно вызвать System.gc()и ожидать, что сборщик мусора будет запускаться при выполнении этой строки кода, верно?

Это ошибочное предположение.

Вы только как бы просите Java запустить сборщик мусора, но, опять же, Java решать, делать это или нет. В любом случае явно вызывать System.gc()не рекомендуется.

Поскольку это довольно сложный процесс и может повлиять на вашу производительность, он реализован разумно. Для этого используется так называемый процесс «Mark and Sweep». Java анализирует переменные из стека и «отмечает» все объекты, которые необходимо поддерживать в рабочем состоянии. Затем все неиспользуемые объекты очищаются.

Так что на самом деле Java не собирает мусор. Фактически, чем больше мусора и чем меньше объектов помечены как живые, тем быстрее идет процесс. Чтобы сделать это еще более оптимизированным, память кучи на самом деле состоит из нескольких частей. Мы можем визуализировать использование памяти и другие полезные вещи с помощью JVisualVM, инструмента, поставляемого с Java JDK. Единственное, что вам нужно сделать, это установить плагин с именем Visual GC, который позволяет увидеть, как на самом деле структурирована память. Давайте немного увеличим масштаб и разберем общую картину:

Когда объект создается, он размещается в пространстве Eden (1). Поскольку пространство Eden не такое уж большое, оно заполняется довольно быстро. Сборщик мусора работает в пространстве Eden и помечает объекты как живые.

Если объект выживает в процессе сборки мусора, он перемещается в так называемое пространство выжившего S0(2). Во второй раз, когда сборщик мусора запускается в пространстве Eden, он перемещает все уцелевшие объекты в пространство S1(3). Кроме того, все, что в настоящее время находится на S0(2), перемещается в пространство S1(3).

Если объект выживает в течение X раундов сборки мусора (X зависит от реализации JVM, в моем случае это 8), скорее всего, он выживет вечно и перемещается в пространство Old(4).

Принимая все сказанное выше, если вы посмотрите на график сборщика мусора (6), каждый раз, когда он запускается, вы можете увидеть, что объекты переключаются на пространство выживших и что пространство Эдема увеличивалось. И так далее. Старое поколение также может быть обработано сборщиком мусора, но, поскольку это большая часть памяти по сравнению с пространством Eden, это происходит не так часто. Метапространство (5) используется для хранения метаданных о ваших загруженных классах в JVM.

Представленное изображение на самом деле является приложением Java 8. До Java 8 структура памяти была немного другой. Метапространство на самом деле называется PermGen область. Например, в Java 6 это пространство также хранит память для пула строк. Поэтому, если в вашем приложении Java 6 слишком много строк, оно может аварийно завершить работу.

Типы сборщиков мусора

Фактически, JVM имеет три типа сборщиков мусора, и программист может выбрать, какой из них следует использовать. По умолчанию Java выбирает используемый тип сборщика мусора в зависимости от базового оборудования.

 1. Serial GC (Последовательный сборщик мусора) — однониточный коллектор. В основном относится к небольшим приложениям с небольшим использованием данных. Можно включить, указав параметр командной строки: -XX:+UseSerialGC.

 2. Parallel GC (Параллельный сборщик мусора) — даже по названию, разница между последовательным и параллельным будет заключаться в том, что параллельный сборщик мусора использует несколько потоков для выполнения процесса сбора мусора. Этот тип GC также известен как сборщик производительности. Его можно включить, явно указав параметр: -XX:+UseParallelGC.

 3. Mostly concurrent GC (В основном параллельный сборщик мусора). Если вы помните, ранее в этой статье упоминалось, что процесс сбора мусора на самом деле довольно дорогостоящий, и когда он выполняется, все потоки приостанавливаются. Однако у нас есть в основном параллельный тип GC, который утверждает, что он работает одновременно с приложением. Однако есть причина, по которой он «в основном» параллелен. Он не работает на 100% одновременно с приложением. Есть период времени, на который цепочки приостанавливаются. Тем не менее, пауза делается как можно короче для достижения наилучшей производительности сборщика мусора. На самом деле существует 2 типа в основном параллельных сборщиков мусора:

 3.1 Garbage First — высокая производительность с разумным временем паузы приложения. Включено с опцией: -XX:+UseG1GC.

 3.2 Concurrent Mark Sweep (Параллельное сканирование отметок) — время паузы приложения сведено к минимуму. Он может быть использован с помощью опции: -XX:+UseConcMarkSweepGC. Начиная с JDK 9, этот тип GC объявлен устаревшим.

Примечание переводчика. Информация про сборщики мусора для различных версий Java приведена в переводе:

Систематизированный список всех функций Java и JVM в Java 8-15

Советы и приемы

• Чтобы минимизировать объем памяти, максимально ограничьте область видимости переменных. Помните, что каждый раз, когда выскакивает верхняя область видимости из стека, ссылки из этой области теряются, и это может сделать объекты пригодными для сбора мусора.

• Явно устанавливайте в null устаревшие ссылки. Это сделает объекты, на которые ссылаются, подходящими для сбора мусора.

• Избегайте финализаторов (finalizer). Они замедляют процесс и ничего не гарантируют. Фантомные ссылки предпочтительны для работы по очистке памяти.

• Не используйте сильные ссылки там, где можно применить слабые или мягкие ссылки. Наиболее распространенные ошибки памяти — это сценарии кэширования, когда данные хранятся в памяти, даже если они могут не понадобиться.

• JVisualVM также имеет функцию создания дампа кучи в определенный момент, чтобы вы могли анализировать для каждого класса, сколько памяти он занимает.

• Настройте JVM в соответствии с требованиями вашего приложения. Явно укажите размер кучи для JVM при запуске приложения. Процесс выделения памяти также является дорогостоящим, поэтому выделите разумный начальный и максимальный объем памяти для кучи. Если вы знаете его, то не имеет смысла начинать с небольшого начального размера кучи с самого начала, JVM расширит это пространство памяти. Указание параметров памяти выполняется с помощью следующих параметров:

  • Начальный размер кучи -Xms512m— установите начальный размер кучи на 512 мегабайт.

  • Максимальный размер кучи -Xmx1024m— установите максимальный размер кучи 1024 мегабайта.

  • Размер стека потоков -Xss1m— установите размер стека потоков равным 1 мегабайту.

  • Размер поколения -Xmn256m— установите размер поколения 256 мегабайт.

• Если приложение Java выдает ошибку OutOfMemoryErrorи вам нужна дополнительная информация для обнаружения утечки, запустите процесс с –XX:HeapDumpOnOutOfMemoryпараметром, который создаст файл дампа кучи, когда эта ошибка произойдет в следующий раз.

• Используйте опцию -verbose:gc, чтобы получить вывод процесса сборки мусора. Каждый раз, когда происходит сборка мусора, будет генерироваться вывод.

Заключение

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

Если вы являетесь Java-разработчиком или администратором Java приложения, вам поможет в работе знание того, что означают опции JVM, а также их важность и как они влияют на ваше приложение.

Обзор параметров JVM

Если говорить о параметрах JVM, то есть три типа параметров, которые вы можете включить в JVM: стандартные, нестандартные и расширенные параметры. Если вы используете расширенную опцию, вы всегда используете опцию с -XX. Точно так же, если вы применяете нестандартную опцию, вы используете -X. Стандартные опции ничего не добавляют к опции.

Какие параметры JVM используются вашим приложением?

Если приложение работает в Linux, вы можете использовать

ps -ef | grep java

для идентификации процесса Java и просмотра параметров JVM, напечатанных как аргументы процесса. Если в системе выполняется более одного Java-процесса, вам может потребоваться использовать ключевое слово, уникальное для вашего Java-приложения.

Если ваш аргумент слишком длинный, попробуйте использовать

ps -auxww | grep java

так как эта команда также покажет длинный список аргументов.

Имея список флагов JVM, вы можете получить представление о поведении любого Java-приложения, например Tomcat.

1. Размер кучи (heap) Java

-Xms - установить начальный размер кучи Java
-Xmx - установить максимальный размер кучи Java
-Xss - установить размер стека Java-потока (java thread stack)

-Xms — эта опция определяет начальный размер кучи для JVM, например, Xms2048m, что означает, что начальный размер кучи JVM составляет около 2 ГБ. Итак, когда JVM запускается, куча памяти будет очень большой. Это делается для предотвращения изменения размера во время запуска и увеличения времени запуска JVM.

-Xmx — этот параметр определяет максимальный размер кучи JVM, например, Xmx2048m, что означает, что максимальный размер кучи JVM будет составлять только 2 ГБ.

По сути, вы всегда будете иметь -Xms и -Xmx вместе.

2. Задание процента кучи

-XX:MaxHeapFreeRatio — устанавливает максимальный процент свободного пространства кучи после GC (Garbage Collecting, сборки мусора), чтобы избежать сжатия.

-XX:MinHeapFreeRatio — устанавливает минимальный процент свободного пространства кучи после GC, чтобы избежать расширения; для мониторинга использования кучи вы можете использовать JConsole.

3. Включить обмен данными класса

Укажите опцию Xshareclasses, чтобы включить общий доступ к данным класса в общем кэше классов. JVM подключается к существующему кэшу или создает кэш, если он не существует. У вас может быть несколько кэшей, и вы можете указать правильный кэш, добавив подопцию в опцию -Xshareclasses.

4. PermGen размер

Ранее параметры JVM определяли размер кучи памяти, но -XX:PermSize — для определения размера пространства PermGen, в котором сохраняются пул строк и метаданные класса. Этот параметр особенно эффективен для веб-сервера, такого как Tomcat, который часто загружает классы веб-приложения во время развертывания.

Кстати, стоит понимать, что пространство PermGen занято Metaspace в Java 8, и этот параметр неприменим, если вы работаете с JRE 8 JVM.

5. Распечатать GC (Garbage Collector)

-verbose:gc - регистрирует, запуски сборщика мусора и сколько времени они занимают.
-XX:+PrintGCDetails - включает в себя данные из -verbose:gc, но также добавляет информацию о размере нового поколения и более точных временных параметрах.
-XX:-PrintGCTimeStamps - печатать метки времени при сборке мусора.

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

Эта удобная опция подскажет вам важную статистику GC. Станет известно, будет ли это большая или небольшая сборка мусора, какой тип сборщика мусора применяется, как часто восстанавливается память, сколько времени он занимал и т.д.

6. Обработка ошибки «OutOfMemory»

Чтобы вызвать дамп кучи при нехватке памяти, вы можете использовать -XX:+HeapDumpOnOutOfMemoryError

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

Дамп кучи будет установлен в «текущем каталоге» JVM по умолчанию. Если вы хотите создать дамп кучи в определенном каталоге, запустите

-XX:HeapDumpPath=[путь к каталогу дампа кучи]
-XX:+UseGCOverheadLimit
-XX:OnOutOfMemoryError="<cmd args>; <cmd args>"

Файл дампа кучи может быть огромного размера, вплоть до гигабайт, поэтому убедитесь, что целевая файловая система обеспечивает достаточную емкость.

Если мы хотим перезапустить сервер сразу после возникновения нехватки памяти, мы можем установить этот параметр с той же целью:

XX:OnOutOfMemoryError="shutdown -r"

7. Trace загрузки классов и выгрузки

-XX:+TraceClassLoading и -XX:+TraceClassUnloading — это две опции JVM, которые мы используем для печати информации журналов всякий раз, когда классы загружаются в JVM или выгружаются из JVM. Эти флаги JVM полезны, если у вас есть какой-либо тип утечки памяти, связанный с загрузчиком классов и есть подозрение, что классы не выгружаются или не собирается мусор.

8. Java classpath (путь к классу)

Говоря о Java Classpath а затем -Xbootclasspath определяет записи classpath, которые мы хотим загрузить без проверки. JVM проверяет все классы, которые она загружает, чтобы убедиться, что она не пытается разыменовать объект с помощью int, выталкивает дополнительные записи из стека или выталкивает слишком много, и так далее.

Помещение class в bootclasspath также снижает стоимость, но его следует использовать только тогда, когда вы знаете, что классы проверялись много раз раньше. В JRuby это сократило время запуска вдвое и более для простого скрипта.

9. Профилирование

Java профилирование — это процесс мониторинга различных параметров уровней JVM, таких как выполнение методов, выполнение потоков, сборка мусора и создание объектов. Java профилирование обеспечивает более точное представление о выполнении целевого приложения и использовании его ресурсов.

-Xprof
-Xrunhprof

10. 64-битная среда

В среде ОС, в которой установлены 32- и 64-разрядные пакеты, JVM автоматически выбирает 32-разрядные пакеты среды по умолчанию.

Если мы хотим установить 64-битную среду вручную, мы можем сделать это с помощью параметра -d . OS bit может быть 32 или 64.

Канал в Телеграм

Новый день, новая версия Java … приятно 🙂

Мы использовали для обновления второстепенных версий Java в основном из-за проблем безопасности. Но иногда эти незначительные обновления приносят нам совершенно новые, потрясающие функции. Так было, например, с 7u40, который принес нам потрясающий контроль полетов, известный из JRockit. (Если вы заинтересованы в отслеживании изменений в обновлениях Java, ознакомьтесь с

http://www.oracle.com/technetwork/java/javase/8all-relnotes-2226344.html  для Java 8 или
http://www.java. com / en / download / faq / release_changes.xml  для Java 7) 

Та же ситуация сейчас с версиями 
7u60  и 
8u20 . Теперь флаги 
MinHeapFreeRatio  и
MaxHeapFreeRatio стало управляемым, что означает, что мы можем изменить его значения … во время выполнения 🙂 

Вы всегда можете проверить, какими флагами в JVM можно управлять, вызвав

java -XX:+PrintFlagsFinal -XX:+UseG1GC -version |grep manageable
intx CMSAbortablePrecleanWaitMillis  = 100  {manageable}
intx CMSWaitDuration  = 2000  {manageable}
bool HeapDumpAfterFullGC  = false  {manageable}
bool HeapDumpBeforeFullGC  = false  {manageable}
bool HeapDumpOnOutOfMemoryError  = false  {manageable}
ccstr HeapDumpPath  =  {manageable}
uintx MaxHeapFreeRatio  = 70  {manageable}
uintx MinHeapFreeRatio  = 40  {manageable}
bool PrintClassHistogram  = false  {manageable}
bool PrintClassHistogramAfterFullGC  = false  {manageable}
bool PrintClassHistogramBeforeFullGC  = false  {manageable}
bool PrintConcurrentLocks  = false  {manageable}
bool PrintGC  = false  {manageable}
bool PrintGCDateStamps  = false  {manageable}
bool PrintGCDetails  = false  {manageable}
bool PrintGCTimeStamps  = false  {manageable}
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)

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

Теперь посмотрим, как работает изменение размера кучи. Сначала нам нужно найти Java-процесс для тестирования. Я собираюсь использовать запуск 
IntelliJ IDEA .

Как вы знаете, java pids можно найти, вызвав 
 команду jps :

jps -l
17136 com.intellij.idea.Main

Мы уже знаем наш pid для тестирования, поэтому самое время узнать статистику кучи. Мы будем использовать 
команду jmap для этого:

jmap -heap 17136
Attaching to process ID 17136, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.20-b23
using thread-local object allocation.
Garbage-First (G1) GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio  = 40
MaxHeapFreeRatio  = 70
MaxHeapSize  = 2147483648 (2048.0MB)
NewSize  = 1363144 (1.2999954223632812MB)
MaxNewSize  = 1287651328 (1228.0MB)
OldSize  = 5452592 (5.1999969482421875MB)
NewRatio  = 2
SurvivorRatio  = 8
MetaspaceSize  = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize  = 17592186044415 MB
G1HeapRegionSize  = 1048576 (1.0MB)
Heap Usage:
G1 Heap:
regions  = 2048
capacity = 702545920 (670.0MB)
used  = 284513824 (271.3335266113281MB)
free  = 418032096 (398.6664733886719MB)
40.49754128527285% used

Как видите, я использую 
G1 GC  с максимальным размером кучи 2 ГБ (-Xmx2g). Использование кучи составляет около 40%. Теперь мы должны запустить full gc, чтобы немного очиститься перед игрой.

jcmd 17136 GC.run

Тогда jmap еще раз, и мы можем увидеть 

Heap Configuration:
MinHeapFreeRatio  = 40
MaxHeapFreeRatio  = 70
Heap Usage:
G1 Heap:
regions  = 2048
capacity = 439353344 (419.0MB)
used  = 135954032 (129.65586853027344MB)
free  = 303399312 (289.34413146972656MB)
30.944121367607025% used

Наконец-то мы готовы начать сбор. Я изменю значение 
 флага MaxHeapFreeRatio с помощью 
инструмента jinfo :

jinfo -flag MaxHeapFreeRatio=50 17136

После этого мы должны снова запустить full gc для принудительного изменения размера. И теперь наша куча выглядит так: 

Heap Configuration:
MinHeapFreeRatio  = 40
MaxHeapFreeRatio  = 50
Heap Usage:
G1 Heap:
regions  = 2048
capacity = 166723584 (159.0MB)
used  = 82849400 (79.01134490966797MB)
free  = 83874184 (79.98865509033203MB)
49.69266975450816% used

Как видите, куча сократилась с 419 до 159 МБ.

Теперь мы можем попробовать пойти другим путем: 

jinfo -flag MaxHeapFreeRatio=90 17136
jinfo -flag MinHeapFreeRatio=85 17136

дает 
 вывод 
Jmap

Heap Configuration:
MinHeapFreeRatio  = 85
MaxHeapFreeRatio  = 90
Heap Usage:
G1 Heap:
regions  = 2048
capacity = 465567744 (444.0MB)
used  = 69816504 (66.58220672607422MB)
free  = 395751240 (377.4177932739258MB)
14.995992505872572% used

Изменение размера сработало еще раз, а объем кучи увеличился с 159 МБ до 444 МБ. Мы описали, что минимум 85% нашей емкости кучи должны быть свободными, и это указало JVM изменить размер кучи, чтобы получить максимально 15% использования. Теперь мы ждем смены среды выполнения XMX;)