ในการพัฒนาซอฟต์แวร์ภาษาโปรแกรมJavaถือว่าช้ากว่า ภาษา ประเภทเจเนอเรชั่นที่สามที่ เร็วที่สุด เช่นCและC++ ^{[ 1 ]}ในทางตรงกันข้ามกับภาษาเหล่านั้น Java จะคอมไพล์เป็นJava Virtual Machine (JVM) โดยค่าเริ่มต้นด้วยการทำงานที่แตกต่างจากการ ทำงานของฮาร์ดแวร์คอมพิวเตอร์จริง การใช้งาน JVM ในยุคแรกๆ เป็นตัวแปลภาษาโดยจะจำลองการทำงานเสมือนทีละรายการแทนที่จะแปลเป็นรหัสเครื่องสำหรับการประมวลผลฮาร์ดแวร์โดยตรง

ตั้งแต่ช่วงปลายทศวรรษ 1990 ความเร็วในการประมวลผลโปรแกรม Java ดีขึ้นอย่างมากจากการนำการคอมไพล์แบบทันเวลา (JIT) มาใช้ (ในปี 1997 สำหรับJava 1.1 ) ^{[ 2 ] [ 3 ] [ 4 ]}การเพิ่มคุณสมบัติของภาษาที่สนับสนุนการวิเคราะห์โค้ดที่ดีขึ้น และการเพิ่มประสิทธิภาพใน JVM (เช่นHotSpotกลายเป็นค่าเริ่มต้นสำหรับJVM ของSun ในปี 2000) กลยุทธ์ การเก็บขยะ ที่ซับซ้อน ก็เป็นอีกด้านหนึ่งของการปรับปรุง การประมวลผลไบต์โค้ด Java ด้วยฮาร์ดแวร์ เช่นที่นำเสนอโดยJazelle ของ ARM ได้รับการสำรวจแต่ไม่ได้นำไปใช้งาน

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

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

JVM รุ่นแรกๆ มักจะตีความไบต์โค้ดของ Java เสมอ ซึ่งส่งผลเสียต่อประสิทธิภาพอย่างมาก โดยมีประสิทธิภาพลดลงระหว่าง 10 ถึง 20 เท่าเมื่อเทียบกับ C ในแอปพลิเคชันทั่วไป^{[ 5 ]}เพื่อแก้ไขปัญหานี้ จึงมีการนำคอมไพเลอร์แบบ Just-in-Time (JIT) มาใช้ใน Java 1.1 เนื่องจากต้นทุนการคอมไพล์ที่สูง จึงมีการเพิ่มระบบที่เรียกว่าHotSpotใน Java 1.2 และกลายเป็นค่าเริ่มต้นใน Java 1.3 โดยใช้เฟรมเวิร์กนี้เครื่องเสมือน Javaจะวิเคราะห์ประสิทธิภาพของโปรแกรมอย่างต่อเนื่องเพื่อหาจุดที่ทำงานหนักหรือทำงานซ้ำๆ จากนั้นจึงกำหนดเป้าหมายเพื่อเพิ่มประสิทธิภาพทำให้ได้การทำงานที่มีประสิทธิภาพสูงโดยมีค่าใช้จ่าย น้อยที่สุด สำหรับโค้ดที่ไม่สำคัญต่อประสิทธิภาพมากนัก^{[ 6 ] [ 7 ]} การทดสอบประสิทธิภาพบางอย่างแสดงให้เห็นถึงความเร็วที่เพิ่มขึ้นถึง 10 เท่าด้วยวิธีนี้^{[ 8 ]}อย่างไรก็ตาม เนื่องจากข้อจำกัดด้านเวลา คอมไพเลอร์จึงไม่สามารถเพิ่มประสิทธิภาพโปรแกรมได้อย่างเต็มที่ ดังนั้นโปรแกรมที่ได้จึงช้ากว่าโค้ดเนทีฟ^{[ ​​9 ] [ 10 ]}

การเพิ่มประสิทธิภาพแบบปรับตัวได้ (Adaptive optimizing) เป็นวิธีการในวิทยาการคอมพิวเตอร์ที่ทำการคอมไพล์ส่วนต่างๆ ของโปรแกรมใหม่แบบไดนามิกโดยอิงจากโปรไฟล์การทำงานปัจจุบัน ในการใช้งานแบบง่ายๆ ตัวเพิ่มประสิทธิภาพแบบปรับตัวได้อาจทำการแลกเปลี่ยนระหว่างการคอมไพล์แบบทันเวลา (just-in-time compiling) และการตีความคำสั่ง ในอีกระดับหนึ่ง การเพิ่มประสิทธิภาพแบบปรับตัวได้อาจใช้ประโยชน์จากเงื่อนไขข้อมูลเฉพาะที่เพื่อเพิ่มประสิทธิภาพโดยการกำจัดเงื่อนไขการแยกสาขาและใช้การขยายแบบอินไลน์ (inline expansion)

