Да вроде варианты очевидны:
1. ОЗУ на сервере не хватает и нет супер жестких требований по производительности - РСУБД
2. ОЗУ на сервере не хватает, но производителность РСУБД не устраивает - подбираем базу под свои экзотические потребности, смотрим всякие Key-value, NoSQL и маскирующиеся под РСУБД, но модные внутри (а-ля тарантул)
3. Ограничений по ОЗУ нет, требований по персистенсу нет, производительности модных СУБД не хватает, а просто приложению сложно ворочать много объектов в хипе - берем либу для off-heap cache
4. Ограничений по ОЗУ нет, но нужен персистенс и супер производительность - берем IMDG решение

Leonid Kudryavtsevjust_vladimir....
3. Ограничений по ОЗУ нет, требований по персистенсу нет, производительности модных СУБД не хватает, а просто приложению сложно ворочать много объектов в хипе - берем либу для off-heap cache
....

При этом аккуратно смотрем, кто из студентов делал эту мега-либу. Если есть фотка и девочка-студент грудастая - можно за ней либу потестить.
Если фотки нет, то оно Вам надо, за студентами их студенческие поделки тестить?

Не видел ни одной нормальной либы для off-heap. Нормальные (более-менее) есть, но они все для специфических задачь. Если value для Map'а могут быть разного размера, то удаление данных из off-heap, уже не тревиальная задача (фрагментация). Насколько стоит замусоривать память операционной системы и что этим при активной работе в режиме 24x7 можно достигнуть, лично мне не очень понятно. Но я бы на реальных PROD серверах эксперементировал бы с опаской.

IMHO & AFAIK

Если такое тащить в проект, то только понимая, что притащенный copy-past'ом из I-net'а код самому же придется и поддерживать. А тогда, проще уж свою либу написать (методом Copy-Past'а) заточенную под свои данные и паттерн нагрузки.
Ну вот, например, вроде Паньгин не тянет на грудастую девочку студентку, но думаю, что если прижмет и задача будет требовать off heap кэша, то его либой можно уж и воспользоваться https://github.com/odnoklassniki/one-nio, но да, понятно, что на свой страх и риск, но если надо, то что уж делать.

Leonid KudryavtsevLeonid Kudryavtsev...Нормальные (более-менее) есть, но они все для специфических задачь....


https://github.com/odnoklassniki/one-nio,

Дело же не в либе, а что бы ей еще и правильно пользоваться и по назначению.

Например глянул на класс allocator. Если, не дай бог, выделять маленькими блоками, то смысла никакого. Т.к. при allocate создается еще и служебные объекты в Heap'е. Т.ч. данные запихиваемые в OffHeap нужно как-то объединять в достаточно большие блоки. Что, для произвольных данных, уже не очень тревиально.

LongLongHashMap все хранит в OffHeap:
1) AFAIK а разница в скорости доступа heap vs off heap, как бы не маленькая (должно быть разы, вплодь до порядков. Но не тестил!).
2) Маппа хранится одним куском. Что для ОЧЕНЬ большой маппы, плохо. Т.к. фрагментацию памяти в ОС никто не отменял. (на данном форуме был топик в подфоруме Delphi, что free памяти навалом, а массив не выделяется)

LongObjectHashMap values вроде хранить в обычном heap'е. Экономить на keys (с учетом потери скорости на offheap) смысла вообще не вижу.

Это с ходу. Могу ошибаться.
На всякий случай уточню, что мы ведь оба понимаем, что если вдруг дело дошло до того, что мы стали задумываться об off heap кэшах, то у нас уже проект не совсем уж на коленке деланный и в команде не 1.5 студента, так ведь?