JVM изнутри – организация памяти внутри процесса Java

    Наверное, все, работающие с Java, знают об управлении памяти на уровне, что для ее распределения используется сборщик мусора. Не все, к сожалению, знают, как именно этот сборщик (-и) работает, и как именно организована память внутри процесса Java.


    Из-за этого иногда делается неверный вывод, что memory leaks в Java не бывает, и слишком задумываться о памяти не надо. Так же часто идут холивары по поводу чрезмерного расхода памяти.
    Все описанное далее относится к Sun-овской реализации JVM (HotSpot), версий 5.0+, конкретные детали и алгоритмы могут различаться для разных версий.

    Итак, память процесса различается на heap (куча) и non-heap (стек) память, и состоит из 5 областей (memory pools, memory spaces):
    • Eden Space (heap) – в этой области выделятся память под все создаваемые из программы объекты. Большая часть объектов живет недолго (итераторы, временные объекты, используемые внутри методов и т.п.), и удаляются при выполнении сборок мусора это области памяти, не перемещаются в другие области памяти. Когда данная область заполняется (т.е. количество выделенной памяти в этой области превышает некоторый заданный процент), GC выполняет быструю (minor collection) сборку мусора. По сравнению с полной сборкой мусора она занимает мало времени, и затрагивает только эту область памяти — очищает от устаревших объектов Eden Space и перемещает выжившие объекты в следующую область.
    • Survivor Space (heap) – сюда перемещаются объекты из предыдущей, после того, как они пережили хотя бы одну сборку мусора. Время от времени долгоживущие объекты из этой области перемещаются в Tenured Space.
    • Tenured (Old) Generation (heap) — Здесь скапливаются долгоживущие объекты (крупные высокоуровневые объекты, синглтоны, менеджеры ресурсов и проч.). Когда заполняется эта область, выполняется полная сборка мусора (full, major collection), которая обрабатывает все созданные JVM объекты.
    • Permanent Generation (non-heap) – Здесь хранится метаинформация, используемая JVM (используемые классы, методы и т.п.). В частноси
    • Code Cache (non-heap) — эта область используется JVM, когда включена JIT-компиляция, в ней кешируется скомпилированный платформенно — зависимый код.

    Вот тут — blogs.sun.com/vmrobot/entry/основы_сборки_мусора_в_hotspot есть хорошее описание работы сборщиков мусора, перепечатывать не вижу смысла, советую всем интересующимся ознакомиться подробней по ссылке.

    Статья не моя. но камрада Zorkus'a, который хотел бы получить инвайт :).
    Поделиться публикацией

    Комментарии 15

      +11
      Вот это статья (вижу, что в посте есть ссылка) и вот статья, а вот презентация, а то, что выше — это не статья.
        0
        все относительно. не считаете статьей — сочтите за заметку :)
          +1
          я не к тому (: просто инвайт никто за эти шесть абзацев не даст. а ведь материал то интересный.
            0
            ну мы, по крайней мере, попытались :)
        –10
        За что у мну так мало кармы? ( Даже плюс хорошей статье не поставить…
          –9
          Иногда я людям поражаюсь…
          За обычную похвалу статьи срут в карму…
            +3
            За кармапопрошайничество, весьма плохо завуалированное.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Между прочим, в посте говорится не о сборщиках мусора вовсе, как таковых. А о распределении памяти внутри JVM, это несколько другая тема. Сравнивать со статьями по сборщикам мусора (выше) не совсем корректно.
            +1
            А меня вот всегда интересовал вопрос, почему бы JVM PermGen и CodeCache не сбрасывать на диск и расшарить для всех процессов JVM? То есть сделать некий кеш-репозиторий, который хранит данные о линковке классов и прекомпилированный код, идентифицируя классы, скажем, по файлу .jar-а из classpath. И сразу решится одна из основных проблем JVM — время запуска апликации. С этой же целью например в виндах и линуксе линкер кеширует информацию о библиотеках.
            У меня такое подозрение, что начиная с Java 5, она таскала с собой нечто подобное, но сделанное только для rt.jar. В директории JRE/bin при первом запуске создавался и пух на глазах один файл с расширением типа gst.
            0
            То-то мне по заголовку показалось, что это было у зоркуса… Аха, знакомы все морды лица.
              +1
              салам, коднетовец :)
                0
                Салам!

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое