Có an toàn để nhận các giá trị từ java.util.HashMap từ nhiều luồng (không sửa đổi) không?

Có một trường hợp bản đồ sẽ được xây dựng và một khi nó được khởi tạo, nó sẽ không bao giờ được sửa đổi nữa. Tuy nhiên, nó sẽ được truy cập (chỉ thông qua get (key)) từ nhiều luồng. Có an toàn khi sử dụng java.util.HashMaptheo cách này?

(Hiện nay, tôi đang hạnh phúc bằng cách sử dụng java.util.concurrent.ConcurrentHashMap, và không cần phải đo để cải thiện hiệu suất, nhưng tôi chỉ đơn giản là tò mò nếu một đơn giản HashMapsẽ đủ. Do đó, câu hỏi này là không "Cái nào tôi nên sử dụng?" Cũng không phải là một câu hỏi hiệu suất. Thay vào đó, câu hỏi là "Liệu nó có an toàn không?")

Thành ngữ của bạn là an toàn nếu và chỉ khi tham chiếu đến HashMapđược công bố an toàn . Thay vì bất cứ điều gì liên quan đến nội bộ của HashMapchính nó, ấn phẩm an toàn liên quan đến cách chủ đề xây dựng làm cho tham chiếu đến bản đồ hiển thị cho các chủ đề khác.

Về cơ bản, cuộc đua duy nhất có thể ở đây là giữa việc xây dựng HashMapvà bất kỳ chủ đề đọc nào có thể truy cập nó trước khi nó được xây dựng đầy đủ. Hầu hết các cuộc thảo luận là về những gì xảy ra với trạng thái của đối tượng bản đồ, nhưng điều này không liên quan vì bạn không bao giờ sửa đổi nó - vì vậy phần thú vị duy nhất là cách HashMaptham chiếu được xuất bản.

Ví dụ: hãy tưởng tượng bạn xuất bản bản đồ như thế này:

class SomeClass {
   public static HashMap<Object, Object> MAP;

   public synchronized static setMap(HashMap<Object, Object> m) {
     MAP = m;
   }
}

... và tại một số điểm setMap()được gọi bằng bản đồ và các luồng khác đang sử dụng SomeClass.MAPđể truy cập bản đồ và kiểm tra null như thế này:

HashMap<Object,Object> map = SomeClass.MAP;
if (map != null) {
  .. use the map
} else {
  .. some default behavior
}

Điều này không an toàn mặc dù nó có thể xuất hiện như thể nó là. Vấn đề là không có mối quan hệ xảy ra trước khi tập hợp SomeObject.MAPvà lần đọc tiếp theo trên một luồng khác, vì vậy luồng đọc được tự do xem bản đồ được xây dựng một phần. Điều này có thể làm bất cứ điều gì và thậm chí trong thực tế, nó thực hiện những việc như đưa luồng đọc vào một vòng lặp vô hạn .

Để xuất bản bản đồ một cách an toàn, bạn cần thiết lập mối quan hệ xảy ra trước khi viết tham chiếu đến HashMap(tức là ấn phẩm ) và các độc giả tiếp theo của tài liệu tham khảo đó (nghĩa là mức tiêu thụ). Thuận tiện, chỉ có một vài cách dễ nhớ để thực hiện điều đó ^[1] :

1. Trao đổi tham chiếu thông qua trường được khóa đúng cách ( JLS 17.4.5 )
2. Sử dụng trình khởi tạo tĩnh để thực hiện các cửa hàng khởi tạo ( JLS 12.4 )
3. Trao đổi tham chiếu qua trường biến động ( JLS 17.4.5 ) hoặc là hệ quả của quy tắc này, thông qua các lớp AtomicX
4. Khởi tạo giá trị vào trường cuối cùng ( JLS 17.5 ).

Những cái thú vị nhất cho kịch bản của bạn là (2), (3) và (4). Cụ thể, (3) áp dụng trực tiếp cho mã tôi có ở trên: nếu bạn chuyển đổi khai báo MAPthành:

public static volatile HashMap<Object, Object> MAP;

