Дизайн структуры данных кэша

Question

Чтобы объяснить домен ...

У меня есть куча (1 000 000) элементов, каждый из 12 типов возможных типов (TypeA, TypeB ... TypeK). Есть 3 неизменяемых класса, а именно,ItemKey (чтобы уникально идентифицировать элемент), ItemTypeKey (чтобы уникально идентифицировать тип) и ItemType (содержащий данные типа, включая ItemTypeKey)

Передо мной находится кеш, который хранит эти данные в двух структурах данных...

ConcurrentHashMap<ItemKey, ItemTypeKey>
ConcurrentHashMap<ItemTypeKey, ItemType>

Я бы реализовал это просто как ConcurrentHashMap<ItemKey, ItemType> Объем памяти в этом случае был бы минимальным, так как кеш в любом случае хранит только ссылки.

Есть ли какое-то конкретное преимущество в разделении кеша, которого я не вижу?Любые альтернативные проекты структуры данных тоже приветствуются

Answer 1

Ну, вам когда-нибудь нужно искать, используя ItemTypeKey в качестве элемента поиска?Это единственная причина, по которой вы так поступите.

Другая потенциальная проблема с примером, который вы демонстрируете, - это потенциальные условия гонки.Эти две карты - ConcurrentHashMaps, что подразумевает, что кто-то планирует использовать это в многопоточных ситуациях.Если нет синхронизированной блокировки, связанной с использованием обеих карт (в этом случае нормальный HashMap будет в порядке), тогда могут быть краткие несоответствия, когда элементы добавляются / удаляются, когда одна карта обновлена, а другая - нет.Это может не иметь значения - зависит от программы.

Это длинный бессмысленный способ сказать: «Да, если ItemKey неизменен, и вам не нужен ItemTypeKey для поиска (по крайней мере, часто), ваш рефакторинг».звучит хорошо для меня ":)