Java hashmap เป็นจริง ๆ O (1) หรือไม่

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

ซึ่งในกรณีนี้การค้นหาจะมากกว่าO(n)O(1)

บางคนสามารถอธิบายได้ว่าพวกเขาเป็น O (1) และถ้าเป็นเช่นนั้นพวกเขาบรรลุสิ่งนี้ได้อย่างไร

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

p _collision = n / ความจุ

ดังนั้นแผนที่แฮชที่มีองค์ประกอบจำนวนเล็กน้อยก็น่าจะได้รับการชนอย่างน้อยหนึ่งครั้ง สัญลักษณ์ Big O ช่วยให้เราทำสิ่งที่น่าสนใจยิ่งขึ้น สังเกตว่าสำหรับค่าคงที่ใด ๆ คงที่ k

O (n) = O (k * n)

เราสามารถใช้คุณสมบัตินี้เพื่อปรับปรุงประสิทธิภาพของแผนที่แฮช เราสามารถคิดเกี่ยวกับความน่าจะเป็นของการชนได้สูงสุด 2 ครั้ง

p _{collision x 2} = (n / ความจุ) ²

ต่ำกว่านี้มาก เนื่องจากค่าใช้จ่ายในการจัดการการชนหนึ่งครั้งไม่เกี่ยวข้องกับประสิทธิภาพของ Big O เราจึงพบวิธีปรับปรุงประสิทธิภาพโดยไม่ต้องเปลี่ยนอัลกอริทึมจริง! เราสามารถพูดคุยเรื่องนี้กับ

p _{collision xk} = (n / ความจุ) ^k

และตอนนี้เราสามารถเพิกเฉยต่อจำนวนการชนโดยพลการบางส่วนและจบลงด้วยความน่าจะเป็นที่จะเกิดการชนน้อยกว่าที่เราคิดไว้ คุณสามารถรับความน่าจะเป็นในระดับเล็ก ๆ โดยเลือก k ที่ถูกต้องโดยไม่ต้องเปลี่ยนการใช้อัลกอริทึมที่แท้จริง

เราพูดถึงเรื่องนี้โดยบอกว่าแผนที่แฮชมีการเข้าถึง O (1) ที่มีความน่าจะเป็นสูง

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

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

ใน Java HashMap ทำงานโดยใช้ hashCode เพื่อค้นหาที่เก็บข้อมูล ที่เก็บข้อมูลแต่ละอันคือรายการของที่อยู่ในที่เก็บข้อมูลนั้น รายการจะถูกสแกนโดยใช้เท่ากับสำหรับการเปรียบเทียบ เมื่อเพิ่มรายการ HashMap จะถูกปรับขนาดเมื่อถึงเปอร์เซ็นต์การโหลดที่แน่นอน

ดังนั้นบางครั้งจะต้องเปรียบเทียบกับบางรายการ แต่โดยทั่วไปแล้วจะใกล้กว่า O (1) มากกว่า O (n) เพื่อจุดประสงค์ในการปฏิบัตินั่นคือทั้งหมดที่คุณควรรู้

โปรดจำไว้ว่า o (1) ไม่ได้หมายความว่าการค้นหาแต่ละรายการจะตรวจสอบรายการเดียวเท่านั้น - หมายความว่าจำนวนรายการที่เลือกโดยเฉลี่ยจะยังคงคงอยู่กับจำนวนรายการในคอนเทนเนอร์ ดังนั้นหากใช้การเปรียบเทียบ 4 รายการโดยเฉลี่ยเพื่อค้นหารายการในคอนเทนเนอร์ที่มี 100 รายการก็ควรใช้การเปรียบเทียบ 4 รายการโดยเฉลี่ยเพื่อค้นหารายการในคอนเทนเนอร์ที่มี 10,000 รายการและสำหรับรายการอื่น ๆ (มีเสมอ บิตของความแปรปรวนโดยเฉพาะรอบ ๆ จุดที่ตารางแฮชจะทำซ้ำและเมื่อมีรายการจำนวนน้อยมาก)

ดังนั้นการชนกันไม่ได้ป้องกันคอนเทนเนอร์จากการดำเนินการ o (1) ตราบใดที่จำนวนคีย์โดยเฉลี่ยต่อที่ฝากข้อมูลยังคงอยู่ภายในขอบเขตคงที่