เครื่องเสมือน Javaเช่นHotSpotยังสามารถดีออพติคิวเลตโค้ดที่เคย JIT ไว้ก่อนหน้านี้ได้ ซึ่งช่วยให้สามารถทำการเพิ่มประสิทธิภาพที่รุนแรง (และอาจไม่ปลอดภัย) ได้ ในขณะที่ยังสามารถดีออพติคิวเลตโค้ดในภายหลังและกลับไปสู่เส้นทางที่ปลอดภัยได้^{[ 11 ] [ 12 ]}

เครื่องเสมือน Java (JVM) เวอร์ชัน 1.0 และ 1.1 ใช้ตัวเก็บขยะแบบ mark-sweepซึ่งอาจทำให้ฮีป แตกกระจาย หลังจากการเก็บขยะ ตั้งแต่ Java 1.2 เป็นต้นไป JVM ได้เปลี่ยนไปใช้ตัวเก็บขยะแบบ generationalซึ่งมีพฤติกรรมการลดการแตกกระจายที่ดีกว่ามาก^{[ 13 ]} JVM รุ่นใหม่ใช้หลากหลายวิธีที่ช่วยปรับปรุงประสิทธิภาพการเก็บขยะ ให้ดียิ่งขึ้นไปอีก ^{[ 14 ]}

Compressed Oops ช่วยให้ Java 5.0 ขึ้นไปสามารถเข้าถึงหน่วยความจำฮีปได้สูงสุดถึง 32 GB ด้วยการอ้างอิงแบบ 32 บิต Java ไม่รองรับการเข้าถึงไบต์แต่ละตัว แต่รองรับเฉพาะอ็อบเจ็กต์ซึ่งจัดเรียงแบบ 8 ไบต์ตามค่าเริ่มต้น ด้วยเหตุนี้ 3 บิตล่างสุดของการอ้างอิงฮีปจึงเป็น 0 เสมอ การลดความละเอียดของการอ้างอิง 32 บิตลงเหลือบล็อก 8 ไบต์ ทำให้พื้นที่ที่สามารถเข้าถึงได้เพิ่มขึ้นเป็น 32 GB ซึ่งช่วยลดการใช้หน่วยความจำลงอย่างมากเมื่อเทียบกับการใช้การอ้างอิง 64 บิต เนื่องจาก Java ใช้การอ้างอิงมากกว่าภาษาอื่นๆ เช่น C++ Java 8 รองรับการจัดเรียงที่ใหญ่กว่า เช่น การจัดเรียง 16 ไบต์ เพื่อรองรับหน่วยความจำได้สูงสุดถึง 64 GB ด้วยการอ้างอิง 32 บิต

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

วิธีการที่เรียกว่าการตรวจสอบแบบแบ่งเวลาซึ่งเปิดตัวครั้งแรกในJava Platform, Micro Edition (J2ME) ถูกนำมาใช้ใน JVM ตั้งแต่Java เวอร์ชัน 6โดยจะแบ่งการตรวจสอบไบต์โค้ดของ Javaออกเป็นสองขั้นตอน: ^{[ 15 ]}

• ขั้นตอนการออกแบบ – เมื่อทำการคอมไพล์คลาสจากซอร์สโค้ดไปเป็นไบต์โค้ด
• รันไทม์ – เมื่อโหลดคลาส

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

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

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

เนื่องจากไลบรารี Java ไม่ทราบว่าเมธอดใดจะถูกใช้งานโดยเธรดมากกว่าหนึ่งเธรด ไลบรารีมาตรฐานจึงล็อกบล็อกเมื่อจำเป็นในสภาพแวดล้อมแบบมัลติเธรด เสมอ

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

public String getNames () { final Vector <String> v = new Vector <> ( ); v.add ( "Me" ) ; v.add ( " You " ) ; v.add ( " Her " ) ; return v.toString ( ) ; }

ตั้งแต่ Java 6 เป็นต้นไป บล็อกโค้ดและวัตถุจะถูกล็อกเฉพาะเมื่อจำเป็นเท่านั้น^{[ 16 ]}ดังนั้นในกรณีข้างต้น เครื่องเสมือนจะไม่ล็อกวัตถุ Vector เลย

ตั้งแต่เวอร์ชัน 6u23 Java ได้รวมการสนับสนุนสำหรับการวิเคราะห์การหลีกเลี่ยงไว้ด้วย^{[ 17 ]}

ก่อนJava 6การจัดสรรรีจิสเตอร์ ในเครื่องเสมือนฝั่ง ไคลเอ็นต์นั้นค่อนข้างพื้นฐาน(รีจิสเตอร์ไม่ได้กระจายอยู่ทั่วบล็อก ) ซึ่งเป็นปัญหาในการออกแบบซีพียูที่มีรีจิสเตอร์ น้อยกว่า เช่นในสถาปัตยกรรมx86หากไม่มีรีจิสเตอร์เหลือสำหรับการดำเนินการ คอมไพเลอร์จะต้องคัดลอกข้อมูลจากรีจิสเตอร์ไปยังหน่วยความจำ (หรือจากหน่วยความจำไปยังรีจิสเตอร์) ซึ่งใช้เวลานาน (การเข้าถึงรีจิสเตอร์เร็วกว่ามาก) อย่างไรก็ตาม เครื่องเสมือนฝั่ง เซิร์ฟเวอร์ใช้ ตัวจัดสรร แบบกราฟสีและไม่มีปัญหาดังกล่าว

