Tại sao ConcảnHashMap ngăn chặn các khóa và giá trị null?

JavaDoc ConcurrentHashMapnói điều này:

Thích Hashtablenhưng không giống HashMap, lớp này không cho phép nullđược sử dụng làm khóa hoặc giá trị.

Câu hỏi của tôi: Tại sao?

Câu hỏi thứ 2: Tại sao không Hashtablecho phép null?

Tôi đã sử dụng rất nhiều HashMaps để lưu trữ dữ liệu. Nhưng khi thay đổi thành ConcurrentHashMaptôi đã gặp nhiều rắc rối vì NullPulumExceptions.

Từ tác giả của ConcurrentHashMapchính mình (Doug Lea) :

Lý do chính mà null không được phép trong Đồng thời (Đồng thờiHashMaps, Đồng thờiSkipListMaps) là sự mơ hồ có thể chỉ chấp nhận được trong các bản đồ không đồng thời không thể chấp nhận được. Cái chính là nếu map.get(key)trả về null, bạn không thể phát hiện xem nullkhóa có ánh xạ rõ ràng với khóa không được ánh xạ hay không. Trong bản đồ không đồng thời, bạn có thể kiểm tra điều này thông qua map.contains(key), nhưng trong bản đồ đồng thời, bản đồ có thể đã thay đổi giữa các cuộc gọi.

Tôi tin rằng, ít nhất là một phần, cho phép bạn kết hợp containsKeyvà thực hiện getmột cuộc gọi. Nếu bản đồ có thể giữ null, không có cách nào để biết liệu getcó trả về null hay không vì không có khóa cho giá trị đó hoặc chỉ vì giá trị là null.

Tại sao đó là một vấn đề? Bởi vì không có cách nào an toàn để làm điều đó cho mình. Lấy mã sau:

if (m.containsKey(k)) {
   return m.get(k);
} else {
   throw new KeyNotPresentException();
}

Vì mlà bản đồ đồng thời, khóa k có thể bị xóa giữa các cuộc gọi containsKeyvà getcuộc gọi, khiến đoạn mã này trả về một giá trị không bao giờ có trong bảng, thay vì mong muốn KeyNotPresentException.

Thông thường bạn sẽ giải quyết điều đó bằng cách đồng bộ hóa, nhưng với một bản đồ đồng thời tất nhiên sẽ không hoạt động. Do đó, chữ ký getphải thay đổi và cách duy nhất để làm điều đó theo cách tương thích ngược là ngăn người dùng chèn giá trị null vào vị trí đầu tiên và tiếp tục sử dụng nó như một trình giữ chỗ cho "không tìm thấy khóa".

Josh Bloch thiết kế HashMap; Doug Lea thiết kế ConcurrentHashMap. Tôi hy vọng đó không phải là bôi nhọ. Trên thực tế tôi nghĩ rằng vấn đề là null thường yêu cầu gói để null thực sự có thể thay thế cho chưa được khởi tạo. Nếu mã máy khách yêu cầu null thì nó có thể trả chi phí (nhỏ được thừa nhận) để tự đóng gói null.

Bạn không thể đồng bộ hóa trên null.

Chỉnh sửa: Đây không phải là chính xác tại sao trong trường hợp này. Ban đầu tôi nghĩ có điều gì đó thú vị đang xảy ra với việc khóa mọi thứ chống lại các bản cập nhật đồng thời hoặc sử dụng trình giám sát Object để phát hiện nếu có gì đó bị sửa đổi, nhưng khi kiểm tra mã nguồn, có vẻ như tôi đã nhầm - họ khóa bằng cách sử dụng "phân đoạn" dựa trên bitmask của hàm băm.

Trong trường hợp đó, tôi nghi ngờ họ đã làm điều đó để sao chép Hashtable và tôi nghi ngờ Hashtable đã làm điều đó bởi vì trong thế giới cơ sở dữ liệu quan hệ, null! = Null, vì vậy sử dụng null làm khóa không có ý nghĩa gì.

Đồng thờiHashMap là an toàn chủ đề. Tôi tin rằng việc không cho phép các khóa và giá trị null là một phần của việc đảm bảo rằng nó an toàn cho chuỗi.

Tôi đoán rằng đoạn mã sau của tài liệu API đưa ra một gợi ý hay: "Lớp này hoàn toàn tương thích với Hashtable trong các chương trình dựa trên sự an toàn của luồng nhưng không dựa trên chi tiết đồng bộ hóa của nó."

Có lẽ họ chỉ muốn làm ConcurrentHashMap hoàn toàn tương thích / hoán đổi cho nhau Hashtable. Và như Hashtablekhông cho phép các khóa và giá trị null ..

Tôi không nghĩ rằng không cho phép giá trị null là một lựa chọn chính xác. Trong nhiều trường hợp, chúng tôi muốn đặt một khóa có giá trị null vào bản đồ hiện tại. Tuy nhiên, bằng cách sử dụng ConcảnHashMap, chúng tôi không thể làm điều đó. Tôi đề nghị rằng phiên bản sắp tới của JDK có thể hỗ trợ điều đó.