Việc thực hiện tiêu chuẩn là yếu và sử dụng nó dẫn đến va chạm không cần thiết. Hãy tưởng tượng một
class ListPair {
List<Integer> first;
List<Integer> second;
ListPair(List<Integer> first, List<Integer> second) {
this.first = first;
this.second = second;
}
public int hashCode() {
return Objects.hashCode(first, second);
}
...
}
Hiện nay,
new ListPair(List.of(a), List.of(b, c))
và
new ListPair(List.of(b), List.of(a, c))
có cùng hashCode, cụ thể 31*(a+b) + clà số nhân được sử dụng choList.hashCode được tái sử dụng ở đây. Rõ ràng, va chạm là không thể tránh khỏi, nhưng tạo ra va chạm không cần thiết chỉ là ... không cần thiết.
Không có gì đáng kể thông minh về việc sử dụng 31. Số nhân phải là số lẻ để tránh mất thông tin (bất kỳ số nhân chẵn nào cũng mất ít nhất là bit đáng kể nhất, bội số của bốn mất hai, v.v.). Bất kỳ số nhân lẻ đều có thể sử dụng. Số nhân nhỏ có thể dẫn đến tính toán nhanh hơn (JIT có thể sử dụng dịch chuyển và bổ sung), nhưng với điều kiện nhân có độ trễ chỉ ba chu kỳ trên Intel / AMD hiện đại, điều này hầu như không thành vấn đề. Số nhân nhỏ cũng dẫn đến xung đột nhiều hơn cho đầu vào nhỏ, đôi khi có thể là một vấn đề.
Sử dụng một số nguyên tố là vô nghĩa vì các số nguyên tố không có ý nghĩa trong vòng Z / (2 ** 32).
Vì vậy, tôi khuyên bạn nên sử dụng một số lẻ lớn được chọn ngẫu nhiên (thoải mái lấy số nguyên tố). Vì CPU i86 / amd64 có thể sử dụng một lệnh ngắn hơn cho các toán hạng phù hợp trong một byte đã ký, có một lợi thế tốc độ nhỏ cho các số nhân như 109. Để giảm thiểu va chạm, hãy lấy thứ gì đó như 0x58a54cf5.
Sử dụng các số nhân khác nhau ở những nơi khác nhau là hữu ích, nhưng có lẽ không đủ để biện minh cho công việc bổ sung.
Objects.hashCode(collection)nên là một giải pháp hoàn hảo!