предисловие
Все знакомы с настройкой JVM, и мы, должно быть, слышали от наших друзей: во время интервью некоторые интервьюеры ухватятся за настройку JVM и не отпустят, и будут много спрашивать о настройке JVM Вопрос, я запутался. 😵 Хотя интервьюер будет использовать это в качестве основного предмета интервью, большинство мелких партнеров редко оптимизируют JVM в реальном процессе разработки, поэтому они мало знают о настройке JVM. Сегодня я расскажу вам о JVM простыми словами и поделюсь с вами своими знаниями 🙇
что такое JVM
Прежде чем говорить о настройке JVM, давайте посмотрим, что такое JVM👇.
JVM — это аббревиатура от Java Virtual Machine (Виртуальная машина Java).JVM — это спецификация для вычислительных устройств.Это воображаемый компьютер, реализуемый путем имитации различных компьютерных функций на реальном компьютере.
После введения виртуальной машины языка Java язык Java не нужно перекомпилировать при работе на разных платформах. Язык Java использует виртуальную машину Java для защиты информации, относящейся к конкретной платформе, так что компилятору языка Java нужно только сгенерировать объектный код (байт-код), работающий на виртуальной машине Java, и он может работать на различных платформах без изменений. . . . (Вышеприведенный контент взят из Baidu)
Виртуальная машина Java — это, по сути, программа, которая при запуске из командной строки начинает выполнять инструкции, хранящиеся в файле байт-кода. Переносимость языка Java основана на виртуальной машине Java. Вы, ребята, должны были слышать поговорку:Java — независимый от платформы язык программирования, причина этого в том, что существует виртуальная машина Java, поскольку виртуальная машина Java знает длину инструкции и другие характеристики базовой аппаратной платформы, а исходные файлы Java могут быть скомпилированы в файлы байт-кода, которые могут быть выполнены Виртуальная машина Java (файл .class), поэтому независимо от платформы, если платформа оснащена виртуальной машиной Java, соответствующей платформе, файл байт-кода (файл .class), скомпилированный из исходного файла Java, может работать на платформе.Это "после компиляции запускать несколько раз".
Это может быть немного сложно понять, это все еще старое правило, позвольте мне рассказать вам о моем «жалком понимании»: например, нам нужно вырастить утку сейчас, но наша среда выращивания часто меняется (сегодня выросли дома, завтра может уйти в другие места) так как уточка относительно маленькая, нам нужно подготовить для нее инкубатор, чтобы ей было комфортно жить в инкубаторе. Если выращивается дома, то используем обычный инкубатор, если меняют на более холодное место, то надо менять на более толстый инкубатор. Утенок — это исходный файл Java, который мы написали, а инкубатор — это виртуальная машина Java. Разные среды соответствуют разным платформам. маленькая утка растет счастливо.
Так что, если мы хотим улучшить качество жизни утят? На самом деле, этот метод также очень прост Мы можем трансформировать инкубатор, например, добавить больше места, разместить раковину, положить немного хлопка и т. д. Эти методы могут сделать инкубатор «обновленным», и процесс обновления инкубатора соответствует to Это настройка JVM. Давайте поговорим о сегодняшнем фокусе - настройке JVM👇
Настройка JVM
Разработанное нами системное программное обеспечение может столкнуться с некоторыми проблемами при тестировании или эксплуатации перед подключением к сети, такими как высокая загрузка ЦП, отложенные запросы или более длительное время сборки мусора и более частая сборка мусора.Чем больше раз, тем меньше мусорные данные очищаются каждый раз при сборке мусора и т. д. Это все проблемы JVM.Эти проблемы будут более или менее влиять на скорость выполнения системного ПО, поэтому нам нужно настроить JVM.Отлично. Конечная цель нашей настройки — позволить приложению работать с большей пропускной способностью при минимальном потреблении оборудования. Настройка JVM в основном направлена на оптимизацию производительности сборки сборщика мусора, чтобы приложения, работающие на виртуальных машинах, могли использовать меньше памяти и задержек для получения большей пропускной способности, повышения удобства работы пользователей и эффективности работы.
Этапы настройки JVM
Некоторые младшие партнеры думали, что настройка JVM может вызвать много проблем, не зная, с чего начать. На самом деле шаг настройки JVM тоже очень прост 👇
① Проанализируйте журналы GC и файлы дампа, определите, нужна ли оптимизация, и определите основную причину проблемы. ② Определите цель квантования настройки JVM и параметры настройки JVM (параметры настройки JVM настраиваются на основе исторических параметров JVM). ③ Настройка памяти, задержки, пропускной способности и других показателей по очереди ④ Сравните и наблюдайте за различиями до и после настройки, а также необходимо постоянно анализировать и настраивать параметры, пока не будет найдена подходящая конфигурация параметров JVM; ⑤ Найдите наиболее подходящие параметры, примените эти параметры ко всем серверам и отслеживайте.
Подведем итог вышеописанным шагам, которые на самом деле разделены на три этапа (аналогично помещению слона в холодильник): первый — анализ логов для подтверждения необходимости настройки, второй — подтверждение целей настройки и параметров настройки; последний шаг - повторить тест и отследить. Посмотрим, не будет ли в этот раз настройка JVM такой уж сложной😀
В приведенных выше шагах операции некоторые шаги необходимо выполнить за несколько итераций (например, настройка параметров, отслеживание удачи после настройки).Здесь следует отметить одну вещь.Когда мы настраиваем, мы обычно начинаем с удовлетворения требований программы к использованию памяти, затем соблюдаем требования программы к временной задержке и, наконец, удовлетворяем требования к пропускной способности программы.Мы должны следовать этим шагам. постоянно оптимизируются, каждый шаг является основой для следующего шага, и нельзя делать наоборот🈲.
Параметры, связанные с JVM
Среди шагов, упомянутых выше, наиболее важным шагом является настройка параметров JVM, поэтому нам нужно иметь определенное представление о параметрах JVM.Позвольте мне сначала поговорить о соответствующем содержании параметров JVM👇
Параметр -XX называется нестабильными параметрами, такие параметры настройки могут легко привести к различиям в производительности на JVM, существуют JVM, которые также создают большую неопределенность. Если этот параметр установлен разумно, это значительно улучшит производительность и стабильность JVM. Такие параметры нестабильности можно понять как палку о двух концах, можно с пользой использовать всплеск мощности, можно навредить противнику, появится от потери ста десяти тысяч ситуация с плохой. Нестабильные параметры разделены на три категории, а именно, значение логического параметра, числовой параметр и значение параметра строкового типа, значение параметра. Значение логического параметра делится на два типа: -XX: + и -XX: -, "+" означает, что опция включена; "-" означает, что эта опция отключена; числовой формат параметра: -XX:, чтобы установить option значение числового типа, значение может увеличиваться в обратном порядке, например: "m" или "m" представляют мегабайты, "k" или "K" представляют килобайты, формат и тип параметров числовой параметр строкового типа одинаковый , за исключением того, что с последними другими значениями значение параметра строкового типа является строковым типом, обычно используемым для указания списка путей к файлам или последовательности команд. Например: -XX:HeapDumpPath=xxx/xxx/xxx (путь к файлу).
Давайте рассмотрим несколько конкретных примеров 👇
-Xms2g -Xmx2g -Xmn512M -Xss128K -XX:PermSize=128M -XX:MaxPermSize=128M -XX:NewRatio=4 -XX:SurivorRatio=4 -XX:MaxTenuringThreshold=1
-
-Xms2g: размер кучи инициализации JVM при запуске составляет 2 г, а значение по умолчанию Xms составляет 1/64 физической памяти, но меньше 1 г.
-
-Xmx2g: максимальный размер кучи JVM составляет 2g, а Xmx составляет 1/4 физической памяти, но по умолчанию меньше 1G; настройка значений -Xms и -Xmx на одинаковые позволяет избежать сброса JVM размер кучи после завершения каждой сборки мусора.
-
-Xmn512M: Размер молодого поколения в куче 512M
-
-Xss128K: размер стека 128 КБ на поток
-
-XX:PermSize=128M: размер инициализации постоянного поколения JVM составляет 128M.
-
-XX:MaxPermSize=128M: максимальный размер постоянного поколения JVM составляет 128M.
-
-XX:NewRatio=4: соотношение размера кучи JVM нового поколения и старого поколения составляет 1:4.
-
-XX:SurvivorRatio=4: Соотношение площади Кайнозоя Survivor (у Кайнозоя 2 области Survivor) и площади Эдема составляет 2:4.
-
-XX:MaxTenuringThreshold=1: После нескольких сборок мусора (если они еще живы) объекты молодого поколения переходят в старое поколение. Если этот параметр установлен в 0, это означает, что объекты новой генерации не попадают в область выживания после сборки мусора, а сразу попадают в старую генерацию
-XX:+UseParallelGC -XX:ParallelGCThread=4 -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
- -XX:+UseParallelGC: использовать параллельный сборщик мусора, но допустимо только для молодого поколения, старое поколение по-прежнему использует последовательный сборщик
- -XX:ParallelGCThread=4: установить количество параллельных потоков сборщика мусора равным 4, желательно равным количеству процессоров.
- -Xx: + useparalleoldgc: настроить старое поколение, чтобы использовать параллельный сборщик мусора, JDK1.6 поддерживает старое поколение для использования параллельного коллектора
- -Xx: MaxGCPAUSEMILLIS = 100: Установите максимальное время для каждой коллекции мусора нового поколения с помощью коллектора. Если время не будет выполнено, JVM будет автоматически настроить размер области нового поколения, чтобы соответствовать этому значению
- -XX:+UseAdaptiveSizePolicy: после установки этого значения JVM автоматически отрегулирует размер нового поколения и соотношение соответствующей оставшейся области для достижения минимального времени отклика или установленной частоты сбора и т. д.
-XX:UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
- -XX:UseConcMarkSweepGC: установить старый возраст кучи JVM для использования параллельного сборщика CMS.После установки этого параметра параметр -XX:NewRatio становится недопустимым, но параметр -Xmn по-прежнему действителен
- -XX:UseParNewGC: установите новое поколение для использования параллельного сборщика.Выше JDK1.5 JVM автоматически установит его в соответствии с системой
- -XX:CMSFullGCsBeforeCompaction=5: установите 5 для сжатия и организации пространства кучи после CMSGC.
- -XX:+UseCMSCompactAtFullCollection: включить сжатие для старого поколения, что может повлиять на производительность, но может устранить фрагментацию кучи.
Параметры настройки JVM
Задействованных параметров JVM много, но не все параметры необходимо изменять в процессе настройки того, как настраивается JVM, я здесь для всех, чтобы разобраться со следующими рекомендациями по настройке (в основном опыт младшего брата ограничен, это будет намного 😂) 👇
- Для настройки кучи JVM минимальное и максимальное значения обычно могут быть ограничены -Xms и -Xmx, Чтобы сборщик мусора не сжимал кучу между минимальным и максимальным значениями, мы обычно устанавливаем минимальное и максимальные значения к тому же значению.
- Память молодого поколения и старого поколения будет выделена в соответствии с соотношением по умолчанию (исходя из принципа полного GC как можно меньше, пусть старое поколение как можно больше кэширует общие объекты, поэтому соотношение по умолчанию двух составляет 1:2) кучи памяти, которую можно настроить, отрегулировав соотношение между двумя NewRadio, чтобы отрегулировать размер между ними. Кроме того, его также можно установить другими способами, например, для молодого поколения, с помощью -XX:newSize -XX:MaxNewSize, чтобы установить его абсолютный размер. Кроме того, мы обычно устанавливаем -XX:newSize -XX:MaxNewSize равным тому же размеру, чтобы предотвратить сокращение кучи молодого поколения.
- Объемы памяти молодого поколения и старого поколения связаны и ограничены.Они похожи на качели (память одного становится больше, а памяти другого становится меньше), поэтому при установке размера памяти двух вам нужно заплатить особое внимание. Будьте осторожны. Мы можем наблюдать за приложением в течение определенного периода времени, чтобы увидеть, сколько памяти будет занимать старое поколение на пике. Чтобы гарантировать, что полный сборщик мусора не будет затронут, мы можем увеличить память молодого поколения. генерация в соответствии с реальной ситуацией.Например, пропорция может контролироваться на 1:1. Следует отметить, что когда мы регулируем размер памяти, мы должны убедиться, что у старого поколения достаточно места для роста.
- На серверах с высокой конфигурацией (например, многоядерные, с большим объемом памяти) мы можем выбрать алгоритм параллельного сбора старого поколения: -XX:+UseParallelOldGC.
- Когда приложение запущено, каждый поток по умолчанию открывает стек размером 1 МБ, который используется для хранения кадров стека, параметров вызовов, локальных переменных и т. д. Это пространство по умолчанию слишком велико для большинства приложений, поэтому при настройке пространства стека потока Обычно достаточно установить значение 256K.
- Если приложение работает в java.lang.OutOfMemoryError Times: ненормальная память прямого буфера, и мы можем поднять -XX: значение MaxDirectMemorySize, увеличенная прямая память.
- Если вы все еще не знаете, какой параметр настроить, мы можем использовать инструменты анализа (такие как GCViewer), чтобы помочь нам. Используя инструмент настройки, мы можем очень интуитивно проанализировать преимущества, которые необходимо настроить. (Этот трюк можно назвать трюком, хахахаха 😄)
Некоторые скромные мнения о настройке JVM
Наконец, позвольте мне рассказать о некоторых из моих скромных мнений о настройке JVM: на самом деле общие проекты не нуждаются в оптимизации JVM.Даже для некоторых сервисов или программного обеспечения с высокой степенью параллелизма или большим объемом запросов настройка JVM важный. Поскольку сама JVM спроектирована и оптимизирована для этого сервиса с малой задержкой, высокой степенью параллелизма и высокой пропускной способностью, нам действительно редко нужно что-либо менять, поэтому, даже если мы сталкиваемся с ситуацией, требующей настройки, мы также должны сосредоточиться на настройке приложения. себя (если вы поторопитесь с настройкой JVM, это может вызвать больше проблем). Говоря более прямо, даже если JVM-оптимизированные параметры некоторых проектов будут удалены, возможно, они все еще могут работать хорошо (в некоторых крайних случаях могут возникнуть проблемы).
И я не знаю, почему, многие компании любят придерживаться JVM при собеседовании с программистами JAVA и задают много вопросов о JVM На самом деле, я чувствую, что это пустая трата денег. И я не знаю встречались ли ваши знакомые с такими коллегами.Они любят лезть на дно,чтобы решить проблемы.При встрече с проблемами сначала скажут,что исключение вызвано багом в JVM.В случае высокой латентность,скажут да.Есть проблема с алгоритмом GC,и даже рассмотрят замену алгоритма GC(не знаю откуда такая уверенность),честно говоря,даже если масло и вода JVM слили, лучше оптимизировать бизнес-логику.
резюме
Мой опыт ограничен, и некоторые места могут быть не особо к месту.Если у вас возникнут какие-либо вопросы во время чтения, пожалуйста, оставьте сообщение в области комментариев, и мы обсудим их по одному в будущем🙇
Я надеюсь, что вы можете использовать свои милые маленькие руки, чтобы поставить лайк + подписаться (✿◡‿◡), чтобы больше друзей могли увидеть эту статью~ Crab Crab Yo (●'◡'●)
Если в статье есть какая-либо ошибка, пожалуйста, оставьте сообщение, чтобы исправить ее; если у вас есть лучшее и более уникальное понимание, вы можете оставить свои ценные идеи в области сообщений.
Люби то, что любишь, делай то, что делаешь, слушай свое сердце, ничего не проси