Ръководство за най-важните параметри на JVM

Програмиране

1. Общ преглед

В този бърз урок ще разгледаме най-известните опции, които могат да се използват за конфигуриране на виртуалната машина Java.

2. Изрична купчина памет - Xms и Xmx Опции

Една от най-често срещаните практики, свързани с производителността, е да се инициализира купчината памет според изискванията на приложението.

Ето защо трябва да посочим минимален и максимален размер на купчината. За постигането му могат да се използват следните параметри:

-Xms[unit] -Xmx[unit]

Тук единица означава единицата, в която паметта (посочена от размера на купчината ) трябва да бъде инициализирана. Единиците могат да бъдат маркирани като „g“ за GB, „m“ за MB и „k“ за KB.

Например, ако искаме да присвоим минимум 2 GB и максимум 5 GB на JVM, трябва да напишем:

-Xms2G -Xmx5G

Започвайки с Java 8, размерът на Metaspace не е определен. След като достигне глобалната граница, JVM автоматично я увеличава. Въпреки това, за да преодолеем всяка ненужна нестабилност, можем да зададем размера на Metaspace с:

-XX:MaxMetaspaceSize=[unit]

Тук размерът на метапространството означава количеството памет, което искаме да присвоим на Metaspace .

Съгласно насоките на Oracle, след общата налична памет, вторият най-влиятелен фактор е делът на купчината, запазен за Младото поколение. По подразбиране минималният размер на YG е 1310 MB , а максималният размер е неограничен .

Можем да ги възложим изрично:

-XX:NewSize=[unit] -XX:MaxNewSize=[unit]

3. Събиране на боклук

За по-добра стабилност на приложението, изборът на правилния алгоритъм за събиране на боклук е от решаващо значение.

JVM има четири вида внедрения на GC :

  • Сериен колектор за боклук
  • Паралелен събирач на боклук
  • CMS Колектор за боклук
  • G1 Колектор за боклук

Тези изпълнения могат да бъдат декларирани със следните параметри:

-XX:+UseSerialGC -XX:+UseParallelGC -XX:+USeParNewGC -XX:+UseG1GC

Повече подробности за внедряването на Garbage Collection можете да намерите тук.

4. Регистрация на GC

За да наблюдаваме стриктно състоянието на приложението, винаги трябва да проверяваме производителността на JVM Garbage Collection . Най-лесният начин да направите това е да регистрирате GC активността в четлив за човека формат.

Използвайки следните параметри, можем да регистрираме GC активността:

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles= -XX:GCLogFileSize=[ unit ] -Xloggc:/path/to/gc.log

UseGCLogFileRotation указва политиката за търкаляне на регистрационния файл, подобно на log4j, s4lj и др. NumberOfGCLogFiles обозначава максималния брой регистрационни файлове, които могат да бъдат записани за един жизнен цикъл на приложението. GCLogFileSize указва максималния размер на файла. И накрая, loggc обозначава своето местоположение.

Тук трябва да се отбележи, че има още два JVM параметъра ( -XX: + PrintGCTimeStamps и -XX: + PrintGCDateStamps ), които могат да бъдат използвани за отпечатване на времеви клей в дневника на GC .

Например, ако искаме да присвоим максимум 100 GC регистрационни файла, всеки с максимален размер от 50 MB и искаме да ги съхраним в местоположението „ / home / user / log /“ , можем да използваме синтаксиса по-долу:

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M -Xloggc:/home/user/log/gc.log

Проблемът обаче е, че една допълнителна демонова нишка винаги се използва за наблюдение на системното време във фонов режим. Това поведение може да създаде известна пречка за изпълнението; затова винаги е по-добре да не играете с този параметър в производството.

5. Работа с памет

Много често срещано е голямо приложение да се сблъска с грешка в паметта, което от своя страна води до срив на приложението. Това е много критичен сценарий и е много трудно да се възпроизведе за отстраняване на проблема.

