Действительно ли хорошая практика поставить дату в hashcode?

Question

У меня есть несколько записей с похожим идентификатором. База данных очень много. Такой уникальный столбец нет. Созданный столбец даты используется для хранения метки времени создания строки в базе данных. Мне нужно сохранить запись на java-карте для выполнения какой-либо операции. Для любых изменений в записи создается новая запись. Я не хочу держать все поля внутри hashcode и равно. Потому что, я не уверен, какой столбец изменен против id.

Во-первых, я пытаюсь использовать генератор случайных чисел для уникального hashcode. Оно работает.

Во-вторых, я решил поместить созданный столбец даты в hashcode. Он также работает.

Есть ли недостаток, чтобы поставить дату в hashcode?

Answer 1

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

Это может включать в себя дату или любое поле вам нравится.

BTW Я предпочитаю использовать long вместо Date, потому что я могу сделать его неизменным, и он немного быстрее.

Если вы собираетесь использовать метку времени в качестве идентификатора, вы можете убедиться, что он уникален, нажав на Milli-секунд (или микро секунд, если вы можете хранить такую ​​метку времени)

private static final AtomicLong TIME_STAMP = new AtomicLong(); 
// can have up to 1000 ids per second. 
public static long getUniqueMillis() { 
    long now = System.currentTimeMillis(); 
    while (true) { 
     long last = TIME_STAMP.get(); 
     if (now <= last) 
      now = last + 1; 
     if (TIME_STAMP.compareAndSet(last, now)) 
      return now; 
    } 
} 

или

private static final AtomicLong TIME_STAMP = new AtomicLong(); 
// can have up to 1000000 ids per second. 
public static long getUniqueMicros() { 
    long now = System.currentTimeMillis() * 1000; 
    while (true) { 
     long last = TIME_STAMP.get(); 
     if (now <= last) 
      now = last + 1; 
     if (TIME_STAMP.compareAndSet(last, now)) 
      return now; 
    } 
} 

Answer 2

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

Answer 3

Прежде всего, вам нужно только equals() и hashCode() методы, если вы используете эти объекты как ключи в HashMap.

Должно быть какое-то понятие, которое определяет, что означает, что эти объекты «равны» друг другу. Вы должны реализовать свои методы equals() и hashCode() таким образом, чтобы это понятие отражалось.

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

Нет никакой проблемы с использованием даты как части вычисления hashCode(), если это один из критериев, который определяет, являются ли два объекта равными друг другу.