ทำไมไม่ Green Threads

ในขณะที่ฉันรู้ว่าคำถามนี้ได้รับการครอบคลุมแล้ว (เช่นhttps://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads ) ฉันไม่รู้สึกว่าฉันได้รับคำตอบที่น่าพอใจ .

คำถามคือ: ทำไม JVM ไม่สนับสนุนเธรดสีเขียวอีกต่อไป?

มันบอกว่านี้ในแบบโค้ด Java คำถามที่พบบ่อย :

เธรดสีเขียวหมายถึงโหมดการทำงานของ Java Virtual Machine (JVM) ซึ่งโค้ดทั้งหมดจะถูกดำเนินการในเธรดระบบปฏิบัติการเดียว

และสิ่งนี้จบบนjava.sun.com :

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

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

คิด?

ฉันจำ JVM ที่ละทิ้งเธรดสีเขียวและย้ายไปที่เธรดดั้งเดิม ด้วยเหตุผลง่ายๆสองข้อ: เธรดสีเขียวเป็นขยะตรงไปตรงมาและมีความต้องการที่จะสนับสนุนโปรเซสเซอร์แบบมัลติคอร์ด้วยความพยายามของนักพัฒนาที่ จำกัด ที่ซัน

นี่เป็นความอัปยศ - เธรดสีเขียวให้สิ่งที่เป็นนามธรรมที่ดีกว่าช่วยให้การทำงานพร้อมกันเป็นเครื่องมือที่มีประโยชน์ไม่ใช่บล็อกที่สะดุด แต่หัวข้อสีเขียวนั้นไม่มีประโยชน์หากอุปสรรคหลายอย่างไม่สามารถเอาชนะได้:

• พวกเขาจะต้องใช้แกน cpu ทั้งหมดที่มีให้

• การสลับบริบทต้องมีราคาถูก

• I / O อาจบล็อกเธรดที่มีส่วนร่วม แต่ไม่ใช่เธรดอื่นใดและไม่แน่นอนเธรดอื่นทั้งหมดซึ่งเป็นกรณีในการนำไปใช้ก่อนหน้านี้บางส่วน

ฉันมักจะสงสัยว่าทำไมการมัลติเธรดจึงยากใน Java แต่ตอนนี้มันชัดเจนยิ่งขึ้น - ในที่สุดมันก็เกี่ยวกับการเปลี่ยนไปใช้เธรดดั้งเดิมซึ่งก็คือ:

• เก่งในการใช้แกน cpu ทั้งหมด

• เก่งในการเป็นพร้อมกันอย่างแท้จริงให้ I / O อิสระเป็นต้น

• ช้าที่การสลับบริบท (เปรียบเทียบกับการใช้เธรดสีเขียวที่ดีที่สุด)

• ความโลภอย่างน่ากลัวด้วยความทรงจำ จำกัด จำนวนสูงสุดที่สามารถใช้ได้

• สิ่งที่เป็นนามธรรมที่น่าสงสารสำหรับพื้นฐานสำหรับการแสดงโลกแห่งความจริงซึ่งแน่นอนพร้อมกันอย่างมาก

ปัจจุบันมีจำนวนมากของเวลาโปรแกรมเมอร์ในขณะนี้จะเข้าสู่การเขียนโปรแกรมขึ้น non-blocking I / O, ฟิวเจอร์สและอื่น ๆ มันเป็นความอัปยศใหญ่ที่เราไม่ได้อยู่ในระดับที่ดีขึ้นของสิ่งที่เป็นนามธรรม

สำหรับการเปรียบเทียบนอกจากภาษา Erlang แล้วภาษาGoใหม่ยังทำงานได้ดีในเวลาเดียวกัน พ่อของพวกเขาทุกคนยังคงเกิดขึ้นในรัฐปรากยังเป็นโครงการวิจัยที่กำลังดำเนินอยู่

กระบวนการเดียวที่แกล้งทำหลายเธรดมีปัญหามากมาย หนึ่งในนั้นคือเธรดที่แกล้งทำอยู่บนหน้าเพจที่ผิด

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

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

จะไม่มีประโยชน์เลยสำหรับรหัส Java เฉลี่ย Java ไม่ใช่ Erlang และโปรแกรมเมอร์ Java ไม่ได้อยู่ในความคิดเดียวกันกับโปรแกรมเมอร์ Erlang ภาษาไม่เคยตั้งใจจะใช้วิธีนี้

หากคุณต้องการกระบวนการที่มีน้ำหนักเบาอย่างแท้จริง - ใช้ Erlang และสร้างเธรดนับพันที่สื่อสารผ่านข้อความ ใน Java คุณจะมีหัวข้อการแชร์หน่วยความจำร่วมกับ mutex และ semaphores มันเป็นเพียงรูปแบบการเขียนโปรแกรมที่แตกต่างกันออกแบบมาสำหรับชุดของปัญหาที่แตกต่าง