มีการนำการเพิ่มประสิทธิภาพการจัดสรรรีจิสเตอร์มาใช้ใน JDK 6 ของ Sun ^{[ 18 ]}ทำให้สามารถใช้รีจิสเตอร์เดียวกันข้ามบล็อกได้ (เมื่อเหมาะสม) ซึ่งช่วยลดการเข้าถึงหน่วยความจำ ส่งผลให้ประสิทธิภาพเพิ่มขึ้นประมาณ 60% ในการทดสอบประสิทธิภาพบางรายการ^{[ 19 ]}

การแชร์ข้อมูลคลาส (เรียกว่า CDS โดย Sun) เป็นกลไกที่ช่วยลดเวลาเริ่มต้นสำหรับแอปพลิเคชัน Java และยังช่วยลดการใช้หน่วยความจำ อีกด้วย เมื่อ ติดตั้ง JREตัวติดตั้งจะโหลดชุดคลาสจาก ไฟล์ JAR ของระบบ (ไฟล์ JAR ที่เก็บไลบรารีคลาส Java ทั้งหมด เรียกว่า rt.jar) ลงในตัวแทนภายในส่วนตัว และดัมพ์ตัวแทนนั้นลงในไฟล์ที่เรียกว่า "ไฟล์เก็บถาวรที่ใช้ร่วมกัน" ในระหว่างการเรียกใช้ JVM ครั้งต่อๆ ไป ไฟล์เก็บถาวรที่ใช้ร่วมกันนี้จะถูกแมปหน่วยความจำ เข้ามา ช่วยประหยัดค่าใช้จ่ายในการโหลดคลาสเหล่านั้น และอนุญาตให้ เมตาเดต้าของ JVM สำหรับคลาสเหล่านี้ส่วนใหญ่สามารถใช้ร่วมกันได้ระหว่างกระบวนการ JVM หลายกระบวนการ^{[ 20 ]}

การปรับปรุงที่สอดคล้องกันในเวลาเริ่มต้นนั้นเห็นได้ชัดเจนยิ่งขึ้นสำหรับโปรแกรมขนาดเล็ก^{[ 21 ]}

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

JDK 1.1.6: การคอมไพล์แบบ just-in-time ครั้งแรก ( คอมไพเลอร์ JIT ของSymantec ) ^{[ 2 ] [ 22 ]}

J2SE 1.2: การใช้ตัว เก็บ รวบรวม ข้อมูลแบบแบ่งรุ่น

J2SE 1.3: การ คอม ไพล์แบบ Just-in-timeโดยHotSpot

J2SE 1.4: ดูที่นี่สำหรับภาพรวมของ Sun เกี่ยวกับการปรับปรุงประสิทธิภาพระหว่างเวอร์ชัน 1.3 และ 1.4

Java SE 5.0: การแบ่งปันข้อมูลคลาส^{[ 23 ]}

Java SE 6:

• การตรวจสอบไบต์โค้ดแบบแยกส่วน
• การวิเคราะห์การหลบหนีและการทำให้ล็อกหยาบขึ้น
• การปรับปรุงการจัดสรรทะเบียน

การปรับปรุงอื่นๆ:

• Java OpenGL Java 2D pipeline speed improvements ^{[ 24 ]}
• ประสิทธิภาพ Java 2D ยังได้รับการปรับปรุงอย่างมีนัยสำคัญใน Java 6 ^{[ 25 ]}

ดูเพิ่มเติมที่ 'ภาพรวมของ Sun เกี่ยวกับการปรับปรุงประสิทธิภาพระหว่าง Java 5 และ Java 6' ^{[ 26 ]}

• Java Quick Starter ช่วยลดเวลาในการเริ่มต้นแอปพลิเคชันโดยการโหลดข้อมูล JRE บางส่วนล่วงหน้าในแคชดิสก์เมื่อ เริ่มต้นระบบปฏิบัติการ ^{[ 27 ]}
• ส่วนต่าง ๆ ของแพลตฟอร์มที่จำเป็นในการเรียกใช้แอปพลิเคชันที่เข้าถึงจากเว็บเมื่อไม่ได้ติดตั้ง JRE จะถูกดาวน์โหลดก่อน JRE เวอร์ชันเต็มมีขนาด 12 MB แอปพลิเคชัน Swing ทั่วไปต้องการดาวน์โหลดเพียง 4 MB เพื่อเริ่มต้น ส่วนที่เหลือจะถูกดาวน์โหลดในพื้นหลัง^{[ 28 ]}
• ประสิทธิภาพกราฟิกบนWindowsดีขึ้นจากการใช้Direct3D อย่างกว้างขวาง โดยค่าเริ่มต้น^{[ 29 ]}และใช้shadersบนหน่วยประมวลผลกราฟิก (GPU) เพื่อเร่งการทำงานของ Java 2D ที่ซับซ้อน ^{[ 30 ]}

