интервьюер:Хотели бы вы сегодня поговорить о настройке JVM?
интервьюер:Был ли у вас когда-нибудь опыт настройки JVM в производственной среде?
Кандидат:нет
интервьюер:…
Кандидат: Ну... вот так, наше общее представление об оптимизации системы такое
Кандидат: 1. Вообще говоря, реляционная база данных является первым узким местом, сначала проверьте, не проблема ли это с базой данных.
Кандидат: (В этом процессе вам необходимо оценить, разумен ли созданный вами индекс, нужно ли вам ввести распределенный кеш, нужно ли вам подбазу данных и подтаблицу и т. д.)
Кандидат: 2. Потом подумаем, нужно ли нам расширяться (как по горизонтали, так и по вертикали)
Кандидат: (В этом процессе мы будем подозревать, что система находится под слишком большим давлением или аппаратные возможности системы недостаточны, что вызывает частые проблемы в системе)
Кандидат: 3. Далее проверьте и оптимизируйте на уровне кода приложения
Кандидат:( Расширение не может быть бесконечным, а деньги внутри и снаружи есть. В этом процессе мы исследуем, есть ли в написанном нами коде проблема растраты ресурсов, или же в логике есть место для оптимизации, например за счет параллелизма способ обработки определенных запросов)
Кандидат: 4. Далее проверка и оптимизация на уровне JVM
Кандидат: (После проверки кода мы наблюдаем, есть ли множественные проблемы GC в JVM во время этого процесса и т. д.)
Кандидат: 5. Наконец, проверьте на уровне сети и операционной системы
Кандидат: (Этот процесс проверяет, в норме ли индикаторы чтения и записи памяти/ЦП/сети/жесткого диска и т. д.)
Кандидат: В большинстве случаев третий этап пройден.В целом, параметры JVM и машины, заданные нам «командой эксплуатации и обслуживания», удовлетворяют большинству потребностей.
Кандидат: Ранее другие команды обнаруживали проблему таймаута обработки интерфейса в "большом продвижении", тогда возникало подозрение, что FULL GC вызван различными проверками мониторинга.
Кандидат: Первая идея — не настраивать различные параметры JVM для оптимизации, а напрямую добавлять машину
Кандидат:(самым грубым способом решить проблему проще всего расширить YYDS)
интервьюер:В самом деле
Кандидат: Тем не менее, я изучил команды и идеи настройки, связанные с JVM.
Кандидат: В моем понимании настройка JVM на самом деле заключается в «настройке параметров» на основе предпосылки «понимания» структуры памяти JVM и различных сборщиков мусора в сочетании с вашим существующим бизнесом, чтобы ваше приложение могло работать нормально и стабильно.
Кандидат: В общей настройке JVM, мы думаем, есть несколько показателей для справки: "пропускная способность", "время паузы" и "частота сборки мусора"
Кандидат: На основе этих показателей нам может потребоваться скорректировать:
Кандидат: 1. Размер области памяти и связанные стратегии (например, сколько занимает вся куча, сколько занимает новое поколение, сколько занимает старое поколение, сколько занимает оставшийся в живых, условия продвижения старого поколения, и т.д.)
Кандидат: Например (-Xmx: задать максимальное значение кучи, -Xms: задать начальное значение кучи, -Xmn: указать размер молодого поколения, -XX: SurvivorRatio: отношение площади Эдема к зона выживания и др.)
Кандидат:(По опыту: IO-интенсивные могут немного увеличить пространство "молодого поколения", потому что большинство объектов умрут в молодом поколении. Интенсивные к памяти могут немного увеличить пространство "старого поколения". Чем больше, тем объект будет жить дольше)
Кандидат: 2. Сборщик мусора (выберите соответствующий сборщик мусора и различные параметры настройки каждого сборщика мусора)
Кандидат: Например (-XX:+UseG1GC: указать сборщик мусора, используемый JVM как G1, -XX:MaxGCPauseMillis: установить целевое время паузы, -XX:InitiatingHeapOccupancyPercent: когда использование всей памяти кучи достигает определенного процента, глобальный будет запущена параллельная фаза маркировки и т. д.)
Кандидат: Да, это все исходя из местных условий, конкретного разбора конкретных проблем (при условии, что вы понимаете всякие базовые знания JVM, вы не понимаете базовых знаний, что там с настройкой)
Кандидат: В большинстве сценариев JVM удалось достичь «из коробки».
интервьюер:В самом деле
Кандидат: Как правило, мы выполняем настройку только после «обнаружения проблем», а после обнаружения проблем нам необходимо использовать различные «инструменты» для устранения неполадок.
Кандидат: 1. Просмотрите "основную" информацию (идентификатор процесса, основной класс) процесса Java с помощью команды jps. Эта команда очень часто используется, чтобы увидеть, сколько процессов Java запущено на текущем сервере, каковы их номера процессов и загружен основной класс?
Кандидат: 2. Используйте команду jstat для просмотра информации, относящейся к «статистическому классу» процесса Java (загрузка класса, статистика информации, связанной с компиляцией, обзор сборщика мусора и статистика каждой области памяти). Эта команда часто используется для просмотра ситуации с сборщиком мусора.
Кандидат: 3. Просмотрите и настройте «параметры выполнения» Java-процесса с помощью команды jinfo.
Кандидат: 4. Просмотрите "информацию о памяти" Java-процесса с помощью команды jmap. Эта команда часто используется для вывода информации о памяти JVM в файл, а затем для анализа файла используется MAT (инструмент анализа памяти).
Кандидат: 5. Просмотрите «информацию о потоке» JVM с помощью команды jstack. Эта команда использует общий язык для устранения неполадок, связанных с взаимоблокировкой.
Кандидат: 6. Существует также недавно популярный Arthas (диагностический инструмент с открытым исходным кодом Alibaba), который охватывает функции многих из вышеперечисленных команд и поставляется с графическим интерфейсом. Это также мой часто используемый инструмент для устранения неполадок и анализа.
интервьюер:Ладно. Говоря о JVM ранее, вы также упомянули, что на этапе «интерпретации» есть два способа интерпретировать информацию байт-кода в код машинных инструкций: один — интерпретатор байт-кода, а другой — JIT-компилятор (JIT). ).
интервьюер:Я хотел бы спросить, понимаете ли вы технологию JIT-оптимизации JVM?
Кандидат: Есть два хорошо известных метода JIT-оптимизации: встраивание методов и анализ экранирования.
Кандидат: так называемое встраивание методов заключается в копировании кода «целевого метода» в «вызывающий метод», чтобы избежать реальных вызовов метода.
Кандидат: поскольку каждый вызов метода будет генерировать кадр стека (нажатие на стек и извлечение стека для записи местоположения вызова метода и т. д.), это приведет к определенной потере производительности, поэтому оптимизация «встраивания методов» может улучшить определенную производительность.
Кандидат: Есть также связанные параметры, которые мы можем указать в JVM (-XX:MaxFreqInlineSize, -XX:MaxInlineSize).
Кандидат: "Анализ побега" – это метод анализа, позволяющий определить, ссылается ли на объект внешний метод или к нему обращается внешний поток. Если на объект нет ссылки, его можно оптимизировать, например:
Кандидат: 1. Устранение блокировки (игнорирование синхронизации): доступ к объекту осуществляется только внутри метода, и на него нельзя ссылаться где-либо еще, поэтому он должен быть потокобезопасным, а код, связанный с блокировкой, можно игнорировать.
Кандидат: 2. Размещение в стеке: доступ к объекту будет осуществляться только внутри метода, а объект размещается непосредственно в «стеке» (Java по умолчанию выделяет объекты в «куче», которую необходимо перерабатывать через мусор JVM период сбора. Потеряете определенное количество производительности, и распределение в стеке будет намного быстрее)
Кандидат: 3. Скалярный объект замены/разделения: когда программа фактически выполняется, вы не можете создавать этот объект, а вместо этого напрямую создаете его переменные-члены. После разделения объекта переменные-члены объекта могут быть размещены в стеке или регистре, и исходному объекту не нужно выделять место в памяти.
Кандидат: Но после такого, разные версии JVM имеют разные оптимизации для JIT (: Это можно рассматривать только как справку
интервьюер:понял.
Предлагаемые чтения:[Блог Meituan Technology] Анализ и решения 9 распространенных проблем CMS GC в Java
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !