Я давно не писал оригинал.Это первый оригинал в 2021 году, и я снова начал свой оригинальный путь.Сегодня я поделюсь недавно законченной книгой "Углубленная виртуальная машина JVM, третье издание". Всего ушло три Я прочитал ее за несколько дней.Я думаю, что многие ее не читали.Все-таки это более 700 страниц.Не легко продолжать читать.
На самом деле, до прочтения этой книги, я уже изучил многое из содержания этой книги, поэтому повторное чтение этой книги - это повторение очков знаний. Это также быстрее и целенаправленнее. Я также специально провел собственное исследование и подвел итоги. моя собственная карта разума:Мое личное самостоятельное изучение и резюме посвящены настройке, поэтому цель чтения этой книги очень проста: дать себе более глубокое понимание настройки JVM.
Эта ментальная карта тоже копилась давно, где-то больше года, до сих пор помню, как впервые увидела."Углубленная виртуальная машина JVM"В то время все было туманно, и я не читал ее с первого раза.
Позже я получил много знаний о JVM по частям из-за работы, и записал это.Это стало моей последней картой разума.Я чувствую, что она относительно завершена в плане настройки.
Давайте начнем наше путешествие по чистке книг. Давайте взглянем на общий каталог этой книги. Есть пять основных частей. Прежде всего, первую большую часть можно сразу пропустить. Вы довольны? :Также есть пятая часть, потому что эта часть относится к содержанию параллельного программирования, и содержание в ней в основном написано в моих предыдущих оригинальных сообщениях в блоге, так что я потратил час на чтение содержания этой части.
На самом деле, вам не нужно читать эту часть содержания. Она будет включена в книгу "Практика параллельного программирования". Моя следующая книга - это "Практика параллельного программирования". Вы также можете сразу ее пропустить. Это не другая часть.
Также есть четвертая часть.Эта часть должна быть необязательной.Лично я в основном фокусируюсь на компиляторе реального времени,потому что компилятор реального времени по-прежнему очень важен.Также будут заданы некоторые интервью.Я прочту остальные части вскользь Общее содержание не то, что вы хотите, потому что вы не можете вспомнить его, когда смотрите на него, и вы не можете использовать его на практике, по крайней мере, не на этом этапе, и задается почти 0 интервью.
Есть еще и третья часть,и третья часть тоже необязательна.Например в шестой главе третьей части он рассказывает о структуре class файла,начиная с бинарной системы,помните?Могу вообще не помню... Ах да, там еще разные инструкции байткода, что никак не влияет на настроение и уверенность в чтении.
Например, на картинке ниже показано содержание шестой главы третьей части. Он покажет вам файлы класса один за другим. Что означает каждая позиция? Как вы думаете, сколько вы сможете вспомнить после прочтения этого? Все вернуться к нулю, поэтому эту часть можно пропустить напрямую.
Но очень важна подсистема загрузки классов третьей части, в том числе процесс загрузки классов внутри, типичныйТрехуровневый загрузчик классов, пользовательский загрузчик классов, механизм родительского делегирования, это то, на что мы должны обратить внимание. Когда я ранее брал интервью у Bytes, меня спрашивали о процессе загрузки классов и механизме родительского делегирования. Это также должно быть в центре внимания.
Однако, если цель большого парня такая же, как и у меня, основное внимание уделяется настройке, На самом деле ваше внимание сосредоточено на второй части, с которой вам предстоит разобраться.
Далее давайте рассмотрим вторую часть — это управление памятью JVM, то есть модель памяти, содержимое области данных времени выполнения и средства мониторинга, используемые для наблюдения за памятью JVM. в этой части должно быть много технических блогов Господи, я писал сообщения в блогах, поэтому я чувствую, что все, кто читает эту часть, должны рассматриваться как просто обзор:
Вторая глава посвящена объяснению области данных времени выполнения Java, объектов Java и исключений OOM Область данных времени выполнения была хорошо воспринята всеми, включая следующие части:
- счетчик команд
- Стек виртуальной машины Java
- собственный стек методов
- куча Java
- область метода
- постоянный пул времени выполнения
- прямая память
Здесь нам нужно понять значение этих областей, которые являются частными для потоков, которые совместно используются потоками и которые вызывают исключения OOM.
прямая памятьМожет быть, некоторые люди относительно незнакомы. Прямая память не является частью виртуальной машины. Это локальная память. Согласно здравому смыслу, ее размер связан с проблемой OOM и локальной памятью. Вы также можете передать-XX:MaxDirectMemorySizeпараметр, чтобы установить его размер.
Одна из инфраструктур Java, имеющая какое-то отношение к этой части памяти,Netty, потому что нижний слой Netty используетNIO, это датьрядибуферIO, он проходит черезDirectByteBufferобъект для работы с этой памятью.
ДалееСоздание объекта, структура памяти объекта, доступ к объектуВ трех частях о том, как магия Java проходитnewКлючевые слова, которые создают объекты, в основном включают эти понятия в части создания объекта:Коллизия указателей, буфер выделения локального потока (Thread Local AllocationBuffer, TLAB).
Как объектам выделяется память? Как избежать конкуренции за ресурсы памяти при многопоточности? Где выделить память (куча, стек)? Содержание этого раздела в основном объясняется этими вопросами.
После того, как объект создан и память выделена, как объект размещается в памяти? Я думаю, вы, возможно, читали статью, прежде чем сказать: XX большая фабрика XX лицо, интервьюер: Вы знаете, насколько велик объект в Java ?
Объект делится на несколько частей (заголовок объекта (Header), экземпляр Данные (Instance Data) и отступы выравнивания (Padding), и заголовок объекта (Mark Word) какой контент содержит и так далее, вы можете найти ответ в этой части.
Наконец, есть доступ к объекту:дескриптор, прямой указатель. В чем разница между этими двумя способами? Каковы недостатки и преимущества каждого из них? Если вы разбираетесь в этих вопросах, даже если освоили более 90%.
Вышеупомянутое содержание является теоретическим, теория всегда служит для реального боя, а следующее исключение OOM частично относится к реальному бою.За исключением счетчика программ, в областях данных времени выполнения, представленных ранее, не будет OOM, и другие части могут быть Появляется ООМ.
За исключением того, что счетчик программ не нужно учитывать (следующая настройка может напрямую игнорировать счетчик программ), куча Java является наиболее важной и сложной частью настройки в JVM, В основном, сложные параметры настройки в JVM смещены Что касается кучи Java, какое решение для OOM в периоде данных времени выполнения, кроме кучи Java?Самый эффективный способ - правильно увеличить память.
Настройка кучи Java не так проста, как простое увеличение памяти Иногда, когда куча Java увеличивает кучу, это будет контрпродуктивно, потому что, хотя память велика, количество объектов, которые могут быть выделены в новом поколении, может также увеличиваются, но единовременно Время сбора GC также стало больше, что приведет к увеличению времени зависания системы.
Для тех приложений, которые требуют частого взаимодействия с пользователем и требуют короткого времени отклика, это неприемлемо.Может быть, вас ищет начальник: сволочь, это та JVM, которую вы настраивали в прошлый раз?Сейчас это занимает больше времени и пользователи жалуются каждый день, у вас есть сделать это сегодня вечером или не прийти завтра.
Таким образом, настройка кучи Java является важным и трудным заданием, прежде всего в этой части, чтобы понять и ознакомиться с различными регионами, появляющимися исключениями OOM, как правило, как распечатать информацию о стеке, например, OOM кучи будет выглядеть так:
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid3404.hprof ...
Heap dump file created [22045981 bytes in 0.663 secs]
В стеке информации можно увидеть "Java heap space"Это название, а какие сцены вызовут переполнение памяти этих частей? Это тоже важнее, напримерГлубина рекурсии слишком велика, метод слишком длинный, в программе появляются большие объекты, утечки памяти, необоснованно задано количество пулов потоков, чрезмерно используется прокси, слишком велико количество констант, информация о классе переборИ так вызовет ли OOM те области соответственно?
На самом деле перед настройкой еще есть что прояснить.Возможно процентов 70-80 проблем можно решить оптимизацией кода.Например,если метод слишком длинный,достаточно разобрать метод.Если большой объект появляется, создайте маленькую.Маленького объекта недостаточно.
Тем не менее, иногда вы можете игнорировать некоторые проблемы, такие как большие объекты (возможно, несколько объектов одновременно), хотя вы очень осторожны в разработке, объекты контролируются очень маленькими, а трафик в производстве. Как только он возникает, OOM появляется, и только рабочий трафик может проверить некоторые из ваших запущенных функций.
Например, на стороне ПК будет функция экспорта, включая экспорт текущей страницы и весь экспорт, особенно этот весь экспорт, нет проблем, когда объем данных небольшой, если объем данных большой , а как только появится поток, тоОдновременно создается много объектов Excell., ООМ появился случайно.
Другим примером является ориентированная на пользователя домашняя страница стороны C. Как правило, домашняя страница стороны C кэшируется, чтобы улучшить взаимодействие с пользователем.Тогда, когда количество кешей слишком велико, будет слишком много объектов, полученных из кеша одновременно, или объекты будут слишком большими..
Для содержания этой части, моя предыдущая карта разума также сделала очень подробное резюме.Далее только часть его.Вы можете использовать его как справку,а также очень важно всем подумать.Следующая третья глава посвящена GC.Область настройки — это куча Java, включая то, как определить, жив ли объект (Метод подсчета ссылок, алгоритм анализа достижимости), три основных алгоритма сборки мусора (Отметить-Очистить, Алгоритм копирования, Отметить-Организовать), теория моделей поколений (новое поколение, старость), а также часто используемые классические сборщики мусора, словосочетания и применимые сценарии. Если вы разберетесь в этих вопросах, вы будете непобедимы, и вы поймете эту часть содержания.
Среди них классический сборщик мусора относительно незнакомается всем. Другие части, такие как алгоритм сборки мусора, теория модели поколения, и судя по живым, был ли объект, был написан многие технические блоггеры. Я также написал оригинальную статью на мусор Алгоритм сбора ранее. Все вы можете обратиться к нему.
Давайте сосредоточимся на сборщике мусора.С непрерывным развитием jdk и постоянным обновлением версий сервер превратился из одноядерного в многоядерный, памяти стало больше, а сборщик мусора стал все более и более интеллектуальным. собственные применимые сценарии.
Наиболее распространенные комбинации этих типов сборщиков мусора показаны на следующем рисунке:Моя личная память о комбинации:
- SerialиSerial Old
- PSиPO
- ParNewиCMS
- G1
У каждого сборщика мусора есть свои сценарии использования, преимущества и недостатки, так что просто посмотрите на эту часть с этими вопросами:
- Что такое сборщики мусора для молодого поколения и старшего поколения?
- Преимущества и недостатки каждого типа сборщика мусора?
- Каковы сценарии использования каждого сборщика мусора?
- Как работает каждый тип сборщика мусора?
- Каковы соответствующие настройки JVM для каждого сборщика мусора?
Если вы разберетесь в этих вопросах, вы сможете разобраться в них досконально.Например, при обращении вСерийный коллектор в эпоху одноядерных процессоровОдной из основных его проблем является проблема STW и эффективности однопоточной сборки мусора, но для одноядерных серверов это, несомненно, лучший выбор.
И позже, перейдя в многопоточную эру PS и PO, из исходной однопоточной коллекции, а теперь и для программирования многопоточной сборки, эффективность времени исходной сборки мусора должна быть улучшена, но для многопоточности есть установить количество потоков для сборки мусора, сколько предлагается в книге.
Более классическийCMS,CMSЕсть четыре стадииНачальная отметка, одновременная отметка, замечание, одновременная очистка.Каковы принципы этих четырех этапов, эти этапы работают одновременно с пользовательскими потоками, как CMS минимизирует проблему STW, каков диапазон размеров кучи, к которым обычно применим CMS, и так далее.
Соответствующие части ответов на эти вопросы ясно объяснены, и вы можете внимательно их изучить.Последний — G1, а все предыдущие классические сборщики мусора имеют модель поколений.
Однако у поколенческой модели есть свои проблемы.Например, классическому поколенческому сборщику мусора соответствует сборка всего размера кучи.С улучшением производительности сервера память сервера также будет становиться все больше и больше.Теперь размер из нескольких g или 10 g на каждом ходу приведет к тому, что время одной сборки мусора станет все больше и больше, и время паузы также будет увеличиваться, потому что текущую позицию STW нельзя устранить, только уменьшить насколько это возможно.
Вот почему позже появился G1, который ослабил сборку мусора теоретической модели поколений и изменил кучу, чтобы она разделялась на по одному.Region, каждый регион не является фиксированным поколением (новое поколение, старое поколение),Когда происходит сборка мусора, G1 записывает время восстановления каждого региона, чтобы можно было подсчитать стоимость восстановления, поэтому G1 достигает приемлемого для пользователя времени паузы (STW, обычно 100-300 миллисекунд) временного диапазона для сборки мусора, не для всей кучи.
Выше приведены преимущества, которые дает G1 для решения проблем традиционных сборщиков мусора, но у самого G1 все еще есть проблемы, такие как плавающий мусор, который до сих пор не решен G1, и G1 в крайних случаях может вызвать феномен системной анабиоза.
Это также одна из причин, почему сборщик мусора по умолчанию не G1.Эти проблемы можно найти в тексте.Содержание этой части необходимо внимательно изучить.
Среди них также есть два сборщика, ориентированных на низкую задержку, которые мы пока не можем использовать на данном этапе.Вы можете увидеть, если посмотрите сценарии, где он используется, и он применим к куче Java. размер, так что вы можете игнорировать его:
Конечно, если вам интересно, вы также можете прочитать это внимательно, ведь это то, что написано начальством, и это суть, когда вы это впитываете.
После ознакомления с описанным выше принципом централизованной сборки мусора и владения им, фактический бой начинается следующим образом: здесь я всегда решаю часто используемые параметры настройки JVM в своей карте ума:Конечно, они есть и в книгах, но они разрознены, и я их в основном суммировал здесь.
Далее идет собственно боевая часть, включающая в себя некоторые сценарии и принципы:Принципы выделения памяти объектам, большие объекты, долгоживущие объекты, возраст объекта, гарантия выделения пространства, Содержимое этой части тоже нужно тщательно распробовать, оно должно быть сутью.
Четвертая глава - инструмент настройки.Для инструмента я использую VisualVM, который поставляется с jdk, который можно настроить в идее, и может установить плагин GC и другие плагины, что очень удобно, но он Как правило, для локальных или тестовых сред, таких как онлайн-инструменты, я рекомендую использовать инструмент Arthas от Али.У Baidu есть куча руководств.
Существует относительно примитивный метод устранения неполадок с использованием команд Linux, таких какjps, jstat, jinfo, jmap, jstack, эта часть подробно объясняется в книге:
Для использования этих оригинальных команд в основном есть две контрольные точки и две фактические боевые точки, а именно:Проанализируйте проблему высокой загрузки процессора и проанализируйте проблему OOM. Другой — проанализировать проблему нехватки памяти, что относительно просто.
Если вы сможете использовать вышеперечисленные оригинальные команды и инструменты анализа для самостоятельного анализа вышеперечисленных проблем, то вы непобедимы.Мастер тюнинга, босс не потратит на вас много денег.
Также можете обратиться к моей собственной карте ума, методы похожи, разница неплохая, но не полная, т.к. некоторые не разобрались:
В пятой главе я чувствую, что все могут ее пропустить.Возможно, опыт босса отличается от нашего.Настоящая боевая сцена встречается редко, поэтому я просто пропустил ее.
Если вы досконально разобрались в вышеизложенном содержании, следующее содержание носит в основном чисто теоретический характер и для вас не составит труда:
Третья часть непосредственно просматривает механизм загрузки виртуальной машины, в том числеПроцесс загрузки классов, классический трехуровневый загрузчик, пользовательский загрузчик классов, родительское делегирование и т. д., они находятся в центре внимания этого раздела.В этой части вы можете поблагодарить код за то, как реализовать собственный загрузчик классов, загрузить свой собственный класс, как уничтожить родительскую модель делегирования и другие вопросы, которые объясняются в статье.
Ну я в основном впитал в себя то содержание, которое лично мне здесь нужно.Я просто читал эту книгу с целью тюнинга.Тут поясню,это не то,что содержание,которое я не читал,значит,что написано нехорошо,это дело не в этом.Просто мы учимся целенаправленно.Содержание в книге очень подробное,но не все то что нам нужно.По крайней мере на данном этапе я просто помогаю вам извлечь нужное нам содержание,а потом делюсь им для себя Цель этой книги и опыт.
Из-за нехватки места я продолжу делиться своим углубленным изучением и пониманием виртуальной машины JVM позже, если это необходимо.«В третье издание виртуальной машины JVM»Электронные книги могут добавлять мой WeChat:abc730500468, я отметил ключевые части книги, чтобы вам было легко их расчесывать, а процесс расчесывания можно было обсудить друг с другом.Хорошо, я Ли Ду, увидимся в следующем выпуске.