มีการปรับปรุงประสิทธิภาพหลายอย่างสำหรับ Java 7: มีการวางแผนการปรับปรุงประสิทธิภาพในอนาคตสำหรับการอัปเดต Java 6 หรือ Java 7: ^{[ 31 ]}

• จัดเตรียมการสนับสนุน JVM สำหรับภาษาการเขียนโปรแกรมแบบไดนามิกโดยปฏิบัติตามงานต้นแบบที่ดำเนินการในปัจจุบันบนเครื่อง Da Vinci (เครื่องเสมือนหลายภาษา) ^{[ 32 ]}
• ปรับปรุงไลบรารีการทำงานพร้อมกันที่มีอยู่โดยการจัดการการประมวลผลแบบขนานบนโปรเซสเซอร์มัลติคอ ร์ ^{[ 33 ] [ 34 ]}
• อนุญาตให้ JVM ใช้ทั้งคอมไพเลอร์ JIT ของไคลเอ็นต์และเซิร์ฟเวอร์ ในเซสชันเดียวกันด้วยวิธีการที่เรียกว่าการคอมไพล์แบบแบ่งระดับ: ^{[ 35 ]}
  • ควรใช้ ไคลเอ็นต์นี้ในช่วงเริ่มต้น (เนื่องจากมีประสิทธิภาพดีในช่วงเริ่มต้นและสำหรับแอปพลิเคชันขนาดเล็ก)
  • เซิร์ฟเวอร์จะถูกใช้สำหรับการเรียกใช้งานแอปพลิเคชันในระยะยาว (เนื่องจากมีประสิทธิภาพเหนือกว่าคอมไพเลอร์ฝั่งไคลเอนต์ สำหรับการ ใช้ งาน นี้)
• แทนที่ตัวเก็บขยะแบบขนานที่มีการหยุดชั่วคราวต่ำที่มีอยู่ (เรียกอีกอย่างว่าตัวเก็บขยะแบบขนานที่มีการทำเครื่องหมายและกวาด (CMS)) ด้วยตัวเก็บขยะใหม่ที่เรียกว่า Garbage First (G1) เพื่อให้แน่ใจว่ามีการหยุดชั่วคราวที่สม่ำเสมอเมื่อเวลาผ่านไป^{[ 36 ] [ 37 ]}

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

Java มักจะคอมไพล์แบบ just-in-timeในขณะรันไทม์โดย Java virtual machineแต่ก็อาจจะคอมไพล์แบบ ahead-of-time ได้เช่นกัน เช่นเดียวกับ C++ เมื่อคอมไพล์แบบ just-in-time ไมโครเบนช์มาร์คของThe Computer Language Benchmarks Gameระบุถึงประสิทธิภาพดังต่อไปนี้: ^{[ 38 ]}

• ^{ช้ากว่าภาษา คอม}ไพล์ เช่นCหรือC++ [ ^{39 ]}
• ^{คล้ายกับภาษาคอมไพล์ แบบ} just-in-time อื่นๆ เช่นC# [ ^{40 ]}
• เร็วกว่าภาษาที่ไม่มีคอมไพเลอร์เนทีฟโค้ดที่มีประสิทธิภาพ ( ^JITหรือ AOT )เช่นPerl , Ruby , PHPและPython มาก [ ^{41 ]}

เกณฑ์มาตรฐานมักวัดประสิทธิภาพสำหรับโปรแกรมขนาดเล็กที่มีการคำนวณเชิงตัวเลขจำนวนมาก ในโปรแกรมจริงบางโปรแกรม Java มีประสิทธิภาพเหนือกว่า C ตัวอย่างหนึ่งคือเกณฑ์มาตรฐานของJake2 (โคลนของQuake IIที่เขียนด้วย Java โดยการแปล โค้ด C GPL ดั้งเดิม ) เวอร์ชัน Java 5.0 มีประสิทธิภาพดีกว่าเวอร์ชัน C ในบางการกำหนดค่าฮาร์ดแวร์^{[ 42 ]}แม้ว่าจะไม่ได้ระบุวิธีการวัดข้อมูล (ตัวอย่างเช่น หากใช้ไฟล์ปฏิบัติการ Quake II ดั้งเดิมที่คอมไพล์ในปี 1997 ซึ่งอาจถือว่าไม่ดี เนื่องจากคอมไพเลอร์ C ในปัจจุบันอาจเพิ่มประสิทธิภาพสำหรับ Quake ได้ดีกว่า) แต่ก็สังเกตว่าซอร์สโค้ด Java เดียวกันสามารถเพิ่มความเร็วได้อย่างมากเพียงแค่การอัปเดต VM ซึ่งเป็นสิ่งที่ทำไม่ได้ด้วยวิธีการคงที่ 100%

