CRaSH — это повторно используемая оболочка, которая развертывается в JVM и помогает нам взаимодействовать с JVM.
В этом руководстве мы увидим, как установить CRaSH как отдельное приложение. Кроме того, мы встроим его в веб-приложение Spring и создадим несколько пользовательских команд.
Давайте установим CRaSH как отдельное приложение, скачав дистрибутив с официального сайта CRaSH.
В этом учебнике мы проанализируем технику составления списка всех классов, загружаемых определенным загрузчиком классов в Java, с использованием API инструментария Java `` . Мы также увидим, как создать и загрузить агент Java для получения экземпляра Instrumentation и вызвать необходимые методы для выполнения нашей задачи.
Загрузчики классов являются неотъемлемой частью JRE (Java Runtime Environment). Их работа заключается в динамической загрузке классов в виртуальную машину Java . Другими словами, они загружают классы в память по требованию, когда этого требует приложение. В статье о загрузчиках классов Java рассказывается об их различных типах и подробно рассказывается, как они работают.
инструментального APIВ этой статье мы сравним BitSet и boolean[] с точки зрения производительности в разных сценариях.
Обычно мы очень широко используем термин производительность, имея в виду разные значения. Поэтому начнем с рассмотрения различных определений термина «производительность».
Затем мы собираемся использовать две разные метрики производительности для тестов: объем памяти и пропускная способность. Чтобы оценить пропускную способность, мы сравним несколько распространенных операций с битовыми векторами.
В этой короткой статье мы увидим разницу между различными показателями размера памяти в JVM.
Сначала мы поговорим о том, как работает адаптивный размер, а затем оценим разницу между максимальным, используемым и зафиксированным размерами.
Два значения управляют размером кучи JVM : одно начальное значение, указанное с помощью флага -Xms, и другое максимальное значение, управляемое флагом настройки -Xmx .
Можно настроить HotSpot JVM с помощью различных флагов настройки. Поскольку существуют сотни таких флагов, отслеживание их и их значений по умолчанию может быть немного сложным.
В этом уроке мы познакомим вас с несколькими способами обнаружения таких флагов настройки и научимся с ними работать.
Команда java поддерживает множество флагов, относящихся к следующим категориям:
Вы когда-нибудь задумывались, почему Java-приложения потребляют гораздо больше памяти, чем указано в хорошо известных флагах настройки -Xms и -Xmx ? По ряду причин и возможных оптимизаций JVM может выделять дополнительную собственную память. Эти дополнительные выделения могут в конечном итоге увеличить потребляемую память сверх ограничения -Xmx .
В этом руководстве мы собираемся перечислить несколько распространенных источников выделения собственной памяти в JVM вместе с их флагами настройки размера, а затем узнаем, как использовать отслеживание собственной памяти для их мониторинга.
Куча обычно является самым большим потребителем памяти в Java-приложениях, но есть и другие. Помимо кучи, JVM выделяет довольно большой кусок собственной памяти для хранения метаданных своего класса, кода приложения, кода, сгенерированного JIT, внутренних структур данных и т. д. В следующих разделах мы рассмотрим некоторые из этих выделений.
В этом кратком руководстве мы увидим, как найти адрес памяти объектов в Java.
Прежде чем двигаться дальше, стоит упомянуть, что структура памяти для областей данных времени выполнения не является частью спецификации JVM и остается на усмотрение разработчика . Поэтому у каждой реализации JVM может быть своя стратегия размещения объектов и массивов в памяти. Это, в свою очередь, повлияет на адреса памяти.
В этом руководстве мы сосредоточимся на одной конкретной реализации JVM: HotSpot JVM. Мы также можем использовать термины JVM и HotSpot JVM как синонимы на протяжении всего руководства.
В этой быстрой статье мы увидим, каково влияние логического значения в JVM при различных обстоятельствах.
Сначала мы проверим JVM, чтобы увидеть размеры объектов. Тогда мы поймем обоснование этих размеров.
Чтобы проверить расположение объектов в памяти в JVM, мы будем широко использовать Java Object Layout ( JOL ). Поэтому нам нужно добавить зависимость jol-core : ``
В этом кратком руководстве мы увидим, как и где JVM HotSpot хранит длину массива.
Обычно расположение областей данных времени выполнения в памяти не является частью спецификации JVM и оставлено на усмотрение разработчика . Поэтому у каждой реализации JVM может быть своя стратегия размещения объектов и массивов в памяти.
В этом руководстве мы сосредоточимся на одной конкретной реализации JVM: HotSpot JVM. Мы также можем взаимозаменяемо использовать термины JVM и HotSpot JVM.
В этой статье мы обсудим API-интерфейсы, предоставляемые Java, которые могут помочь нам понять несколько аспектов, связанных с пространством кучи Java .
Это может быть полезно для понимания текущего состояния памяти JVM и передачи его на аутсорсинг службам мониторинга, таким как StatsD и Datadog , которые затем можно настроить для выполнения упреждающих действий и предотвращения сбоев приложений.
Каждое приложение Java имеет единственный экземпляр java.lang.Runtime , который может помочь нам понять текущее состояние памяти приложения. Статический метод Runtime#getRuntime можно вызвать для получения одноэлементного экземпляра среды выполнения .