sau đó tất cả mọi thứ đều hoàn hảo: độc giả thấy một không null giá trị nhất thiết phải có một xảy ra-trước khi mối quan hệ với các cửa hàng để MAPvà do đó thấy tất cả các cửa hàng liên quan đến việc khởi tạo bản đồ.

Các phương thức khác thay đổi ngữ nghĩa của phương thức của bạn, vì cả (2) (sử dụng bộ khởi động tĩnh) và (4) (sử dụng cuối cùng ) ngụ ý rằng bạn không thể thiết lập MAPđộng khi chạy. Nếu bạn không cần phải làm điều đó, thì chỉ cần khai báo MAPlà static final HashMap<>và bạn được đảm bảo xuất bản an toàn.

Trong thực tế, các quy tắc rất đơn giản để truy cập an toàn vào "các đối tượng không bao giờ sửa đổi":

Nếu bạn đang xuất bản một đối tượng vốn không phải là bất biến (như trong tất cả các trường được khai báo final) và:

• Bạn đã có thể tạo đối tượng sẽ được chỉ định tại thời điểm khai báo ^a : chỉ cần sử dụng một finaltrường (bao gồm cả static finalcác thành viên tĩnh).
• Bạn muốn gán đối tượng sau, sau khi tham chiếu đã hiển thị: sử dụng trường biến động ^b .

Đó là nó!

Trong thực tế, nó rất hiệu quả. static finalVí dụ, việc sử dụng một trường cho phép JVM giả sử giá trị không thay đổi trong vòng đời của chương trình và tối ưu hóa nó rất nhiều. Việc sử dụng finaltrường thành viên cho phép hầu hết các kiến trúc đọc trường theo cách tương đương với trường đọc bình thường và không ức chế tối ưu hóa thêm ^c .

Cuối cùng, việc sử dụng volatilecó một số tác động: không cần rào cản phần cứng đối với nhiều kiến ​​trúc (như x86, cụ thể là không cho phép đọc để vượt qua đọc), nhưng một số tối ưu hóa và sắp xếp lại có thể không xảy ra trong thời gian biên dịch - nhưng điều này hiệu quả nói chung là nhỏ. Đổi lại, bạn thực sự nhận được nhiều hơn những gì bạn yêu cầu - không chỉ bạn có thể xuất bản một cách an toàn HashMap, bạn có thể lưu trữ nhiều HashMaps chưa được sửa đổi như bạn muốn cùng một tham chiếu và yên tâm rằng tất cả người đọc sẽ thấy một bản đồ được xuất bản an toàn .

Để biết thêm chi tiết, hãy tham khảo Shipilev hoặc Câu hỏi thường gặp này của Manson và Goetz .

[1] Trích dẫn trực tiếp từ shipilev .

^a Nghe có vẻ phức tạp, nhưng ý tôi là bạn có thể gán tham chiếu tại thời điểm xây dựng - tại điểm khai báo hoặc trong hàm tạo (trường thành viên) hoặc bộ khởi tạo tĩnh (trường tĩnh).

^b Tùy chọn, bạn có thể sử dụng một synchronizedphương thức để lấy / đặt, hoặc một AtomicReferencecái gì đó, nhưng chúng tôi đang nói về công việc tối thiểu bạn có thể làm.

c Một số kiến ​​trúc với các mô hình bộ nhớ rất yếu (tôi đang nhìn vào bạn , Alpha) có thể yêu cầu một số loại rào cản đọc trước khi finalđọc - nhưng ngày nay chúng rất hiếm.

Jeremy Manson, vị thần khi nói đến Mô hình bộ nhớ Java, có một blog gồm ba phần về chủ đề này - bởi vì thực chất bạn đang đặt câu hỏi "Có an toàn khi truy cập HashMap bất biến" - câu trả lời cho điều đó là có. Nhưng bạn phải trả lời vị ngữ cho câu hỏi đó là - "HashMap của tôi có bất biến không". Câu trả lời có thể làm bạn ngạc nhiên - Java có một bộ quy tắc tương đối phức tạp để xác định tính bất biến.

Để biết thêm thông tin về chủ đề này, hãy đọc các bài đăng trên blog của Jeremy:

Phần 1 về Tính không thay đổi trong Java: http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

Phần 2 về Tính không thay đổi trong Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

Phần 3 về Tính không thay đổi trong Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

