Ответ 1

Хранилище на куче относится к объектам, которые будут присутствовать в куче Java (а также при условии GC). С другой стороны, хранилище с кучей относится к (сериализованным) объектам, которые управляются EHCache, но хранятся вне кучи (а также не подлежат GC). Поскольку хранилище с кучей продолжает управляться в памяти, оно немного медленнее, чем хранилище на куче, но все же быстрее, чем дисковое хранилище.

Внутренние детали, связанные с управлением и использованием хранилища вне кучи, не очень заметны в ссылке, размещенной в вопросе, поэтому было бы разумно проверить детали Terracotta BigMemory, который используется для управления хранилищем вне диска. BigMemory (хранилище с кучей) должно использоваться, чтобы избежать накладных расходов на GC на куче, которая составляет несколько мегабайт или гигабайт. BigMemory использует адресное пространство памяти процесса JVM через direct ByteBuffers, которые не подлежат GC, в отличие от других родных объектов Java.

Ответ 2

from http://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff

Что такое куча разгрузки?

Обычно все не временные объекты, которые вы назначаете, управляются сборщиком мусора java. Хотя VM делает достойную работу по сбору мусора, в определенный момент VM должна сделать так называемый "Полный GC". Полный GC включает сканирование всей выделенной кучи, что означает, что паузы/замедления GC пропорциональны размеру кучи приложений. Поэтому не доверяйте никому, говорящему вам, что "Память дешевая". В java-памяти потребление ухудшает производительность. Кроме того, вы можете получить заметные паузы, используя размеры кучи > 1 Гб. Это может быть неприятно, если у вас есть вещи почти в реальном времени, в кластере или сетке процесс java может не отвечать на запросы и отбрасываться из кластера.

Однако сегодняшние серверные приложения (часто построенные на основе блатных фреймворков;-)) легко требуют кучи далеко за пределами 4Gb.

Одним из решений этих требований к памяти является "выгрузка" частей объектов в кучу не-java (непосредственно выделенную из ОС). К счастью, java.nio предоставляет классы для прямого выделения/чтения и записи "неуправляемых" фрагментов памяти (даже с отображением памяти).

Таким образом, можно выделить большие количества "неуправляемой" памяти и использовать ее для сохранения объектов. Чтобы сохранить произвольные объекты в неуправляемой памяти, наиболее жизнеспособным решением является использование сериализации. Это означает, что приложение сериализует объекты в память offheap, позже объект может быть прочитан с помощью десериализации.

Размер кучи, управляемый виртуальной машиной Java, может быть небольшой, поэтому GC-паузы находятся в миллисекундах, все довольны работой.

Понятно, что производительность такого буфера с кучей зависит в основном от производительности реализации сериализации. Хорошие новости: по какой-то причине сериализация FST довольно быстро: -).

Примеры сценариев использования:

• Кэш сеанса в серверном приложении. Используйте файл с отображением памяти для хранения гигабайт (неактивных) сеансов пользователя. Как только пользователь входит в ваше приложение, вы можете быстро получить доступ к данным, связанным с пользователем, без необходимости иметь дело с базой данных.
• Кэширование вычислительных результатов (запросы, html-страницы,..) (применимо только в том случае, если вычисление выполняется медленнее десериализации объекта результата из c).
• очень простое и быстрое сохранение с использованием файлов с отображением памяти

Изменить: для некоторых сценариев можно выбрать более сложные алгоритмы сбора мусора, такие как ConcurrentMarkAndSweep или G1, чтобы поддерживать большие кучи (но у этого также есть свои пределы за пределами 16 ГБ). Существует также коммерческая JVM с улучшенным "безрезультатным" GC (Azul).

Ответ 3

Куча - это место в памяти, в котором живут ваши динамически распределенные объекты. Если вы использовали new, то это в куче. Это в отличие от пространства стека, в котором живет функциональный стек. Если у вас есть локальная переменная, то эта ссылка находится в стеке. Куча Java подлежит сборке мусора, и объекты могут использоваться напрямую.

Накопительное хранилище EHCache берет ваш обычный объект из кучи, сериализует его и хранит в виде байтов в блоке памяти, который управляет EHCache. Это похоже на сохранение его на диске, но он все еще в ОЗУ. В этом состоянии объекты непосредственно не используются, их нужно сначала десериализовать. Также не подлежат сборке мусора.

Ответ 4

Короче

pic credits

Подробное изображение

pic credits

Ответ 5

Не 100%; однако это звучит так: куча - это объект или набор выделенного пространства (в ОЗУ), встроенный в функциональность кода либо самой Java, либо более вероятная функциональность от самого ehcache, а у раковины без кучи есть собственная система как Что ж; однако, похоже, что это на одну величину медленнее, поскольку она не такая организованная, то есть она не может использовать кучу (имея в виду один длинный набор пространства RAM) и вместо этого использует разные адресные пространства, что делает ее несколько менее эффективной.

Тогда, конечно, следующий уровень ниже - это пространство жесткого диска.

Я не использую ehcache, поэтому вы можете не хотеть доверять мне, но это то, что я собрал из своей документации.

Ответ 6

JVM ничего не знает о памяти вне кучи. Ehcache реализует кеш-диск на диске, а также кеш в памяти.