String.hashCode () портативен через VMs, JDKs и OSs?
Если для ответа требуется, чтобы вы сделали цикл самостоятельно, то что-то вроде этого должно работать нормально (один из нескольких способов сделать это, но есть O(n)):
public void addBefore(int x) {
if(length + 1 >= a.length){
int[] b = new int[a.length*2];
b[0] = x;
for (int i = 0; i < length; i++) {
b[i + 1] = a[i];
}
a = b;
} else {
for (int i = length; i >= 0 ; i--) {
a[i + 1] = a[i];
}
a[0] = x;
}
length++;
}
Я заметил, что это началось запускать «тест скорости» - не уверен, насколько полезен такой тест, поскольку он будет основан на производительности процессора, а не на тестировании сложности алгоритма.
5 ответов
Нет. Из http://tecfa.unige.ch/guides/java/langspec-1.0/javalang.doc1.html:
Общий контракт хэш-кода следующие:
- Каждый раз, когда это вызывается на тот же объект несколько раз во время выполнения JAVA-приложения, хэш-код должен последовательно возвращать то же целое число. Целое число может быть положительным, отрицательным, или нуль. Это целое число не должно, однако, оставаться последовательным от одного JAVA-приложения до другого, или от одного выполнения приложения к другому выполнению того же приложения. [...]
Я хотел бы добавить, что можно переопределить хэш-код () (не забывайте, равняется (), если Вы делаете это) удостоверяться, что Ваши бизнес-объекты возвращают тот же хэш-код везде. Те объекты будут затем, по крайней мере, иметь предсказуемый хэш-код.
Согласно документам: хэш-код для Строкового объекта вычисляется как
s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
Я не уверен, является ли это формальной спецификацией или просто реализацией Sun. По крайней мере это должно быть то же на всем существующем Sun VMs, независимо от платформной или операционной системы.
Нет. Хеш-алгоритмы не гарантируются, если иначе не указано. Так, например, десериализация структур хеша должна повторно вычислить хэш-коды, и эти значения не должны быть сохранены в сериализированной форме.
Это зависит от типа:
- Если у Вас будет тип, который не переопределил хэш-код () затем, то он, вероятно, возвратит другой хэш-код () каждый раз, когда Вы запускаете программу.
- Если у Вас есть тип, который переопределяет хэш-код (), но не документирует, как он вычисляется, совершенно законно для объекта с теми же данными возвратить другой хеш на каждом выполнении, пока он возвращает тот же хеш для повторных вызовов в рамках того же выполнения.
- Если у Вас есть тип, который переопределяет хэш-код () зарегистрированным способом, т.е. алгоритм является частью зарегистрированного поведения, то Вы, вероятно, в безопасности. (java.lang. Строка документирует это, например.) Однако я все еще избегал бы полагаться на это на общем принципе, лично.
Просто назидательная история от мира.NET: я видел по крайней мере несколько человек в мире боли посредством использования результата строки. GetHashCode () как их хэш пароля в базе данных. Алгоритм, измененный между.NET 1.1 и 2.0, и внезапно все хеши, является "неправильным". (Jeffrey Richter документирует почти идентичный случай в CLR через C#.), Когда хеш действительно должен быть сохранен, я предпочел бы, чтобы это было вычислено способом, который, как всегда гарантируют, будет стабилен - например, MD5 или пользовательский интерфейс, реализованный Вашими типами с гарантией устойчивости.