Механизм тайм-аута для Hashtable

Question

У меня есть хеш-таблица, которая в условиях интенсивного трафика. Я хочу добавить механизм тайм-аута в хеш-таблицу, удалить слишком старые записи. Мои опасения - он должен быть легким - Операция удаления не имеет критического времени. Я имею в виду (время ожидания составляет 1 час), операция удаления может быть через 1 час или 1 час 15 минут. Нет проблем.

Мое мнение таково, Я создаю большой массив (в виде кольцевого буфера), в котором хранятся время и ключ хеш-таблицы, При добавлении в хеш-таблицу, используя индекс массива, найдите следующий слот во время размещения массива, если слот массива пуст, введите время вставки и ключ HT, если слот массива не пустой, сравните время вставки для истекшего времени ожидания.
если истекло время ожидания, удалите из Hashtable (если еще не удалено) тайм-аут не наступил, увеличивайте индекс до тех пор, пока не найдете пустой слот или слот массива с временной шкалой. При удалении из хеш-таблицы нет работы с большим массивом.

Вскоре, для каждой операции добавления в Hashtable, можно удалить 1 элемент с временным графиком из hashtable или ничего не делать.

Какое ваше самое элегантное и легкое решение?

Спасибо за помощь,

Answer 1

Мой подход будет использовать Гуава MapMaker:

ConcurrentMap<String, MyValue> graphs = new MapMaker()
   .maximumSize(100)
   .expireAfterWrite(1, TimeUnit.HOURS)
   .makeComputingMap(
       new Function<String, MyValue>() {
         public MyValue apply(String string) {
           return calculateMyValue(string);
         }
       });

Это может быть точно то, что выописываю, но скорее всего, это достаточно близко.И его гораздо проще создать (плюс он использует хорошо протестированную базу кода).

Обратите внимание, что вы можете настроить поведение результирующего Map, вызывая различные методы перед вызовом make*().

Answer 2

Вы должны рассмотреть возможность использования LinkedHashMap или, возможно, WeakHashMap.

В первом случае для установки имеется конструктор порядок итераций его элементов до порядка последнего доступа;это делает тривиальным удаление слишком старых элементов.И его removeEldestEntry метод может быть переопределен для определения вашей собственной политики, когда автоматически удалять самую старую запись после вставки новой.

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

Answer 3

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

Answer 4

Я думаю, что гораздо более простым решением является использование LRUMap из Apache Commons Collections . Конечно, вы можете написать свои собственные структуры данных, если вам это нравится или вы хотите учиться, но эта проблема настолько распространена, что существует множество готовых решений. (Я уверен, что другие укажут вам и на другие реализации, через некоторое время ваша проблема будет выбирать правильную из них:))