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

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

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

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

Обычно все выделяемые вами невременные объекты управляются сборщиком мусора java. Хотя виртуальная машина неплохо справляется со сборкой мусора, в определенный момент виртуальная машина должна выполнить так называемую «полную сборку мусора». Полный сборщик мусора включает сканирование всей выделенной кучи, что означает, что паузы / замедления сборки мусора пропорциональны размеру кучи приложения. Так что не верьте никому, кто говорит вам: «Память - дешевая». Использование памяти Java снижает производительность. Кроме того, вы можете получить заметные паузы при размерах кучи> 1 Гб. Это может быть неприятно, если у вас есть какие-либо вещи, близкие к реальному времени, в кластере или сетке Java-процесс может перестать отвечать и быть удален из кластера.

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

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

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

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

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

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

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

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

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

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

Вкратце картина

в картинках

Детальное изображение

в картинках

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

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

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

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