สำหรับโปรแกรมอื่นๆ เวอร์ชัน C++ สามารถทำงานได้เร็วกว่าเวอร์ชัน Java อย่างเห็นได้ชัด และโดยปกติแล้ว การทดสอบประสิทธิภาพที่ดำเนินการโดย Google ในปี 2011 แสดงให้เห็นถึงความแตกต่างถึง 10 เท่าระหว่าง C++ และ Java ^{[ 43 ]}ในทางตรงกันข้าม การทดสอบประสิทธิภาพทางวิชาการที่ดำเนินการในปี 2012 ด้วยอัลกอริทึมการสร้างแบบจำลอง 3 มิติ แสดงให้เห็นว่าJava 6 JVM ช้ากว่า C++ บน Windows ถึง 1.09 ถึง 1.91 เท่า^{[ 44 ]}

การเพิ่มประสิทธิภาพบางอย่างที่เป็นไปได้ใน Java และภาษาที่คล้ายกันอาจไม่สามารถทำได้ในบางสถานการณ์ใน C++: ^{[ 45 ]}

• การใช้ พอยเตอร์แบบ C อาจขัดขวางการปรับแต่งประสิทธิภาพในภาษาโปรแกรมที่รองรับพอยเตอร์
• การใช้ วิธี การวิเคราะห์การหลบหนีมีข้อจำกัดในC++ตัวอย่างเช่น เนื่องจากคอมไพเลอร์ C++ ไม่ทราบเสมอไปว่าวัตถุจะถูกแก้ไขในบล็อกโค้ดที่กำหนดเนื่องจากตัวชี้ [ ^{หมายเหตุ1 ]}
• Java สามารถเข้าถึงเมธอดอินสแตนซ์ที่สืบทอดมาได้เร็วกว่าที่ C++ สามารถเข้าถึงเมธอดเสมือนที่สืบทอดมาได้ เนื่องจาก C++ มีการค้นหาในตารางเสมือนเพิ่มเติม อย่างไรก็ตาม เมธอดที่ไม่ใช่เสมือนใน C++ ไม่ประสบปัญหาคอขวดด้านประสิทธิภาพของตารางเสมือน ดังนั้นจึงมีประสิทธิภาพใกล้เคียงกับ Java

JVM ยังสามารถดำเนินการเพิ่มประสิทธิภาพเฉพาะโปรเซสเซอร์หรือการขยายแบบอินไลน์ได้และความสามารถในการลดประสิทธิภาพของโค้ดที่คอมไพล์หรืออินไลน์แล้วบางครั้งทำให้สามารถดำเนินการเพิ่มประสิทธิภาพที่รุนแรงกว่าภาษาที่มีประเภทคงที่เมื่อมีฟังก์ชันไลบรารีภายนอกเข้ามาเกี่ยวข้อง^{[ 46 ] [ 47 ]}

ผลลัพธ์ของการทดสอบประสิทธิภาพระดับไมโครระหว่าง Java และ C++ ขึ้นอยู่กับว่านำการดำเนินการใดมาเปรียบเทียบ ตัวอย่างเช่น เมื่อเปรียบเทียบกับ Java 5.0:

• การดำเนินการทางคณิตศาสตร์ 32 บิตและ 64 บิต^{[ 48 ] [ 49 ]}การรับ/ส่งข้อมูลไฟล์^{[ 50 ]}และการจัดการข้อยกเว้น^{[ 51 ]}มีประสิทธิภาพใกล้เคียงกับโปรแกรม C++ ที่เทียบเคียงได้
• การดำเนินการกับอาร์เรย์^{[ 52 ]}มีประสิทธิภาพที่ดีกว่าใน C
• ประสิทธิภาพของฟังก์ชันตรีโกณมิติดีขึ้นมากในภาษา C ^{[ 53 ]}

หมายเหตุ

ความสามารถในการปรับขนาดและประสิทธิภาพของแอปพลิเคชัน Java บนระบบมัลติคอร์นั้นถูกจำกัดด้วยอัตราการจัดสรรวัตถุ ผลกระทบนี้บางครั้งเรียกว่า "กำแพงการจัดสรร" ^{[ 54 ]}อย่างไรก็ตาม ในทางปฏิบัติ อัลกอริทึมตัวเก็บขยะสมัยใหม่ใช้หลายคอร์ในการดำเนินการเก็บขยะ ซึ่งช่วยบรรเทาปัญหานี้ได้ในระดับหนึ่ง มีรายงานว่าตัวเก็บขยะบางตัวสามารถรองรับอัตราการจัดสรรได้มากกว่าหนึ่งกิกะไบต์ต่อวินาที^{[ 55 ]}และมีระบบที่ใช้ Java ซึ่งไม่มีปัญหาในการปรับขนาดไปยังคอร์ CPU หลายร้อยคอร์และฮีปขนาดหลายร้อยกิกะไบต์^{[ 56 ]}