Việc đọc được an toàn từ quan điểm đồng bộ hóa nhưng không phải là quan điểm bộ nhớ. Đây là điều bị hiểu lầm rộng rãi giữa các nhà phát triển Java, kể cả ở đây trên Stackoverflow. (Quan sát đánh giá của câu trả lời này để chứng minh.)

Nếu bạn có các luồng khác đang chạy, chúng có thể không thấy bản sao cập nhật của HashMap nếu không có bộ nhớ ghi ra khỏi luồng hiện tại. Ghi bộ nhớ xảy ra thông qua việc sử dụng các từ khóa được đồng bộ hóa hoặc biến động hoặc thông qua việc sử dụng một số cấu trúc đồng thời java.

Xem bài viết của Brian Goetz về Mô hình bộ nhớ Java mới để biết chi tiết.

Sau khi tìm hiểu thêm một chút, tôi đã tìm thấy điều này trong tài liệu java (nhấn mạnh của tôi):

Lưu ý rằng việc thực hiện này không được đồng bộ hóa. Nếu nhiều luồng truy cập đồng thời một bản đồ băm và ít nhất một trong các luồng sửa đổi bản đồ theo cấu trúc, nó phải được đồng bộ hóa bên ngoài. (Sửa đổi cấu trúc là bất kỳ thao tác nào thêm hoặc xóa một hoặc nhiều ánh xạ; chỉ thay đổi giá trị được liên kết với khóa mà một thể hiện đã chứa không phải là sửa đổi cấu trúc.)

Điều này dường như ngụ ý rằng nó sẽ an toàn, giả sử điều ngược lại của tuyên bố là đúng.

Một lưu ý là trong một số trường hợp, get () từ HashMap không đồng bộ có thể gây ra một vòng lặp vô hạn. Điều này có thể xảy ra nếu put () đồng thời gây ra sự thử lại của Bản đồ.

http://lightbody.net/blog/2005/07/hashmapget_can_cause_an_infini.html

Có một thay đổi quan trọng mặc dù. Truy cập bản đồ là an toàn, nhưng nói chung, không đảm bảo rằng tất cả các luồng sẽ nhìn thấy chính xác cùng một trạng thái (và do đó là các giá trị) của HashMap. Điều này có thể xảy ra trên các hệ thống đa bộ xử lý trong đó các sửa đổi đối với HashMap được thực hiện bởi một luồng (ví dụ: luồng được tạo ra) có thể nằm trong bộ đệm của CPU đó và sẽ không được nhìn thấy bởi các luồng chạy trên các CPU khác, cho đến khi hoạt động của hàng rào bộ nhớ thực hiện đảm bảo sự kết hợp bộ nhớ cache. Đặc tả ngôn ngữ Java được trình bày rõ ràng về vấn đề này: giải pháp là có được một khóa (được đồng bộ hóa (...)) để phát ra một hoạt động hàng rào bộ nhớ. Vì vậy, nếu bạn chắc chắn rằng sau khi điền HashMap, mỗi luồng sẽ thu được BẤT K lock khóa nào, thì từ thời điểm đó trở đi để truy cập HashMap từ bất kỳ luồng nào cho đến khi HashMap được sửa đổi lại.

Theo http://www.ibm.com/developerworks/java/l Library / j-jtp03304 / # Khởi tạo an toàn, bạn có thể biến HashMap của mình thành trường cuối cùng và sau khi nhà xây dựng kết thúc, nó sẽ được xuất bản một cách an toàn.

... Trong mô hình bộ nhớ mới, có một cái gì đó tương tự như mối quan hệ xảy ra trước khi ghi một trường cuối cùng trong một hàm tạo và tải ban đầu của một tham chiếu được chia sẻ đến đối tượng đó trong một luồng khác. ...

Vì vậy, kịch bản bạn mô tả là bạn cần đưa một loạt dữ liệu vào Bản đồ, sau đó khi bạn hoàn thành việc điền dữ liệu, bạn coi nó là bất biến. Một cách tiếp cận "an toàn" (có nghĩa là bạn đang thực thi rằng nó thực sự được coi là bất biến) là thay thế tham chiếu bằng Collections.unmodifiableMap(originalMap)khi bạn sẵn sàng biến nó thành bất biến.

