an internal look at hotspot jvm

25
INSIDE THE JAVA VIRTUAL MACHINE Управление памятью и решение типичных проблем

Upload: ecommerce-solution-provider-sysiq

Post on 25-Jan-2015

480 views

Category:

Documents


5 download

DESCRIPTION

There are hundreds of JVM parameters and options out there. Here we are going to take a closer look at the internal structure of HotSpot VM while over-viewing memory spaces and different types of Garbage Collectors.

TRANSCRIPT

Page 1: An internal look at HotSpot JVM

INSIDE THE JAVA VIRTUAL MACHINE

Управление памятью и решение типичных проблем

Page 2: An internal look at HotSpot JVM

•Рассмотрение с точки зрения Java программиста

•Для других программистов и системных администраторов

•Внутренняя организация памяти JVM

О чем пойдет речь

Page 3: An internal look at HotSpot JVM

•Базовые сведения про Garbage Collector

•Исключительные ситуации OutOfMemory

–Почему они произошли

–Как их исправить

•Некоторые опции для тюнинга VM

•Вопросы и ответы

•Распределение памяти внутри Java machine

Содержание

Page 4: An internal look at HotSpot JVM

•Каждый процесс управляет памятью

•Способы управления памятью в процессеo C (malloc() и free())o C++(new и delete)o Java(new и GC)

•Запускается как отдельный процесс (память между процессами не разделяется)

Page 5: An internal look at HotSpot JVM

The JVM Process Heap

Page 6: An internal look at HotSpot JVM

Опции -Xmx, -Xms и –Xmn влияют только на размер «кучи» Java объектов, но не кучи самого Java процесса – непонимание этого факта может повлечь неправильное конфигурирование.(И как результат – ухудшение общей производительности )

Замечание

Page 7: An internal look at HotSpot JVM

Структура памяти JVM процесса(для 32бит)

Page 8: An internal look at HotSpot JVM

• java.lang.OutOfMemoryError: Java heap space

• java.lang.OutOfMemoryError: PermGen space

• java.lang.OutOfMemoryError: GC overhead limit exceeded

• java.lang.OutOfMemoryError: unable to create new native thread

Исключительные ситуации

Page 9: An internal look at HotSpot JVM

•Class data sharing (CDS)-Xshare:off

-Xshare:on

-Xshare:auto

•String pool•Метаданные об объектах

Permanent Generation

Page 10: An internal look at HotSpot JVM

•Библиотеки неявно генерирующие байткод

•Использование java.lang.reflect.Proxy

•Java Reflection API

•Serialization

•RMI

•Библиотеки явно генерирующие байткод

Переполнение PermGen

Page 11: An internal look at HotSpot JVM

•Память выделяется каждому созданному потоку в индивидуальное пользование.

•Хранится стек вызова методов, локальные переменные и параметры.

o Локальная переменная примитивного типа - все данные полностью хранятся на стеке.

o Объект - ссылка хранится на стеке, сам же объект уже создается в куче.

Java Thread Stack

Page 12: An internal look at HotSpot JVM

Размеры объектов в памяти(примитивные типы)

Java types bytes required

boolean1

byte

char2

short

int4

float

long8

double

Page 13: An internal look at HotSpot JVM

Размеры объектов в памяти

•Обычные объекты занимают минимум 8байт (служебная информация)

•Массивы занимают минимум 12 байт (8 как обычный объект и 4 - размер массива)

•Для каждого объект производится выравнивание по границе 8байт

Page 14: An internal look at HotSpot JVM

Размеры объектов в памяти

• Объект с полем типа char занимает 16 байт

Заголовок 8 байт + поле 1 байт + выравнивание 7 байт

• Объект с 8 полями типа char занимает 16 байт

Заголовок 8 байт + 8 полей по 1 байт

• Массив 10x10 int занимает 616 байт

Внешний массив - 52 (после паддинга 56 байт)+10 внутренних массивов по 56 байт(52 байта до выравнивания)

Page 15: An internal look at HotSpot JVM

• Механизм GC был впервые использован Джоном Маккарти в языке LISP (1959).

• В последствии часто применялся в функциональных и логических ЯП.

• С 1980-х годов технология сборки мусора стала использоваться и в директивных, и в объектных языках программирования

История Garbage Collector

Page 16: An internal look at HotSpot JVM

Сборщики мусора используют консервативные оценки, позволяющие определить, что в будущем объект гарантированно не будет использоваться.

Обычно критерием того, что объект ещё используется, является наличие ссылок на него. Если в системе нет больше ссылок на данный объект, то он больше не может быть использован программой и может быть удалён. Этот критерий используется большинством современных сборщиков мусора и называется ещё достижимостью объекта.

Немного теории

Page 17: An internal look at HotSpot JVM

• для каждого объекта есть флаг, указывающий, достижим ли этот объект из программы или нет;

• изначально все объекты, кроме корневых, помечаются как недостижимые;

• рекурсивно просматриваются и помечаются как достижимые объекты ещё не помеченные и до которых можно добраться из корневых объектов по ссылкам;

• те объекты, у которых флаг достижимости не был установлен, считаются недостижимыми.

Еще немного теории - Алгоритм «Mark and sweep»

Page 18: An internal look at HotSpot JVM

• Lock it downo Все объекты должны быть заблокированы,

что бы они не изменились в процессе сборки мусора

• Marko Пройтись по всем объектамo Отметить недостижимые как «мусор»

• Sweepo Удалить отмеченные объектыo Освободить память

Ближе к практике – Фазы GC

Page 19: An internal look at HotSpot JVM

• Stop The World• Incremental

o Отложить GC до окончания создания новых объектов

• Concurrent/Parallelo Выделение памяти происходит совместно с

GCo Очень сложные режимы блокировокo Поколения объектов

• CMS – Concurrent Mark and Sweep

Стратегии GC

Page 20: An internal look at HotSpot JVM

Стратегии GC

Page 21: An internal look at HotSpot JVM

Стратегии GC

Page 22: An internal look at HotSpot JVM

Поколения объектов в HotSpot

Page 23: An internal look at HotSpot JVM

1. Создается новый объект

2. Если Eden переполнен – минорная сборка

3. Выжившие объекты копируются в 1st survivor space

4. Следующий раз при заполнении Eden• Копируются из Eden в 2nd• Копируются из 1st в 2nd

5. Если 2nd заполнен и объекты все еще остаются в Eden или в 1sto Копируются в tenured

Как это работает

Page 24: An internal look at HotSpot JVM

Установки GC

-XX:+UseConcMarkSweepGC

-XX:+CMSIncrementalMode

-XX:+CMSIncrementalPacing

-XX:CMSIncrementalDutyCycleMin=0

-XX:+CMSIncrementalDutyCycle=10

-XX:+UseParNewGC

-XX:+CMSPermGenSweepingEnabled

Для анализа того, что происходит

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-XX:-TraceClassUnloading

Рекомендуемые опции GC

Page 25: An internal look at HotSpot JVM