Hoạt động đọc trong ConcurrentHashMap có đáng tin cậy về giá trị trả lại không?

Question

Tôi đọc trong một cuốn sách đọc trong ConcurrentHashmap không đảm bảo trạng thái được cập nhật gần đây nhất và đôi khi nó có thể mang lại giá trị gần hơn. Điều này có đúng không?

Tôi đã đọc javadocs của nó và nhiều blog có vẻ như nói khác (tức là nó chính xác).

Điều nào là đúng?

Answer 1

Đó là bản chất của sự tương tranh. Bất kỳ bộ sưu tập đồng thời nào cũng có thể cung cấp cho bạn giá trị cũ trong một trường nếu thao tác ghi hiện đang chờ xử lý không được hoàn tất một cách an toàn. Đó là trong mọi trường hợp những gì bạn phải mong đợi. Các bộ sưu tập được thực hiện cho đồng thời sẽ không cung cấp cho bạn các giá trị bị hỏng hoặc bị hỏng nếu bạn truy cập chúng từ nhiều luồng, nhưng chúng có thể cung cấp cho bạn các giá trị cũ, nếu viết không được thực hiện.

Answer 2

Từ ConcurrentHashMap javadoc:

hoạt động Retrieval (bao gồm get) thường không chặn, vì vậy có thể chồng chéo với các hoạt động cập nhật (kể cả đặt và gỡ bỏ). Retrievals phản ánh kết quả của các hoạt động cập nhật mới nhất được hoàn thành khi họ khởi động. Đối với các phép toán tổng hợp như putAll và rõ ràng, các lần truy xuất đồng thời có thể phản ánh việc chèn hoặc loại bỏ chỉ một số mục nhập. Tương tự, các Iterator và Enumerations trả về các phần tử phản ánh trạng thái của bảng băm tại một số điểm tại hoặc từ khi tạo ra vòng lặp/liệt kê. Họ không ném ConcurrentModificationException. Tuy nhiên, các trình vòng lặp được thiết kế chỉ được sử dụng bởi một luồng tại một thời điểm.

Một điểm cần làm nổi bật là Iterator sẽ không phản ánh các thay đổi được thực hiện sau khi Iterator được tạo. Vì vậy, nếu bạn cần lặp lại các giá trị của bản đồ, trong khi các chủ đề khác đang thêm vào bản đồ và bạn quan tâm đến trạng thái hiện tại nhất của bản đồ, thì việc sử dụng ConcurrentHashMap có thể không thực hiện được bản đồ mà bạn cần.

Answer 3

Bằng trực giác, một ConcurrentHashMap sẽ hoạt động giống như một tập các biến dễ bay hơi; các khóa bản đồ là các địa chỉ biến. get(key) và put(key, value) sẽ hoạt động như đọc và ghi dễ bay hơi.

Điều đó không được nêu rõ trong tài liệu. Tuy nhiên, tôi tin chắc rằng đó là trường hợp. Nếu không, sẽ có rất nhiều hành vi bất ngờ, đáng ngạc nhiên làm suy yếu logic ứng dụng. Tôi không nghĩ Doug Lea sẽ làm điều đó với chúng tôi. Để chắc chắn, ai đó vui lòng hỏi anh ấy theo số concurrency-interest danh sách gửi thư.

Giả sử nó không tuân theo ngữ nghĩa không ổn định, chúng ta có thể lý do dựa trên Java Memory Model -

Tất cả biến động đọc và viết thành một tổng số thứ tự duy nhất. Điều này có thể được coi là một dòng thời gian giả, nơi đọc/ghi là điểm trên đó.

Đọc dễ bay hơi thấy ghi dễ bay hơi trước ngay lập tức và chỉ thấy ghi đó. "Trước" ở đây là theo dòng thời gian giả.

Dòng thời gian giả có thể khác với dòng thời gian "thực". Tuy nhiên, về lý thuyết, một ghi dễ bay hơi không thể bị trì hoãn vô hạn trên dòng thời gian giả. Và, trong pracitce, hai dòng thời gian là khá gần.

Vì vậy, chúng tôi có thể chắc chắn rằng, một ghi dễ bay hơi sẽ trở thành hiển thị "rất nhanh" để đọc.