Ето защо JVM идва с някои параметри, които изхвърлят куп памет във физически файл, който може да се използва по-късно за откриване на течове:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./java_pid.hprof -XX:OnOutOfMemoryError=";" -XX:+UseGCOverheadLimit

Тук трябва да се отбележат няколко точки:

  • HeapDumpOnOutOfMemoryError инструктира JVM да зарежда купчина във физически файл в случай на OutOfMemoryError
  • HeapDumpPath обозначава пътя, където файлът трябва да бъде записан; може да се даде всяко име на файл; ако обаче JVM намери aв името, идентификаторът на процеса на текущия процес, причиняващ грешка при липса на памет, ще бъде добавен към името на файла с .hprof формат
  • OnOutOfMemoryError се използва за издаване на аварийни команди, които трябва да бъдат изпълнени в случай на грешка без памет; правилната команда трябва да се използва в пространството на cmd args. Например, ако искаме да рестартираме сървъра веднага щом настъпи липсата на памет, можем да зададем параметъра:
-XX:OnOutOfMemoryError="shutdown -r"
  • UseGCOverheadLimit е политика, която ограничава дела на времето на виртуалната машина, прекарано в GC, преди да се изведе грешка OutOfMemory

6. 32/64 бита

В средата на операционната система, където са инсталирани 32-битови и 64-битови пакети, JVM автоматично избира 32-битови екологични пакети.

Ако искаме да зададем средата на 64 бита ръчно, можем да го направим, като използваме параметъра по-долу:

-d

Битът за ОС може да бъде 32 или 64 . Повече информация за това можете да намерите тук.

7. Разни

  • -сървър : активира “Server Hotspot VM”; този параметър се използва по подразбиране в 64 битов JVM
  • -XX: + UseStringDeduplication : Java 8u20 представи този JVM параметър за намаляване на ненужното използване на памет чрез създаване на твърде много екземпляри на един и същ низ; това оптимизира паметта на купчината чрез намаляване на дублиращи се низови стойности до един глобален масив char []
  • -XX: + UseLWPS Synchronization : задава LWP ( Light Weight Process ) - базирана политика на синхронизация вместо синхронизация, базирана на нишки
  • -XX: LargePageSizeInBytes : задава големия размер на страницата, използван за Java купчината; взема аргумента в GB / MB / KB; с по-големи размери на страниците можем да използваме по-добре хардуерните ресурси на виртуалната памет; това обаче може да доведе до по-големи размери на пространството за PermGen , което от своя страна може да принуди да намали размера на Java Java Heap пространство
  • -XX: MaxHeapFreeRatio : задава максималния процент без купчина след GC, за да се избегне свиването.
  • -XX: MinHeapFreeRatio : задава минималния процент без купчина след GC, за да се избегне разширяване; за да следите използването на купчината, можете да използвате VisualVM, доставен с JDK.
  • -XX: SurvivorRatio : Съотношение на Eden / наследствена размер пространство - например -XX: SurvivorRatio = 6 комплекта съотношението между всяка наследствена пространство и Eden пространство да бъде 1: 6,
  • -XX: + UseLargePages : използвайте голяма страница памет, ако тя се поддържа от системата; имайте предвид, че OpenJDK 7 има тенденция да се срива, ако се използва този JVM параметър

  • -XX: + UseStringCache : позволява кеширане на често разпределени низове, налични в String pool

  • -XX: + UseCompressedStrings : използвайте тип байт [] за String обекти, които могат да бъдат представени в чист ASCII формат
  • -XX: + OptimizeStringConcat : тя оптимизира String операциите конкатенация, където е възможно

8. Заключение

В тази бърза статия научихме за някои важни параметри на JVM - които могат да се използват за настройка и подобряване на общата производителност на приложението.

Някои от тях също могат да се използват за отстраняване на грешки.

Ако искате да разгледате по-подробно референтните параметри, можете да започнете тук.