การเขียนความหน่วงต่ำ Java [ปิด]

มีเทคนิคเฉพาะ Java (สิ่งที่จะไม่ใช้กับ C ++) สำหรับการเขียนรหัส latency ต่ำใน Java? ฉันมักจะเห็นบทบาทที่มีความล่าช้าต่ำของ Java และพวกเขาขอประสบการณ์ในการเขียน Java ที่มีความหน่วงต่ำซึ่งบางครั้งก็ดูเหมือนเป็นช่วงเวลาสั้น ๆ

เพียงคิดว่าฉันสามารถคิดว่าเป็นประสบการณ์กับ JNI จ้าง I / O โทรไปยังรหัสพื้นเมือง อาจเป็นไปได้ที่จะใช้รูปแบบการทำลายซึ่งไม่ใช่เทคโนโลยีจริง

มีเคล็ดลับเฉพาะ Java สำหรับการเขียนรหัส latency ต่ำหรือไม่

ฉันรู้ว่ามี Java Real Time แบบเรียลไทม์ แต่ฉันถูกเตือนแบบเรียลไทม์ไม่เหมือนกับ latency ต่ำ ....

นอกจากความคิดเห็นของ Martijnฉันต้องการเพิ่ม:

1. อุ่นเครื่อง JVM ของคุณ Bytecode เริ่มต้นเริ่มออกถูกตีความสำหรับ Hotspot และจากนั้นได้รับเรียบเรียงบนเซิร์ฟเวอร์หลังจาก10K สังเกต การสะสมฉัตรเป็นช่องว่างหยุดที่ดี

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

3. ปฏิบัติตาม " หลักการเขียนเดี่ยว " เพื่อหลีกเลี่ยงการทะเลาะวิวาทและผลกระทบจากการเข้าคิวของกฎของ Little รวมทั้งศึกษากฎของ Amdhal สำหรับสิ่งที่สามารถขนานกันและคุ้มค่า

4. สร้างโมเดลโดเมนธุรกิจของคุณและตรวจสอบให้แน่ใจว่าอัลกอริทึมของคุณทั้งหมดเป็น O (1) หรืออย่างน้อย O (log n) นี่อาจเป็นสาเหตุที่ใหญ่ที่สุดของปัญหาประสิทธิภาพในประสบการณ์ของฉัน ตรวจสอบให้แน่ใจว่าคุณมีการทดสอบประสิทธิภาพเพื่อครอบคลุมกรณีหลัก

5. เวลาแฝงต่ำใน Java ไม่ได้ จำกัด อยู่แค่ Java เท่านั้น คุณต้องเข้าใจว่าสแต็กทั้งหมดของคุณกำลังประมวลผลอยู่ สิ่งนี้จะเกี่ยวข้องกับการปรับระบบปฏิบัติการการเลือกฮาร์ดแวร์ที่เหมาะสมการปรับระบบซอฟต์แวร์และไดรเวอร์อุปกรณ์สำหรับฮาร์ดแวร์นั้น

6. เป็นจริง หากคุณต้องการเวลาแฝงต่ำอย่าเรียกใช้บนไฮเปอร์ไวเซอร์ ตรวจสอบให้แน่ใจว่าคุณมีคอร์เพียงพอสำหรับเธรดทั้งหมดที่จำเป็นต้องอยู่ในสถานะที่รันได้

7. Cache missors เป็นต้นทุนที่ใหญ่ที่สุดในการทำงานของคุณ ใช้อัลกอริธึมที่เป็นมิตรกับแคชและตั้งค่าความสัมพันธ์กับตัวประมวลผลหลักด้วยชุดงานหรือ numactl สำหรับ JVM หรือ JNI สำหรับแต่ละเธรด

8. พิจารณา JVM ทางเลือกเช่น Zing จาก Azul พร้อมกับตัวรวบรวมขยะแบบหยุดชั่วคราว

9. ที่สำคัญที่สุดคือให้ใครบางคนมีส่วนร่วมกับประสบการณ์ สิ่งนี้จะช่วยคุณประหยัดเวลาได้มากในระยะยาว ปลั๊กไร้ยางอาย :-)

