คำถามของฉันเกี่ยวข้องกับคำถามนี้ที่ถามก่อนหน้านี้ ในสถานการณ์ที่ฉันใช้คิวในการสื่อสารระหว่างเธรดผู้ผลิตและผู้บริโภคคนทั่วไปจะแนะนำให้ใช้LinkedBlockingQueueหรือConcurrentLinkedQueue?
ข้อดี / ข้อเสียของการใช้อย่างอื่นคืออะไร?
ความแตกต่างหลักที่ฉันเห็นได้จากมุมมองของ API คือLinkedBlockingQueueสามารถกำหนดขอบเขตได้
คำตอบ:
สำหรับเธรดผู้ผลิต / ผู้บริโภคฉันไม่แน่ใจว่านั่นConcurrentLinkedQueueเป็นตัวเลือกที่สมเหตุสมผล - มันไม่ได้ใช้งานBlockingQueueซึ่งเป็นอินเทอร์เฟซพื้นฐานสำหรับคิวผู้ผลิต / ผู้บริโภค IMO คุณต้องโทรไปpoll()รอสักครู่หากคุณไม่พบอะไรแล้วสำรวจความคิดเห็นอีกครั้ง ฯลฯ ... ซึ่งนำไปสู่ความล่าช้าเมื่อมีรายการใหม่เข้ามาและความไร้ประสิทธิภาพเมื่อว่างเปล่า (เนื่องจากตื่นขึ้นมาโดยไม่จำเป็น) .
จากเอกสารสำหรับ BlockingQueue:
BlockingQueueการใช้งานได้รับการออกแบบมาเพื่อใช้สำหรับคิวผู้ผลิต - ผู้บริโภคเป็นหลัก
ฉันรู้ว่ามันไม่ได้บอกอย่างเคร่งครัดว่าควรใช้เฉพาะคิวการบล็อกสำหรับคิวผู้ผลิต - ผู้บริโภค แต่ถึงอย่างนั้น ...
ConcurrentLinkedQueueยังมีประโยชน์หากเธรดของคุณกำลังตรวจสอบหลายคิว ตัวอย่างเช่นในเซิร์ฟเวอร์หลายผู้เช่า สมมติว่าคุณไม่ได้ใช้คิวบล็อกเดียวและใช้ตัวเลือกผู้เช่าแทนด้วยเหตุผลในการแยก
take()และput()เพียงสิ้นเปลืองทรัพยากรพิเศษ (interms ConcurrentLinkedQueue ของการประสานกว่า) แม้ว่ามันจะเป็นกรณีที่จะใช้คิวกระโดดสำหรับสถานการณ์การผลิตของผู้บริโภค
คำถามนี้สมควรได้รับคำตอบที่ดีกว่า
Java ConcurrentLinkedQueueขึ้นอยู่กับอัลกอริทึมที่มีชื่อเสียงของ Maged M. Michael และ Michael L. Scottสำหรับคิวที่ไม่มีการล็อคแบบไม่ปิดกั้น
"ไม่บล็อก" เป็นคำศัพท์สำหรับทรัพยากรที่ขัดแย้งกัน (คิวของเรา) หมายความว่าไม่ว่าตัวกำหนดตารางเวลาของแพลตฟอร์มจะทำอะไรเช่นการขัดจังหวะเธรดหรือหากเธรดที่เป็นปัญหาช้าเกินไปเธรดอื่น ๆ ที่ต่อสู้เพื่อทรัพยากรเดียวกัน จะยังคงสามารถดำเนินการต่อไปได้ หากเกี่ยวข้องกับการล็อกเช่นเธรดที่ยึดล็อกอาจถูกขัดจังหวะและเธรดทั้งหมดที่รอการล็อกนั้นจะถูกบล็อก Intrinsic locks ( synchronizedคีย์เวิร์ด) ใน Java อาจมาพร้อมกับบทลงโทษที่รุนแรงสำหรับประสิทธิภาพเช่นเมื่อล็อคเอนเอียงมีส่วนเกี่ยวข้องและคุณมีความขัดแย้งหรือหลังจาก VM ตัดสินใจที่จะ "ขยาย" การล็อกหลังจากระยะเวลาผ่อนผันการหมุนและบล็อกเธรดที่แข่งขันกัน ... ซึ่งเป็นเหตุผลว่าทำไมในหลาย ๆ บริบท (สถานการณ์ที่มีความขัดแย้งน้อย / ปานกลาง) ทำการเปรียบเทียบและ ชุดข้อมูลอ้างอิงอะตอมมีประสิทธิภาพมากขึ้นและนี่คือสิ่งที่โครงสร้างข้อมูลที่ไม่ปิดกั้นจำนวนมากกำลังทำอยู่
Java ConcurrentLinkedQueueไม่เพียง แต่ไม่ปิดกั้น แต่ยังมีคุณสมบัติที่ยอดเยี่ยมที่ผู้ผลิตไม่โต้แย้งกับผู้บริโภค ในสถานการณ์ผู้ผลิตรายเดียว / ผู้บริโภครายเดียว (SPSC) นั่นหมายความว่าจะไม่มีการโต้แย้งที่จะพูดถึง ในสถานการณ์ผู้ผลิตหลายราย / ผู้บริโภครายเดียวผู้บริโภคจะไม่โต้แย้งกับผู้ผลิต คิวนี้มีข้อขัดแย้งเมื่อผู้ผลิตหลายรายพยายามoffer()แต่จะเกิดขึ้นพร้อมกันตามคำจำกัดความ โดยพื้นฐานแล้วมันเป็นจุดประสงค์ทั่วไปและไม่มีการปิดกั้นคิวที่มีประสิทธิภาพ
สำหรับการไม่เป็นBlockingQueueเช่นนั้นการบล็อกเธรดเพื่อรอคิวเป็นวิธีที่แย่มากในการออกแบบระบบพร้อมกัน อย่า หากคุณคิดไม่ออกว่าจะใช้ConcurrentLinkedQueueสถานการณ์ผู้บริโภค / ผู้ผลิตอย่างไรให้เปลี่ยนไปใช้นามธรรมระดับสูงเช่นกรอบงานนักแสดงที่ดี
LinkedBlockingQueueบล็อกผู้บริโภคหรือผู้ผลิตเมื่อคิวว่างหรือเต็มและเธรดผู้บริโภค / ผู้ผลิตตามลำดับจะเข้าสู่โหมดสลีป แต่คุณลักษณะการปิดกั้นนี้มาพร้อมกับค่าใช้จ่าย: การดำเนินการใส่หรือดำเนินการทุกครั้งจะถูกล็อกซึ่งขัดแย้งกันระหว่างผู้ผลิตหรือผู้บริโภค (ถ้ามี) ดังนั้นในสถานการณ์ที่มีผู้ผลิต / ผู้บริโภคจำนวนมากการดำเนินการอาจช้าลง
ConcurrentLinkedQueueไม่ได้ใช้การล็อก แต่CASในการดำเนินการวาง / ดำเนินการอาจช่วยลดความขัดแย้งกับเธรดผู้ผลิตและผู้บริโภคจำนวนมาก แต่การเป็นโครงสร้างข้อมูล "รอฟรี" ConcurrentLinkedQueueจะไม่บล็อกเมื่อว่างเปล่าหมายความว่าผู้บริโภคจะต้องจัดการกับค่าที่take()ส่งคืนnullโดย "ไม่ว่างรอ" เช่นเธรดผู้บริโภคกิน CPU
ดังนั้นอันไหน "ดีกว่า" จึงขึ้นอยู่กับจำนวนเธรดของผู้บริโภคอัตราการบริโภค / การผลิต ฯลฯ จำเป็นต้องมีเกณฑ์มาตรฐานสำหรับแต่ละสถานการณ์
กรณีการใช้งานโดยเฉพาะอย่างหนึ่งที่ConcurrentLinkedQueueดีกว่าอย่างชัดเจนคือเมื่อผู้ผลิตผลิตสินค้าเป็นครั้งแรกและทำงานให้เสร็จโดยวางงานในคิวและหลังจากที่ผู้บริโภคเริ่มบริโภคเท่านั้นโดยรู้ว่าจะเสร็จสิ้นเมื่อคิวว่างเปล่า (ในที่นี้ไม่ใช่การเกิดขึ้นพร้อมกันระหว่างผู้ผลิต - ผู้บริโภค แต่เป็นระหว่างผู้ผลิต - ผู้ผลิตและผู้บริโภค - ผู้บริโภคเท่านั้น)
unbounded blockingqueueใช้จะดีกว่าCASตามพร้อมกันConcurrentLinkedQueue
อีกวิธีหนึ่ง (ที่ปรับขนาดได้ไม่ดี) คือช่องทางการนัดพบ: java.util.concurrent SynchronousQueue
หากคิวของคุณไม่สามารถขยายได้และมีเธรดผู้ผลิต / ผู้บริโภคเพียงรายการเดียว คุณสามารถใช้คิวแบบไม่ล็อก (คุณไม่จำเป็นต้องล็อกการเข้าถึงข้อมูล)