การจัดการหน่วยความจำอัตโนมัติใน Java ช่วยให้สามารถใช้โครงสร้างข้อมูลแบบไร้การล็อกและเปลี่ยนแปลงไม่ได้อย่างมีประสิทธิภาพ ซึ่งทำได้ยากมากหรือบางครั้งเป็นไปไม่ได้เลยหากไม่มีระบบเก็บขยะ (garbage collection) Java มีโครงสร้างระดับสูงดังกล่าวจำนวนมากในไลบรารีมาตรฐานในแพ็กเกจ java.util.concurrent ในขณะที่ภาษาโปรแกรมหลายภาษาที่เคยใช้สำหรับระบบประสิทธิภาพสูง เช่น C หรือ C++ ยังขาดโครงสร้างเหล่านี้อยู่

โดยทั่วไปแล้ว เวลาเริ่มต้นทำงานของ Java จะช้ากว่าภาษาโปรแกรมอื่นๆ หลายภาษา เช่นC , C++ , PerlหรือPython มาก เนื่องจากต้องโหลดคลาสจำนวนมาก (โดยเฉพาะคลาสจากไลบรารีคลาสของแพลตฟอร์ม ) ก่อนที่จะนำมาใช้งาน

เมื่อเปรียบเทียบกับรันไทม์ยอดนิยมที่คล้ายกัน สำหรับโปรแกรมขนาดเล็กที่ทำงานบนเครื่อง Windows เวลาเริ่มต้นดูเหมือนจะคล้ายกับของ Mono และช้ากว่าของ . NETเล็กน้อย^{[ 57 ]}

ดูเหมือนว่าเวลาเริ่มต้นส่วนใหญ่เกิดจากการดำเนินการที่ผูกกับการรับส่งข้อมูล (IO) มากกว่าการเริ่มต้น JVM หรือการโหลดคลาส ( ไฟล์ข้อมูลคลาส rt.jarเพียงอย่างเดียวมีขนาด 40 MB และ JVM ต้องค้นหาข้อมูลจำนวนมากในไฟล์ขนาดใหญ่นี้) ^{[ 27 ]} การทดสอบบางอย่างแสดงให้เห็นว่าถึงแม้ว่าวิธี การตรวจสอบไบต์โค้ดแบบแยกส่วนใหม่จะช่วยปรับปรุงการโหลดคลาสได้ประมาณ 40% แต่ก็ช่วยปรับปรุงการเริ่มต้นโปรแกรมขนาดใหญ่ได้เพียงประมาณ 5% เท่านั้น^{[ 58 ]}

แม้จะเป็นการปรับปรุงเพียงเล็กน้อย แต่จะเห็นได้ชัดเจนกว่าในโปรแกรมขนาดเล็กที่ดำเนินการง่ายๆ แล้วจึงจบการทำงาน เนื่องจากภาระการโหลดข้อมูลของแพลตฟอร์ม Java อาจมากกว่าภาระการทำงานของโปรแกรมจริงหลายเท่า

ตั้งแต่ Java SE 6 Update 10 เป็นต้นไป Sun JRE มาพร้อมกับ Quick Starter ที่จะโหลดข้อมูลคลาสล่วงหน้าเมื่อระบบปฏิบัติการเริ่มต้นทำงาน เพื่อดึงข้อมูลจากแคชบนดิสก์แทนที่จะดึงจากดิสก์โดยตรง

Excelsior JETแก้ปัญหาจากอีกมุมหนึ่ง โปรแกรม Startup Optimizer ของมันช่วยลดปริมาณข้อมูลที่ต้องอ่านจากดิสก์เมื่อแอปพลิเคชันเริ่มต้นทำงาน และทำให้การอ่านข้อมูลเป็นไปอย่างเป็นลำดับมากขึ้น

ในเดือนพฤศจิกายน พ.ศ. 2547 Nailgunซึ่งเป็น "ไคลเอ็นต์ โปรโตคอล และเซิร์ฟเวอร์สำหรับการรันโปรแกรม Java จากบรรทัดคำสั่งโดยไม่ต้องเสียค่าใช้จ่ายในการเริ่มต้น JVM" ได้ถูกเผยแพร่สู่สาธารณะ^{[ 59 ]} โดยนำเสนอตัวเลือกสำหรับ สคริปต์ในการใช้ JVM เป็นเดมอนเป็นครั้งแรกเพื่อรันแอปพลิเคชัน Java หนึ่งรายการหรือมากกว่าโดยไม่ต้องเสียค่าใช้จ่ายในการเริ่มต้น JVM เดมอน Nailgun ไม่ปลอดภัย: "โปรแกรมทั้งหมดทำงานด้วยสิทธิ์เดียวกันกับเซิร์ฟเวอร์" ในกรณีที่ ต้องการความปลอดภัย แบบหลายผู้ใช้ Nailgun จึงไม่เหมาะสมหากไม่มีข้อควรระวังเป็นพิเศษ สคริปต์ที่การเริ่มต้น JVM ต่อแอปพลิเคชันใช้ทรัพยากรมาก จะเห็นประสิทธิภาพการทำงานที่ดีขึ้น หนึ่งถึงสอง เท่า^{[ 60 ]}

