เหตุใดขนาดฮีปจึงถูกแก้ไขใน JVM

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

จำเป็นต้องกำหนดขนาดหน่วยความจำสูงสุดของโปรแกรมของคุณเมื่อเวลาเริ่มต้นดูเหมือนว่าสิ่งที่ต้องทำ 1960 และมีการโต้ตอบที่ไม่ดีกับการจัดการหน่วยความจำเสมือนของ OS (GC การดึงข้อมูลสลับไม่สามารถกำหนดจำนวนหน่วยความจำกระบวนการ Java ใช้งานจริงจากทางด้าน OS พื้นที่ VM จำนวนมากสูญเปล่า (ฉันรู้ว่าคุณไม่สนใจเครื่อง 48 บิตแฟนซีของคุณ ... )) ฉันยังเดาว่าความพยายามเศร้าต่าง ๆ ในการสร้างระบบปฏิบัติการขนาดเล็กภายใน JVM (EE แอ็พพลิเคชันเซิร์ฟเวอร์ OSGi) เป็นอย่างน้อยบางส่วนที่จะตำหนิในสถานการณ์เช่นนี้เพราะการเรียกใช้กระบวนการ Java หลายกระบวนการบนระบบนำไปสู่การสูญเสียทรัพยากร ให้หน่วยความจำแต่ละอันที่พวกเขาอาจต้องใช้สูงสุด

น่าแปลกใจที่ Google ไม่ได้ยอมแพ้กับความชั่วร้ายที่เกิดขึ้นกับสิ่งที่ฉันคาดหวัง แต่พวกเขาอาจถูกฝังอยู่ใต้ผู้คนหลายล้านคนเพื่อค้นหาขนาดกองที่มั่นคงและยอมรับความจริง

คุณผิด. ขนาดฮีปของ JVM ไม่คงที่ จำกัด เพียงขอบเขต:

• -Xmx ตั้งค่าขนาดหน่วยความจำฮีปสูงสุด
• -Xms ตั้งค่าขนาดหน่วยความจำฮีพขั้นต่ำ

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

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

(FWIW คุณต้องระบุข้อกำหนดหน่วยความจำของโปรแกรมภายใต้ MacOS รุ่น pre-Darwin ของ Mac [ถึงระบบ 7 ต่อไปซึ่งเป็นรุ่นล่าสุดที่ฉันใช้] ซึ่งเข้ากันได้ดีกับ 80s)

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

กุญแจสำคัญคือการตั้งค่า ขอบเขตที่ถูกต้อง ฉันดู-msว่า "นี่เป็นจำนวนหน่วยความจำที่แอพของฉันต้องการ" และ-mx"มันไม่ควรเกินจำนวนนี้" ในการปรับใช้การผลิตทั้งสองควรอยู่ใกล้กันหากไม่เท่ากันและควรเป็นไปตามข้อกำหนดที่วัดได้จริง

ความกังวลของคุณเกี่ยวกับหน่วยความจำเสมือน "ที่สูญเปล่า" นั้นถูกใส่ผิดที่: เป็นเสมือนจริง (ฟรี) ใช่การจัดสรรฮีปให้ใหญ่เกินไปหมายความว่าคุณไม่สามารถเริ่มเธรดได้มากหรือโหลดไฟล์ที่แมปหน่วยความจำมากพอ แต่นั่นเป็นส่วนหนึ่งของการออกแบบแอพพลิเคชั่น: คุณมีทรัพยากรที่หายากคุณต้องแบ่งพาร์ติชั่นด้วยวิธีที่อนุญาตให้แอปพลิเคชันของคุณทำงานได้ ในฮีปแบบ "C-style" ซึ่งจะขยายจนกว่าคุณจะแตะที่ด้านบนสุดของหน่วยความจำปัญหาพื้นฐานก็เหมือนกันคุณแค่ไม่ต้องคิดถึงมันจนกว่าคุณจะมีปัญหา

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

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

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