การรับค่าจาก java.util.HashMap นั้นปลอดภัยจากหลายเธรดหรือไม่?

มีกรณีที่แผนที่จะถูกสร้างขึ้นและเมื่อมีการเริ่มต้นมันจะไม่ถูกแก้ไขอีกครั้ง อย่างไรก็ตามจะสามารถเข้าถึงได้ (ผ่านรับ (คีย์) เท่านั้น) จากหลายเธรด วิธีนี้ปลอดภัยไหมที่จะใช้java.util.HashMap?

(ปัจจุบันฉันใช้อย่างมีความสุขjava.util.concurrent.ConcurrentHashMapและไม่จำเป็นต้องวัดเพื่อปรับปรุงประสิทธิภาพ แต่ฉันแค่อยากรู้อยากเห็นว่าเรียบง่ายHashMapพอเพียงดังนั้นคำถามนี้ไม่ใช่ "ฉันควรใช้อันไหนดี?" และไม่ใช่คำถามประสิทธิภาพ ค่อนข้างคำถามคือ "จะปลอดภัยหรือไม่")

สำนวนของคุณจะปลอดภัยถ้าหากว่าการอ้างอิงถึงสิ่งHashMapนั้นได้รับการตีพิมพ์อย่างปลอดภัยแล้ว แทนที่จะเป็นสิ่งที่เกี่ยวข้องกับHashMapตัวตนของตัวเองสิ่งพิมพ์ที่ปลอดภัยเกี่ยวข้องกับวิธีการสร้างเธรดทำให้การอ้างอิงไปยังแผนที่สามารถมองเห็นกระทู้อื่น ๆ ได้

โดยพื้นฐานแล้วการแข่งขันที่เป็นไปได้เพียงอย่างเดียวที่นี่คือระหว่างการสร้างHashMapและการอ่านเธรดใด ๆ ที่สามารถเข้าถึงได้ก่อนที่มันจะถูกสร้างขึ้นอย่างสมบูรณ์ การอภิปรายส่วนใหญ่เกี่ยวกับสิ่งที่เกิดขึ้นกับสถานะของวัตถุแผนที่ แต่สิ่งนี้ไม่เกี่ยวข้องเนื่องจากคุณไม่เคยแก้ไขมันดังนั้นส่วนที่น่าสนใจเพียงอย่างเดียวก็คือHashMapการเผยแพร่ข้อมูลอ้างอิง

ตัวอย่างเช่นสมมติว่าคุณเผยแพร่แผนที่ดังนี้:

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

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

... และ ณ จุดหนึ่งsetMap()มีการเรียกใช้แผนที่และมีเธรดอื่น ๆ ที่ใช้SomeClass.MAPในการเข้าถึงแผนที่และตรวจสอบ null เช่นนี้:

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

สิ่งนี้ไม่ปลอดภัยแม้ว่ามันอาจปรากฏขึ้นราวกับว่ามันเป็น ปัญหาคือว่าไม่มีความสัมพันธ์เกิดขึ้นก่อนระหว่างชุดของSomeObject.MAPและการอ่านที่ตามมาบนเธรดอื่นดังนั้นเธรดการอ่านมีอิสระที่จะดูแผนที่ที่สร้างขึ้นบางส่วน นี้สวยมากสามารถทำอะไรและแม้กระทั่งในทางปฏิบัติมันไม่สิ่งที่ชอบใส่ด้ายอ่านลงในวง จำกัด

หากต้องการเผยแพร่แผนที่อย่างปลอดภัยคุณต้องสร้างความสัมพันธ์ก่อนเกิดขึ้นระหว่างการเขียนการอ้างอิงถึงHashMap(เช่นสิ่งพิมพ์ ) และผู้อ่านที่ตามมาของการอ้างอิงนั้น (เช่นปริมาณการใช้) สะดวกมีเพียงไม่กี่วิธีที่ง่ายต่อการจดจำประสบความสำเร็จที่^[1] :