ฉันรู้ว่านี่เป็นคำถามเก่า แต่จริงๆแล้วมีคำตอบใหม่สำหรับมัน

คุณพูดถูกว่าแผนที่แฮชไม่ได้O(1)พูดอย่างเคร่งครัดเพราะจำนวนองค์ประกอบมีขนาดใหญ่ตามอำเภอใจในที่สุดคุณจะไม่สามารถค้นหาในเวลาที่แน่นอน (และสัญลักษณ์ O ถูกกำหนดในรูปของตัวเลขที่สามารถ รับขนาดใหญ่โดยพลการ)

แต่มันไม่ได้เป็นไปตามความซับซ้อนตามเวลาจริง - O(n)เนื่องจากไม่มีกฎที่บอกว่าถังจะต้องดำเนินการเป็นรายการเชิงเส้น

ในความเป็นจริง, Java 8 การดำเนินการบุ้งกี๋เป็นเมื่อพวกเขาเกินเกณฑ์ซึ่งจะทำให้เวลาที่เกิดขึ้นจริงTreeMapsO(log n)

หากจำนวนของถัง (เรียกว่า b) มีค่าคงที่ (กรณีปกติ) การค้นหาจะเป็นจริง O (n)
เมื่อ n มีขนาดใหญ่ขึ้นจำนวนขององค์ประกอบในที่เก็บข้อมูลแต่ละค่าเฉลี่ย n / b หากการแก้ปัญหาการชนกันทำในวิธีใดวิธีหนึ่งตามปกติ (เช่นรายการที่ลิงก์) การค้นหาคือ O (n / b) = O (n)

สัญกรณ์ O เป็นเรื่องเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อ n มีขนาดใหญ่ขึ้นเรื่อย ๆ มันอาจทำให้เข้าใจผิดเมื่อนำไปใช้กับอัลกอริทึมบางอย่างและตารางแฮชเป็นกรณีในจุด เราเลือกจำนวนถังตามจำนวนองค์ประกอบที่เราคาดว่าจะจัดการ เมื่อ n มีขนาดใกล้เคียงกับ b จากนั้นการค้นหาจะเป็นค่าคงที่ประมาณเวลา แต่เราไม่สามารถเรียกมันได้ว่า O (1) เนื่องจาก O ถูกกำหนดในแง่ของขีด จำกัด เป็น n →∞

O(1+n/k)ซึ่งkเป็นจำนวนที่เก็บข้อมูล

หากการดำเนินการชุดk = n/alphaแล้วมันเป็นO(1+alpha) = O(1)ตั้งแต่alphaเป็นค่าคงที่

เราได้กำหนดไว้ว่าคำอธิบายมาตรฐานของการค้นหาตารางแฮชเป็น O (1) หมายถึงเวลาที่คาดว่าจะเป็นตัวพิมพ์เล็กโดยเฉลี่ยไม่ใช่ประสิทธิภาพของตัวพิมพ์ที่แย่ที่สุดอย่างเข้มงวด สำหรับตารางแฮชที่แก้ไขการชนด้วยการโยง (เช่น hashmap ของ Java) นี่คือเทคนิค O (1 + α) ด้วยฟังก์ชั่นแฮชที่ดีโดยที่αเป็นตัวประกอบภาระของตาราง ยังคงมีค่าคงที่ตราบใดที่จำนวนวัตถุที่คุณจัดเก็บนั้นไม่มากไปกว่าปัจจัยคงที่ที่ใหญ่กว่าขนาดของตาราง

นอกจากนี้ยังได้รับการอธิบายว่าการพูดอย่างเคร่งครัดเป็นไปได้ที่จะสร้างอินพุตที่ต้องใช้การค้นหา O ( n ) สำหรับฟังก์ชันแฮชที่กำหนดขึ้น แต่ก็น่าสนใจที่จะพิจารณาเวลาที่คาดว่าจะเป็นกรณีที่เลวร้ายที่สุดซึ่งแตกต่างจากเวลาค้นหาโดยเฉลี่ย การใช้การโยงนี้คือ O (1 + ความยาวของสายโซ่ที่ยาวที่สุด) เช่นΘ (log n / log log n ) เมื่อα = 1