Để biết ví dụ về cách bản đồ xấu có thể thất bại nếu được sử dụng đồng thời và cách giải quyết được đề xuất mà tôi đã đề cập, hãy xem mục diễu hành lỗi này: bug_id = 6423457

Câu hỏi này được giải quyết trong cuốn sách "Java đồng thời trong thực tiễn" của Brian Goetz (Liệt kê 16.8, trang 350):

@ThreadSafe
public class SafeStates {
    private final Map<String, String> states;

    public SafeStates() {
        states = new HashMap<String, String>();
        states.put("alaska", "AK");
        states.put("alabama", "AL");
        ...
        states.put("wyoming", "WY");
    }

    public String getAbbreviation(String s) {
        return states.get(s);
    }
}

Vì statesđược khai báo finalvà việc khởi tạo của nó được hoàn thành trong hàm tạo của chủ sở hữu, nên bất kỳ luồng nào sau này đọc bản đồ này đều được đảm bảo xem nó tại thời điểm hàm tạo kết thúc, miễn là không có luồng nào khác sẽ cố gắng sửa đổi nội dung của bản đồ.

Được cảnh báo rằng ngay cả trong mã đơn luồng, việc thay thế ConcảnHashMap bằng HashMap có thể không an toàn. ConcảnHashMap cấm null là khóa hoặc giá trị. HashMap không cấm họ (đừng hỏi).

Vì vậy, trong trường hợp không chắc là mã hiện tại của bạn có thể thêm null vào bộ sưu tập trong khi thiết lập (có thể là trong trường hợp thất bại nào đó), thay thế bộ sưu tập như mô tả sẽ thay đổi hành vi chức năng.

Điều đó nói rằng, miễn là bạn không làm gì khác đồng thời đọc từ HashMap là an toàn.

[Chỉnh sửa: bằng cách "đọc đồng thời", ý tôi là không có sửa đổi đồng thời.

Các câu trả lời khác giải thích làm thế nào để đảm bảo điều này. Một cách là làm cho bản đồ trở nên bất biến, nhưng nó không cần thiết. Ví dụ, mô hình bộ nhớ JSR133 xác định rõ ràng bắt đầu một luồng là một hành động được đồng bộ hóa, có nghĩa là những thay đổi được thực hiện trong luồng A trước khi nó bắt đầu luồng B được hiển thị trong luồng B.

Mục đích của tôi là không mâu thuẫn với những câu trả lời chi tiết hơn về Mô hình bộ nhớ Java. Câu trả lời này nhằm chỉ ra rằng ngay cả ngoài các vấn đề tương tranh, có ít nhất một sự khác biệt về API giữa ConcảnHashMap và HashMap, có thể làm hỏng ngay cả một chương trình đơn luồng thay thế một chương trình khác.

http://www.docjar.com/html/api/java/util/HashMap.java.html

đây là nguồn cho HashMap. Như bạn có thể nói, hoàn toàn không có mã khóa / mutex ở đó.

Điều này có nghĩa là mặc dù bạn có thể đọc từ HashMap trong tình huống đa luồng, nhưng tôi chắc chắn sẽ sử dụng một concảnHashMap nếu có nhiều lần ghi.

Điều thú vị là cả .NET HashTable và Dictionary <K, V> đều được tích hợp mã đồng bộ hóa.

Nếu việc khởi tạo và mọi lệnh được đồng bộ hóa, bạn sẽ lưu lại.

Mã sau được lưu vì trình nạp lớp sẽ đảm nhiệm việc đồng bộ hóa:

public static final HashMap<String, String> map = new HashMap<>();
static {
  map.put("A","A");

}

Mã sau được lưu vì việc viết biến động sẽ đảm nhiệm việc đồng bộ hóa.

class Foo {
  volatile HashMap<String, String> map;
  public void init() {
    final HashMap<String, String> tmp = new HashMap<>();
    tmp.put("A","A");
    // writing to volatile has to be after the modification of the map
    this.map = tmp;
  }
}

Điều này cũng sẽ hoạt động nếu biến thành viên là cuối cùng vì cuối cùng cũng biến động. Và nếu phương thức là một constructor.