1. แลกเปลี่ยนการอ้างอิงผ่านช่องที่ล็อคอย่างเหมาะสม ( JLS 17.4.5 )
2. ใช้ initializer คงที่เพื่อทำการเริ่มต้นร้านค้า ( JLS 12.4 )
3. แลกเปลี่ยนการอ้างอิงผ่านสนามระเหย ( JLS 17.4.5 ) หรือเป็นผลมาจากกฎนี้ผ่านคลาส AtomicX
4. เริ่มต้นค่าลงในเขตข้อมูลสุดท้าย ( JLS 17.5 )

สิ่งที่น่าสนใจที่สุดสำหรับสถานการณ์ของคุณคือ (2), (3) และ (4) โดยเฉพาะอย่างยิ่ง (3) นำไปใช้โดยตรงกับรหัสที่ฉันมีด้านบน: หากคุณเปลี่ยนการประกาศMAPเป็น:

public static volatile HashMap<Object, Object> MAP;

ดังนั้นทุกอย่างเป็นเพียว: ผู้อ่านที่เห็นค่าที่ไม่เป็นศูนย์จำเป็นต้องมีความสัมพันธ์ที่เกิดขึ้นก่อนกับร้านค้าMAPและด้วยเหตุนี้จึงเห็นร้านค้าทั้งหมดที่เกี่ยวข้องกับการเริ่มต้นแผนที่

วิธีอื่นเปลี่ยนความหมายของวิธีการของคุณเนื่องจากทั้ง (2) (โดยใช้ static initalizer) และ (4) (ใช้ขั้นสุดท้าย ) หมายความว่าคุณไม่สามารถตั้งค่าMAPแบบไดนามิกที่รันไทม์ หากคุณไม่ต้องการทำเช่นนั้นเพียงแค่ประกาศMAPว่าเป็นstatic final HashMap<>และคุณได้รับการรับรองสิ่งพิมพ์ที่ปลอดภัย

ในทางปฏิบัติกฎนั้นง่ายสำหรับการเข้าถึง "วัตถุที่ไม่เคยแก้ไข" อย่างปลอดภัย:

หากคุณกำลังเผยแพร่วัตถุที่ไม่เปลี่ยนแปลงไม่ได้โดยเนื้อแท้ (เช่นในทุกสาขาที่ประกาศfinal) และ:

• คุณสามารถสร้างวัตถุที่จะถูกกำหนดในขณะที่มีการประกาศ^a : เพียงแค่ใช้finalฟิลด์ (รวมถึงstatic finalสมาชิกแบบคงที่)
• คุณต้องการที่จะกำหนดวัตถุที่ต่อมาหลังจากการอ้างอิงที่มีอยู่แล้วสามารถมองเห็นได้: ใช้สารระเหยฟิลด์ข

แค่นั้นแหละ!

ในทางปฏิบัติมันมีประสิทธิภาพมาก static finalตัวอย่างเช่นการใช้ฟิลด์ช่วยให้ JVM ถือว่าค่าไม่เปลี่ยนแปลงสำหรับอายุการใช้งานของโปรแกรมและปรับให้เหมาะสมอย่างมาก การใช้finalเขตข้อมูลสมาชิกช่วยให้สถาปัตยกรรมส่วนใหญ่สามารถอ่านฟิลด์ในลักษณะที่เทียบเท่ากับฟิลด์ปกติที่อ่านและไม่ยับยั้งการปรับให้เหมาะสมต่อไป^cค

ในที่สุดการใช้งานvolatileจะมีผลกระทบบางอย่าง: ไม่จำเป็นต้องใช้ฮาร์ดแวร์กั้นในสถาปัตยกรรมจำนวนมาก (เช่น x86 โดยเฉพาะที่ไม่อนุญาตให้อ่านเพื่อส่งผ่านการอ่าน) แต่การเพิ่มประสิทธิภาพและการเรียงลำดับใหม่อาจไม่เกิดขึ้นในเวลารวบรวม ผลกระทบโดยทั่วไปมีขนาดเล็ก ในการแลกเปลี่ยนคุณจะได้รับมากกว่าที่คุณขอไม่เพียง แต่คุณจะสามารถเผยแพร่ได้อย่างปลอดภัยHashMapคุณสามารถจัดเก็บจำนวนมากที่ไม่ได้แก้ไขHashMapตามที่คุณต้องการอ้างอิงเดียวกันและมั่นใจได้ว่าผู้อ่านทุกคนจะเห็นแผนที่ที่เผยแพร่อย่างปลอดภัย .

