2009-09-10 3 views
2

Я использую ehcache (через плагин Grails). Метод, который добавляет объекты в кэш требует ключей, чтобы быть сериализациями, так что типичное использование будет:генерация ключа кэша

def key = 22 
def someObject = new Object(); 
cacheService.cache(key, true, someObject) 

(булевы пары указуют на то, должен ли объект быть добавлен к распределенной или локальной кэш-памяти)

Мой вопрос, как я должен идти о генерации ключей от объектов значений, таких как:

class Person implements Serializable { 
    String firstName 
    String lastName 
    Integer age 
} 

Один подход должен был бы обеспечить хэш-код() и Equals() методы и использовать хэш-код в качестве ключа. В этом случае мне не нужно было бы, чтобы класс Person реализовал Serializable.

В качестве альтернативы я мог бы просто использовать сам объект Person в качестве ключа. Похоже, мне все равно нужно предоставить методы equals и hashCode, но также потребуется реализовать Serializable. Однако, как представляется, вероятность столкновения с меньшим шансом при использовании этого подхода, поскольку Личность может быть равна только одному экземпляру Person.

Я предполагаю, что ehcache использует метод equals() ключа, чтобы определить, существует ли этот ключ в кеше, является ли это предположение правильным?

Является ли один из подходов, описанных выше, по существу лучше других, или есть другой подход, который я не рассматривал?

Спасибо, Дон

ответ

1

Вашего hashkey вопрос в основном ортогональный к сериализуемому вопросу. В ответ на hashkey я бы использовал Apache Commons HashCodeBuilder. Он делает весь тяжелый подъем для вас. Аналогично равным, используйте EqualsBuilder.

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

Я бы не использовал объект Person в качестве ключа, так как это вызовет его equals(), чтобы проверить сопоставления клавиш, что, вероятно, медленнее, чем сравнение целого hashcode.

+0

Но есть и меньше шансов на столкновение, если я использую Личность, потому что это может быть равно только другим экземплярам Лица –

+0

Один, беспокоясь о том, что столкновение является pr-eoptimization. Помните правила оптимизации :). 1) Не оптимизируйте, 2) Не оптимизируйте. Во-вторых, вероятность того, что объект с двумя людьми создает один и тот же хеш, довольно мал. Три, если вы собираетесь использовать Person в качестве своего ключа, тогда вы должны реализовать equals() hashcode() в любом случае, если вы не полагаетесь на фактическое равенство объекта (==) для поиска, а не для эквивалентности (equals()). –

+3

Столкновение = повреждение кеша. Коррупция = очень плохо. Очень плохо = не оптимизация. Я настолько ошеломлен, что многие люди, работающие с ehcache (и особенно проектирование абстракции Spring cache), по-видимому, забыли, что 'hashCode (obj1) = hashCode (obj2) = \ => obj1 = obj2'. –

Смежные вопросы