หากคุณสนใจในวิธีการทางทฤษฎีเพื่อให้ได้การคาดการณ์เวลาที่เลวร้ายที่สุดการค้นหากรณีที่เลวร้ายที่สุดคุณสามารถอ่านเกี่ยวกับการแฮชที่สมบูรณ์แบบแบบไดนามิกซึ่งแก้ไขการชนซ้ำด้วยตารางแฮชอีกแบบ

มันเป็น O (1) ก็ต่อเมื่อฟังก์ชั่นแฮชของคุณดีมาก การใช้งานตารางแฮช Java ไม่ได้ป้องกันฟังก์ชันแฮชที่ไม่ดี

ไม่ว่าคุณจะต้องขยายตารางเมื่อคุณเพิ่มรายการหรือไม่ไม่เกี่ยวข้องกับคำถามเพราะมันเกี่ยวกับเวลาการค้นหา

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

location = (arraylength - 1) & keyhashcode

ที่นี่ & แสดงถึงตัวดำเนินการบิตและ AND

ตัวอย่างเช่น: 100 & "ABC".hashCode() = 64 (location of the bucket for the key "ABC")

ระหว่างการดำเนินการ get จะใช้วิธีเดียวกันในการกำหนดตำแหน่งของที่เก็บข้อมูลสำหรับคีย์ ภายใต้กรณีที่ดีที่สุดแต่ละคีย์มีแฮชโค้ดที่ไม่ซ้ำกันและผลลัพธ์ในที่ฝากข้อมูลเฉพาะสำหรับแต่ละคีย์ในกรณีนี้เมธอด get ใช้เวลาเพียงเพื่อกำหนดตำแหน่งที่เก็บข้อมูลและเรียกค่าที่คงที่ O (1)

ภายใต้กรณีที่เลวร้ายที่สุดคีย์ทั้งหมดมีแฮชโค้ดเดียวกันและเก็บไว้ในที่เก็บเดียวกันส่งผลให้เกิดการข้ามผ่านรายการทั้งหมดซึ่งนำไปสู่ ​​O (n)

ในกรณีของ java 8 ที่ฝากข้อมูลรายการที่เชื่อมโยงจะถูกแทนที่ด้วย TreeMap ถ้าขนาดเพิ่มขึ้นมากกว่า 8 ซึ่งจะช่วยลดประสิทธิภาพการค้นหากรณีที่เลวร้ายที่สุดให้เป็น O (log n)

โดยพื้นฐานแล้วสิ่งนี้ใช้สำหรับการใช้งานตารางแฮชส่วนใหญ่ในภาษาการเขียนโปรแกรมส่วนใหญ่เนื่องจากอัลกอริทึมเองนั้นไม่เปลี่ยนแปลง

หากไม่มีการชนกันในตารางคุณจะต้องค้นหาเพียงครั้งเดียวดังนั้นเวลาทำงานคือ O (1) หากมีการชนกันคุณต้องทำการค้นหามากกว่าหนึ่งครั้งซึ่งจะลดประสิทธิภาพลงสู่ O (n)

ขึ้นอยู่กับอัลกอริทึมที่คุณเลือกเพื่อหลีกเลี่ยงการชน หากการใช้งานของคุณใช้การเชื่อมโยงแบบแยกกันดังนั้นสถานการณ์กรณีที่เลวร้ายที่สุดจะเกิดขึ้นเมื่อองค์ประกอบข้อมูลทุกรายการถูกแฮชเป็นค่าเดียวกัน ในกรณีดังกล่าวการค้นหาข้อมูลไม่แตกต่างจากการค้นหาเชิงเส้นในรายการที่เชื่อมโยงเช่น O (n) อย่างไรก็ตามความน่าจะเป็นที่เกิดขึ้นนั้นเล็กน้อยและการค้นหาที่ดีที่สุดและกรณีเฉลี่ยยังคงที่เช่น O (1)

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

เฉพาะในกรณีทางทฤษฎีเมื่อ hashcodes แตกต่างกันเสมอและ bucket สำหรับรหัส hash ทุกครั้งก็แตกต่างกันเช่นกัน O (1) จะมีอยู่ มิฉะนั้นจะเป็นลำดับที่คงที่เช่นเมื่อเพิ่ม Hashmap ลำดับการค้นหาจะคงที่

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

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