สำหรับรายละเอียดเต็มไปด้วยเลือดเพิ่มเติมโปรดดูที่Shipilevหรือคำถามที่พบบ่อยนี้โดยแมนสันและเก๊

[1] โดยตรงข้อความจากshipilev

^aนั่นฟังดูซับซ้อน แต่สิ่งที่ฉันหมายถึงคือคุณสามารถกำหนดการอ้างอิงในเวลาก่อสร้างได้ไม่ว่าจะที่จุดประกาศหรือในตัวสร้าง (เขตข้อมูลสมาชิก) หรือตัวย่อคงที่ (แบบคงที่)

^bหรือคุณสามารถใช้synchronizedวิธีรับ / ตั้งค่าAtomicReferenceหรืออะไรก็ได้ แต่เรากำลังพูดถึงงานขั้นต่ำที่คุณสามารถทำได้

c สถาปัตยกรรมบางอย่างที่มีโมเดลหน่วยความจำอ่อนแอมาก (ฉันกำลังมองคุณอัลฟ่า) อาจต้องการกำแพงกั้นการอ่านบางประเภทก่อนfinalอ่าน - แต่สิ่งเหล่านี้หายากมากในวันนี้

Jeremy Manson พระเจ้าเมื่อมาถึง Java Memory Model มีบล็อกสามส่วนในหัวข้อนี้ - เพราะโดยพื้นฐานแล้วคุณกำลังถามคำถาม "ปลอดภัยหรือไม่ที่จะเข้าถึง HashMap ที่ไม่เปลี่ยนรูป" - คำตอบคือใช่ แต่คุณต้องตอบคำกริยาสำหรับคำถามนั้นคือ - "HashMap ของฉันไม่เปลี่ยนรูป" คำตอบอาจทำให้คุณประหลาดใจ - Java มีกฎที่ค่อนข้างซับซ้อนในการพิจารณาความไม่สามารถเปลี่ยนแปลงได้

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับหัวข้ออ่านโพสต์บล็อกของ Jeremy:

ส่วนที่ 1 เกี่ยวกับความไม่สามารถเปลี่ยนแปลงได้ใน Java: http://jeremymanson.blogspot.com/2008/04/immutability-in-java.html

ส่วนที่ 2 เกี่ยวกับความไม่สามารถเปลี่ยนได้ใน Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html

ส่วนที่ 3 เกี่ยวกับความไม่สามารถเปลี่ยนแปลงได้ใน Java: http://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html

การอ่านนั้นปลอดภัยจากจุดยืนการซิงโครไนซ์ แต่ไม่ใช่มุมมองหน่วยความจำ นี่เป็นสิ่งที่เข้าใจผิดในหมู่นักพัฒนา Java รวมถึงที่นี่ใน Stackoverflow (สังเกตคะแนนของคำตอบนี้เพื่อพิสูจน์)

หากคุณมีเธรดอื่นที่กำลังรันอยู่เธรดเหล่านั้นอาจไม่เห็นสำเนาที่ปรับปรุงแล้วของ HashMap หากไม่มีหน่วยความจำเขียนออกมาจากเธรดปัจจุบัน การเขียนหน่วยความจำเกิดขึ้นผ่านการใช้คีย์เวิร์ดที่ซิงโครไนซ์หรือระเหยหรือผ่านการใช้งานของการสร้างพร้อมกันของจาวา

ดูบทความของ Brian Goetz ใน Java Memory Model ใหม่สำหรับรายละเอียด

หลังจากดูเพิ่มอีกนิดฉันพบสิ่งนี้ในjava doc (focus mine):

โปรดทราบว่าการใช้งานนี้ไม่ได้รับการซิงโครไนซ์ หากมีหลายเธรดเข้าถึงการแฮชแม็พพร้อมกันและอย่างน้อยหนึ่งเธรดที่ปรับเปลี่ยนการแม็พโครงสร้างนั้นจะต้องซิงโครไนซ์ภายนอก (การปรับเปลี่ยนโครงสร้างเป็นการดำเนินการใด ๆ ที่เพิ่มหรือลบการแมปหนึ่งรายการขึ้นไปเพียงแค่เปลี่ยนค่าที่เกี่ยวข้องกับคีย์ที่อินสแตนซ์ที่มีอยู่แล้วไม่ใช่การปรับเปลี่ยนโครงสร้าง)