การใช้หน่วยความจำของ Java สูงกว่าการใช้หน่วยความจำของ C++ มาก เนื่องจาก:

• ใน Java มีค่าใช้จ่ายเพิ่มเติม 8 ไบต์สำหรับแต่ละอ็อบเจ็กต์และ 12 ไบต์สำหรับแต่ละอาร์เรย์^{[ 61 ]}หากขนาดของอ็อบเจ็กต์ไม่ใช่จำนวนเท่าของ 8 ไบต์ ระบบจะปัดขึ้นเป็นจำนวนเท่าของ 8 ถัดไป ซึ่งหมายความว่าอ็อบเจ็กต์ที่เก็บฟิลด์หนึ่งไบต์จะใช้พื้นที่ 16 ไบต์และต้องการการอ้างอิง 4 ไบต์ C++ ยังจัดสรรพอยเตอร์ (โดยปกติ 4 หรือ 8 ไบต์) สำหรับทุกอ็อบเจ็กต์ที่คลาสประกาศฟังก์ชันเสมือน โดยตรงหรือโดยอ้อม ^{[ 62 ]}
• การขาดการคำนวณแอดเดรสทำให้การสร้างคอนเทนเนอร์ที่มีประสิทธิภาพด้านหน่วยความจำ เช่น โครงสร้างที่มีระยะห่างแคบและรายการเชื่อมโยงแบบ XORเป็นไปไม่ได้ในปัจจุบัน ( โครงการ OpenJDK Valhallaมีเป้าหมายที่จะบรรเทาปัญหาเหล่านี้ แม้ว่าจะไม่ได้มุ่งเน้นที่จะนำการคำนวณพอยเตอร์มาใช้ เนื่องจากไม่สามารถทำได้ในสภาพแวดล้อมที่มีการเก็บขยะ)
• ตรงกันข้ามกับ malloc และ new ค่าใช้จ่ายด้านประสิทธิภาพโดยเฉลี่ยของการเก็บขยะจะเข้าใกล้ศูนย์อย่างไม่สิ้นสุด (หรือแม่นยำกว่านั้นคือรอบการทำงานของ CPU หนึ่งรอบ) เมื่อขนาดฮีปเพิ่มขึ้น^{[ 63 ]}
• ส่วนต่าง ๆ ของไลบรารีคลาส Javaจะต้องโหลดก่อนการดำเนินการโปรแกรม (อย่างน้อยคลาสที่ใช้ภายในโปรแกรม) ^{[ 64 ]}ซึ่งนำไปสู่ภาระหน่วยความจำจำนวนมากสำหรับแอปพลิเคชันขนาดเล็ก
• โดยทั่วไปแล้ว ทั้งไฟล์ไบนารีของ Java และการคอมไพล์แบบเนทีฟจะอยู่ในหน่วยความจำ
• เครื่องเสมือนใช้หน่วยความจำจำนวนมาก
• ในภาษา Java อ็อบเจ็กต์แบบผสม (คลาส A ซึ่งใช้อินสแตนซ์ของ B และ C) ถูกสร้างขึ้นโดยใช้การอ้างอิงไปยังอินสแตนซ์ที่จัดสรรไว้ของ B และ C ในภาษา C++ สามารถหลีกเลี่ยงค่าใช้จ่ายด้านหน่วยความจำและประสิทธิภาพของการอ้างอิงประเภทนี้ได้ เมื่ออินสแตนซ์ของ B และ/หรือ C มีอยู่ภายใน A แล้ว

โดยทั่วไปแล้ว แอปพลิเคชันที่เขียนด้วย C++ จะใช้หน่วยความจำน้อยกว่าแอปพลิเคชันที่เขียนด้วย Java ที่มีฟังก์ชันเทียบเท่ากัน เนื่องจากค่าใช้จ่ายในการทำงานที่สูงของเครื่องเสมือน การโหลดคลาส และการปรับขนาดหน่วยความจำอัตโนมัติของ Java สำหรับโปรแกรมที่หน่วยความจำเป็นปัจจัยสำคัญในการเลือกภาษาและสภาพแวดล้อมการทำงาน จำเป็นต้องมีการวิเคราะห์ต้นทุนและผลประโยชน์

ประสิทธิภาพของฟังก์ชันตรีโกณมิติแย่กว่า C เพราะ Java มีข้อกำหนดที่เข้มงวดสำหรับผลลัพธ์ของการดำเนินการทางคณิตศาสตร์ ซึ่งอาจไม่สอดคล้องกับการใช้งานฮาร์ดแวร์พื้นฐาน^{[ 65 ]}บน ชุดย่อยจุดลอยตัว x87 Java ตั้งแต่เวอร์ชัน 1.4 เป็นต้นไปจะลดอาร์กิวเมนต์สำหรับ sin และ cos ในซอฟต์แวร์^{[ 66 ]}ทำให้ประสิทธิภาพลดลงอย่างมากสำหรับค่าที่อยู่นอกช่วง^{[ 67 ]}

