Разница между "on-heap" и " off-heap"
Ehcache переговоры о на кучи и кучи памяти. В чем разница? Какие Арги JVM используются для их настройки?
6 ответов
хранилище на куче ссылается на объекты, которые будут присутствовать в куче Java (а также подлежат GC). С другой стороны, хранилище вне кучи ссылается на (сериализованные) объекты, которые управляются EHCache, но хранятся вне кучи (а также не подлежат GC). Поскольку хранилище вне кучи продолжает управляться в памяти, оно немного медленнее, чем хранилище в куче, но все же быстрее, чем хранилище дисков.
внутренние детали, связанные с управлением и использованием вне кучи магазин не очень очевиден в ссылке, размещенной в вопросе, поэтому было бы разумно проверить детали Терракотовый BigMemory, который используется для управления хранилищем вне диска. BigMemory (хранилище вне кучи) должно использоваться, чтобы избежать накладных расходов GC в куче, которая составляет несколько мегабайт или гигабайт. BigMemory использует адресное пространство памяти процесса JVM через прямой ByteBuffers которые не подлежат GC в отличие от других собственных объектов Java.
от http://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff
Что такое выгрузка кучи ?
обычно все временные объекты, которые вы выделяете, управляются сборщиком мусора java. Хотя виртуальная машина выполняет приличную работу по сбору мусора, в определенный момент виртуальная машина должна сделать так называемый "полный GC". Полный GC включает сканирование полной выделенной кучи, что означает, что паузы/замедления GC пропорциональны размер кучи приложений. Поэтому не доверяйте никому, кто говорит вам: "память дешева". В java потребление памяти снижает производительность. Кроме того, вы можете получить заметные паузы, используя размеры кучи > 1 Гб. Это может быть неприятно, если у вас есть какие-либо вещи, близкие к реальному времени, в кластере или сетке процесс java может перестать отвечать и быть удален из кластера.
однако сегодняшние серверные приложения (часто построенные поверх раздутых фреймворков ; -)) легко требуют кучи далеко за пределами 4гб.
одним из решений этих требований к памяти является "разгрузка" частей объектов в кучу, отличную от java (непосредственно выделенную из ОС). К счастью, Ява.nio предоставляет классы для прямого выделения / чтения и записи "неуправляемых" кусков памяти (даже сопоставленных с памятью файлов).
таким образом, можно выделить большое количество "неуправляемой" памяти и использовать ее для сохранения объектов. Чтобы сохранить произвольные объекты в неуправляемой памяти, наиболее жизнеспособным решением является использование Сериализация. Это означает, что приложение сериализует объекты в память offheap, позже объект можно прочитать с помощью десериализации.
размер кучи, управляемый Java VM, может быть небольшим, поэтому паузы GC находятся в миллисах, все счастливы, работа выполнена.
понятно, что производительность такого буфера кучи зависит в основном от производительности реализации сериализации. Хорошие новости: по какой-то причине FST-сериализация происходит довольно быстро :-).
пример использования:
- кэш сеанса в серверном приложении. Используйте сопоставленный файл памяти для хранения гигабайт (неактивных) сеансов пользователя. После входа пользователя в приложение можно быстро получить доступ к данным, связанным с пользователем, без необходимости работать с базой данных.
- кэширование результатов вычислений (запросы, html-страницы,..) (только если расчет идет медленнее, чем десериализации объекта result ОФК).
- очень простой и быстрый persistance с помощью памяти сопоставленных файлов
Edit: для некоторых сценариев можно выбрать более сложные алгоритмы сбора мусора, такие как ConcurrentMarkAndSweep или G1 для поддержки больших куч (но это также имеет свои пределы за пределами кучи 16GB). Существует также коммерческая СПМ с улучшенным "беспаузным" GC (Azul).
куча-это место в памяти, где живут динамически выделенные объекты. Если вы использовали new тогда это на куче. Это в отличие от пространства стека, где живет стек функций. Если у вас есть локальная переменная, то эта ссылка находится в стеке.
Куча Java подлежит сбору мусора, и объекты могут использоваться напрямую.
хранилище Ehcache вне кучи удаляет ваш обычный объект из кучи, сериализует его и сохраняет его в виде байтов в куске памяти что EHCache управляет. Это как хранить его на диске, но он все еще в ОЗУ. Объекты не используются непосредственно в этом состоянии, они должны быть десериализованы в первую очередь. Также не подлежит сбору мусора.
не 100%, но похоже на кучу-это объект или набор выделенную память (ОЗУ), встроенный в функциональности кода или Java сама или, что более вероятно функциональность ehcache от себя и от кучи Овна есть собственную систему; впрочем, похоже, это одна величина медленнее, так как он не организован, то есть он может не использовать кучу (что означает один длинный набор пространства оперативной памяти), а вместо этого используют разные адресные пространства, вероятно, делает его немного меньше эффективный.
тогда, конечно, следующий уровень ниже-это само пространство жесткого диска.
Я не использую ehcache, поэтому вы можете не доверять мне, но это то, что я собрал из своей документации.