สิ่งนี้ดูเหมือนจะบอกเป็นนัยว่ามันจะปลอดภัยโดยสมมติว่าการสนทนาของแถลงการณ์มีจริง

สิ่งหนึ่งที่ทราบคือในบางกรณีการรับ () จาก HashMap ที่ไม่ซิงโครไนซ์สามารถทำให้เกิดการวนซ้ำไม่สิ้นสุด สิ่งนี้สามารถเกิดขึ้นได้หาก put () พร้อมกันทำให้เกิดการทำแผนที่ใหม่

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

มีการบิดที่สำคัญแม้ว่า มีความปลอดภัยในการเข้าถึงแผนที่ แต่โดยทั่วไปไม่รับประกันว่ากระทู้ทั้งหมดจะเห็นสถานะเดียวกัน (และค่านิยม) ของ HashMap สิ่งนี้อาจเกิดขึ้นในระบบมัลติโปรเซสเซอร์ซึ่งการแก้ไข HashMap ที่ทำโดยหนึ่งเธรด (เช่นหนึ่งที่มีประชากร) สามารถนั่งในแคชของ CPU นั้นและจะไม่เห็นโดยเธรดที่ทำงานบน CPU อื่นจนกว่าหน่วยความจำรั้วจะทำงาน ดำเนินการเพื่อให้มั่นใจว่าการเชื่อมโยงกันของแคช Java Language Specification ชัดเจนในที่นี้: การแก้ปัญหาคือการได้รับล็อค (ตรงกัน (... ())) ซึ่งส่งเสียงการดำเนินงานรั้วหน่วยความจำ ดังนั้นหากคุณแน่ใจว่าหลังจากการเติม HashMap แต่ละเธรดจะได้รับการล็อกใด ๆ แล้วก็ตกลงจากจุดนั้นในการเข้าถึง HashMap จากเธรดใด ๆ จนกว่า HashMap จะถูกแก้ไขอีกครั้ง

ตามhttp://www.ibm.com/developerworks/java/library/j-jtp03304/ # ความปลอดภัยในการเริ่มต้นคุณสามารถทำให้ HashMap ของคุณเป็นฟิลด์สุดท้ายและหลังจากตัวสร้างเสร็จสิ้นจะได้รับการเผยแพร่อย่างปลอดภัย

... ภายใต้โมเดลหน่วยความจำใหม่มีบางสิ่งที่คล้ายกับความสัมพันธ์ที่เกิดขึ้นก่อนระหว่างการเขียนฟิลด์สุดท้ายในตัวสร้างและการโหลดเริ่มต้นของการอ้างอิงที่ใช้ร่วมกันกับวัตถุนั้นในเธรดอื่น ...

ดังนั้นสถานการณ์ที่คุณอธิบายคือคุณต้องใส่ข้อมูลจำนวนมากลงในแผนที่จากนั้นเมื่อคุณเติมข้อมูลเสร็จแล้วคุณจะถือว่ามันไม่เปลี่ยนรูป วิธีการหนึ่งที่ "ปลอดภัย" (หมายถึงคุณบังคับใช้ว่ามันได้รับการปฏิบัติอย่างไม่เปลี่ยนรูป) คือการแทนที่การอ้างอิงด้วยCollections.unmodifiableMap(originalMap)เมื่อคุณพร้อมที่จะทำให้ไม่เปลี่ยนรูป

สำหรับตัวอย่างของวิธีการแมปไม่ดีสามารถล้มเหลวหากใช้พร้อมกันและวิธีแก้ปัญหาที่แนะนำที่ฉันกล่าวถึงให้ตรวจสอบรายการข้อผิดพลาดในการแห่นี้: bug_id = 6423457

คำถามนี้ได้รับการแก้ไขในหนังสือ "Java Concurrency in Practice" ของ Brian Goetz (รายการ 16.8 หน้า 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);
    }
}

