Можно ли пометить java-объекты, которые нельзя -собирать с точки зрения gc, чтобы сэкономить время развертки gc -?

Можно ли пометить java-объекты, которые нельзя -собирать с точки зрения gc, чтобы сэкономить время развертки gc -?

Что-то вродеhttp://wwwasd.web.cern.ch/wwwasd/lhc++/Objectivity/V5.2/Java/guide/jgdStorage.fm.htmlи конкретно не -мусор -коллекционные контейнеры есть (не -мусор -сбор? ).

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

Таким образом, я мог бы разделить свои данные по своему усмотрению на бесконечные -живые и нормальные -живые объекты, и, надеюсь, GC будет достаточно быстрым, потому что нормальные объекты не живут так долго и составляют меньшие суммы.

Есть несколько обходных путей для этой проблемы, например Apache DirectMemory и коммерческая Terracotta BigMemory (http://terracotta.org/products/bigmemory)., но нативное решение java -было бы лучше (Я имею в виду бесплатное и, вероятно, более надежное? ). Также я хочу избежать накладных расходов на сериализацию, что означает, что это должно происходить в одном и том же jvm. Насколько я понимаю, DirectMemory и BigMemory работают в основном вне кучи , что означает, что объекты должны быть сериализованы/десериализованы в/из памяти вне jvm.Простая маркировка областей, отличных от -gc, внутри jvm кажется лучшим решением. Использование файлов для кеша также не вариант, он имеет те же непозволительные накладные расходы на сериализацию/десериализацию -, что и использование сервера высокой доступности с большим количеством данных, используемых в случайном (человеческом )порядке и с низкой задержкой.