เรียลไทม์และเวลาแฝงต่ำนั้นแยกจากกันอย่างชัดเจนแม้ว่ามักจะเกี่ยวข้องกัน เรียลไทม์นั้นเกี่ยวกับการคาดเดาได้มากกว่าเร็ว จากประสบการณ์ของฉัน JVM แบบเรียลไทม์แม้แต่แบบเรียลไทม์แบบนุ่มนวลจะช้ากว่า JVM แบบปกติ

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

1. คุณจำเป็นต้องชื่นชม Mechanical Sympathy (คำประกาศเกียรติคุณจากMartin Thompson ) กล่าวอีกนัยหนึ่งคุณต้องเข้าใจว่าฮาร์ดแวร์พื้นฐานของคุณทำอะไรอยู่ การรู้ว่า CPU โหลดเส้นแคชอย่างไรการอ่าน / เขียนแบนด์วิดธ์คือความเร็วของหน่วยความจำหลักและอื่น ๆ อีกมากมายมีความสำคัญมาก ทำไม? เพราะคุณจะต้องให้เหตุผลว่าซอร์สโค้ด Java ของคุณมีผลต่อระบบปฏิบัติการ / ฮาร์ดแวร์ผ่านทางรันไทม์ JVM อย่างไร ตัวอย่างเช่นเป็นวิธีการที่ตัวแปรฟิลด์ของคุณถูกวางในซอร์สโค้ดของคุณซึ่งเป็นสาเหตุของการวางสายแคช

2. โดยทั่วไปคุณต้องการอัลกอริทึมและล็อกฟรี I / O แม้แต่แอพพลิเคชั่นที่ได้รับการออกแบบมาอย่างดีที่สุด (ที่ใช้ตัวล็อก) ก็ยังมีความเสี่ยงในการบล็อก

3. ทำความเข้าใจกับการจัดสรรวัตถุและการรวบรวมขยะ นี่เป็นหัวข้อใหญ่ แต่โดยทั่วไปคุณต้องการหลีกเลี่ยงการหยุด GC ชั่วคราว (มักเกิดจากการหยุดธรรมชาติของคอลเลกชัน GC ต่าง ๆ ) นักสะสมผู้เชี่ยวชาญ GC เช่นนักสะสม Azul สามารถแก้ไขปัญหานี้ให้กับคุณได้ในหลายกรณี แต่สำหรับคนส่วนใหญ่พวกเขาจำเป็นต้องเข้าใจวิธีการปรับ Sun / Oracle GCs (CMS, G1, ฯลฯ )

4. Hotspot JIT นั้นยอดเยี่ยมมาก เรียนรู้เกี่ยวกับการปรับให้เหมาะสม แต่โดยทั่วไปแล้วการพูดถึงเทคนิค OO ที่ดีทั้งหมด (การห่อหุ้ม, วิธีการขนาดเล็ก, ข้อมูลที่ไม่เปลี่ยนรูปได้มากที่สุด) จะช่วยให้ JIT สามารถปรับให้เหมาะสมที่สุดได้

5. สถาปัตยกรรมระบบโดยรวม ระวังเครือข่ายว่าเครื่องอยู่ร่วมอย่างไรหากคุณเชื่อมต่อกับการแลกเปลี่ยนผ่านไฟเบอร์ ฯลฯ

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

โดยรวมฉันขอแนะนำให้ไปที่หลักสูตรการปรับประสิทธิภาพ Java ของ Kirk Pepperdine [คำเตือน: ฉันสอนหลักสูตรนี้ด้วยตัวเองดังนั้นฉันจึงลำเอียง] คุณจะได้รับความคุ้มครองที่ดีในแง่มุมต่าง ๆ ของ JVM และผลกระทบต่อ O / S และฮาร์ดแวร์พื้นฐาน

PS: ฉันจะพยายามกลับมาทบทวนในภายหลังและทำให้เป็นระเบียบขึ้นบ้าง