เนื่องจากstatesมีการประกาศเป็นfinalและการกำหนดค่าเริ่มต้นเสร็จสมบูรณ์ภายในตัวสร้างคลาสของเจ้าของเธรดใด ๆ ที่อ่านแผนที่นี้ในภายหลังจะรับประกันว่าจะเห็นเมื่อเวลาที่ตัวสร้างเสร็จสิ้นโดยที่ไม่มีเธรดอื่นใดที่จะพยายามแก้ไขเนื้อหาของแผนที่

ได้รับการเตือนว่าแม้ในรหัสที่มีเธรดเดียวการแทนที่ ConcurrentHashMap ด้วย HashMap อาจไม่ปลอดภัย ConcurrentHashMap ห้ามใช้ null เป็นคีย์หรือค่า HashMap ไม่ได้ห้ามพวกเขา (ไม่ต้องถาม)

ดังนั้นในสถานการณ์ที่ไม่น่าเป็นไปได้ที่รหัสที่มีอยู่ของคุณอาจเพิ่ม null ให้กับคอลเลกชันในระหว่างการติดตั้ง (สมมุติว่ามีบางกรณีที่ล้มเหลว) การแทนที่คอลเลกชันตามที่อธิบายไว้จะเปลี่ยนพฤติกรรมการทำงาน

ที่กล่าวว่าหากคุณไม่ทำสิ่งใดการอ่านจาก HashMap ที่เกิดขึ้นพร้อมกันนั้นปลอดภัย

[แก้ไข: โดย "อ่านพร้อมกัน" ฉันหมายความว่ายังไม่มีการแก้ไขพร้อมกัน

คำตอบอื่น ๆ อธิบายถึงวิธีการตรวจสอบให้แน่ใจ วิธีหนึ่งคือการทำให้แผนที่ไม่เปลี่ยนรูป แต่ไม่จำเป็น ตัวอย่างเช่นโมเดลหน่วยความจำ JSR133 กำหนดการเริ่มต้นเธรดอย่างชัดเจนว่าเป็นการกระทำที่ทำข้อมูลให้ตรงกันซึ่งหมายความว่าการเปลี่ยนแปลงที่เกิดขึ้นในเธรด A ก่อนที่จะเริ่มเธรด B จะปรากฏในเธรด B

ความตั้งใจของฉันคือไม่ขัดต่อคำตอบที่ละเอียดยิ่งขึ้นเกี่ยวกับ Java Memory Model คำตอบนี้มีจุดมุ่งหมายเพื่อชี้ให้เห็นว่านอกเหนือจากปัญหาการเกิดพร้อมกันมีอย่างน้อยหนึ่งความแตกต่างระหว่าง API ConcurrentHashMap และ HashMap ซึ่งสามารถ scupper แม้โปรแกรมเธรดเดียวซึ่งแทนที่หนึ่งด้วยอื่น ๆ ]

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

นี่คือแหล่งข้อมูลสำหรับ HashMap อย่างที่คุณสามารถบอกได้ว่าไม่มีรหัสล็อค / mutex อยู่ที่นั่น

ซึ่งหมายความว่าในขณะที่มันโอเคที่จะอ่านจาก HashMap ในสถานการณ์แบบมัลติเธรดฉันต้องใช้ ConcurrentHashMap แน่นอนถ้ามีหลาย ๆ การเขียน

สิ่งที่น่าสนใจคือทั้ง. NET HashTable และ Dictionary <K, V> ได้สร้างขึ้นในรหัสการประสาน

หากการกำหนดค่าเริ่มต้นและทุกรายการถูกซิงโครไนซ์คุณจะได้รับการบันทึก

รหัสต่อไปนี้ถูกบันทึกเนื่องจาก classloader จะดูแลการซิงโครไนซ์:

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

}

รหัสต่อไปนี้ถูกบันทึกเนื่องจากการเขียนของ volatile จะดูแลการซิงโครไนซ์

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;
  }
}

วิธีนี้จะใช้งานได้หากตัวแปรสมาชิกถือเป็นที่สิ้นสุดเพราะสุดท้ายยังมีความผันผวน และถ้าวิธีนี้เป็นนวกรรมิก