Java Native Interfaceเรียกใช้โอเวอร์เฮดสูง ทำให้การข้ามขอบเขตระหว่างโค้ดที่ทำงานบน JVM และโค้ดเนทีฟมีค่าใช้จ่ายสูง^{[ 68 ] [ 69 ] [ 70 ]} Java Native Access (JNA) ช่วยให้ โปรแกรม Javaเข้าถึงไลบรารีที่ใช้ร่วมกัน แบบเนทีฟ ( ไลบรารีลิงก์แบบไดนามิก (DLL) บน Windows) ได้ง่ายผ่านโค้ด Java เท่านั้น โดยไม่ต้องใช้ JNI หรือโค้ดเนทีฟ ฟังก์ชันการทำงานนี้เทียบได้กับ Platform/Invoke ของ Windows และ ctypes ของ Pythonการเข้าถึงเป็นแบบไดนามิกในขณะรันไทม์โดยไม่ต้องสร้างโค้ด แต่มีค่าใช้จ่าย และ JNA มักจะช้ากว่า JNI ^{[ 71 ]}

Swingถูกมองว่าช้ากว่าชุดเครื่องมือวิดเจ็ต ดั้งเดิม เนื่องจากมอบหมายการเรนเดอร์วิดเจ็ตให้กับAPI 2D ของ Java บริสุทธิ์ อย่างไรก็ตาม การทดสอบเปรียบเทียบประสิทธิภาพของ Swing กับชุดเครื่องมือวิดเจ็ตมาตรฐานซึ่งมอบหมายการเรนเดอร์ให้กับไลบรารี GUI ดั้งเดิมของระบบปฏิบัติการ แสดงให้เห็นว่าไม่มีผู้ชนะที่ชัดเจน และผลลัพธ์ขึ้นอยู่กับบริบทและสภาพแวดล้อมเป็นอย่างมาก^{[ 72 ]}นอกจากนี้ เฟรมเวิร์ก JavaFX รุ่นใหม่ ซึ่งมีจุดประสงค์เพื่อทดแทน Swing ยังแก้ไขปัญหาหลายอย่างของ Swing อีก ด้วย

บางคนเชื่อว่าประสิทธิภาพของ Java สำหรับการประมวลผลประสิทธิภาพสูง (HPC) นั้นคล้ายกับFortranในเกณฑ์มาตรฐานที่เน้นการคำนวณ แต่ JVM ยังคงมีปัญหาเรื่องความสามารถในการปรับขนาดสำหรับการสื่อสารที่เข้มข้นบนเครือข่ายการประมวลผลแบบกริด^{[ 73 ]}

อย่างไรก็ตาม แอปพลิเคชันการประมวลผลประสิทธิภาพสูงที่เขียนด้วยภาษา Java ได้รับรางวัลชนะเลิศในการแข่งขันวัดประสิทธิภาพ ในปี 2551 ^{[ 74 ]}และ 2552 ^{[ 75 ] [ 76 ]} คลัสเตอร์ที่ใช้ Apache Hadoop (โครงการประมวลผลประสิทธิภาพสูงแบบโอเพนซอร์สที่เขียนด้วยภาษา Java) สามารถเรียงลำดับจำนวนเต็มขนาดเทราไบต์และเพตาไบต์ได้เร็วที่สุด อย่างไรก็ตาม การตั้งค่าฮาร์ดแวร์ของระบบที่เข้าร่วมแข่งขันไม่ได้ถูกกำหนดตายตัว^{[ 77 ] [ 78 ]}

โปรแกรมใน Java เริ่มทำงานช้ากว่าโปรแกรมในภาษาคอมไพล์อื่นๆ^{[ 79 ] [ 80 ]}ดังนั้น ระบบตัดสินออนไลน์บางระบบ โดยเฉพาะระบบที่ดำเนินการโดยมหาวิทยาลัยในประเทศจีน จึงใช้เวลาจำกัดที่นานกว่าสำหรับโปรแกรม Java ^{[ 81 ] [ 82 ] [ 83 ] [ 84 ] [ 85 ]}เพื่อความเป็นธรรมต่อผู้เข้าแข่งขันที่ใช้ Java

• รันไทม์ภาษาทั่วไป
• การวิเคราะห์ประสิทธิภาพ
• โปรเซสเซอร์ Javaคือโปรเซสเซอร์แบบฝังตัวที่รันไบต์โค้ด Java โดยตรง (เช่นJStik )
• การเปรียบเทียบ Java และ C++
• Java ConcurrentMap

• เว็บไซต์ที่รวบรวมข้อมูลเกี่ยวกับประสิทธิภาพของ Java
• การแก้ไขปัญหาประสิทธิภาพของ Java
• พอร์ทัลประสิทธิภาพ Java ของ Sun
• แผนผังความคิด (Mind-map) ที่สร้างขึ้นจากงานนำเสนอของวิศวกรในสาขา Oracle SPb (ในรูปแบบไฟล์ PNG ขนาดใหญ่)