ByteBuffer.allocate () กับ ByteBuffer.allocateDirect ()

ถึงallocate()หรือallocateDirect()นั่นคือคำถาม

เป็นเวลาหลายปีตอนนี้ฉันติดอยู่เพียงแค่ความคิดที่ว่าตั้งแต่DirectByteBuffers มีการทำแผนที่หน่วยความจำโดยตรงในระดับ OS, ว่าจะดำเนินการได้เร็วขึ้นด้วยการรับ / วางสายกว่าHeapByteBuffers ฉันไม่เคยสนใจที่จะหารายละเอียดที่แน่นอนเกี่ยวกับสถานการณ์จนถึงปัจจุบัน ฉันต้องการทราบว่าByteBuffers สองประเภทใดที่เร็วและเงื่อนไขอะไร

Ron Hitches ในหนังสือที่ยอดเยี่ยมของเขาJava NIOดูเหมือนจะเสนอสิ่งที่ฉันคิดว่าอาจเป็นคำตอบที่ดีสำหรับคำถามของคุณ:

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

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

บัฟเฟอร์ไบต์โดยตรงมักเป็นตัวเลือกที่ดีที่สุดสำหรับการดำเนินการ I / O โดยการออกแบบพวกเขาสนับสนุนกลไก I / O ที่มีประสิทธิภาพสูงสุดที่มีให้กับ JVM บัฟเฟอร์แบบไม่ระบุทิศทางสามารถส่งผ่านไปยังแชนเนลได้ แต่การทำเช่นนั้นอาจส่งผลให้เกิดการปรับประสิทธิภาพ ปกติแล้วมันเป็นไปไม่ได้ที่บัฟเฟอร์แบบไม่มีทิศทางจะเป็นเป้าหมายของการดำเนินการ I / O แบบดั้งเดิม หากคุณส่งผ่านวัตถุ ByteBuffer แบบ nondirect ไปยังช่องสัญญาณเพื่อเขียนช่องทางนั้นอาจทำสิ่งต่อไปนี้ในการโทรแต่ละครั้งโดยปริยาย:

1. สร้างวัตถุ ByteBuffer โดยตรงชั่วคราว
2. คัดลอกเนื้อหาของบัฟเฟอร์แบบไม่เปลี่ยนทิศทางไปยังบัฟเฟอร์ชั่วคราว
3. ดำเนินการ I / O ระดับต่ำโดยใช้บัฟเฟอร์ชั่วคราว
4. วัตถุบัฟเฟอร์ชั่วคราวออกนอกขอบเขตและในที่สุดก็มีการรวบรวมขยะ

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

บัฟเฟอร์โดยตรงเหมาะสมที่สุดสำหรับ I / O แต่มันอาจมีราคาแพงกว่าการสร้างมากกว่าบัฟเฟอร์แบบไม่ระบุทิศทาง หน่วยความจำที่ใช้โดยบัฟเฟอร์โดยตรงได้รับการจัดสรรโดยการเรียกผ่านรหัสดั้งเดิมของระบบปฏิบัติการโดยผ่านฮีป JVM มาตรฐาน การตั้งค่าและการแยกบัฟเฟอร์โดยตรงอาจมีราคาแพงกว่าบัฟเฟอร์ฮีพแบบอาศัยอย่างมากทั้งนี้ขึ้นอยู่กับระบบปฏิบัติการโฮสต์และการนำ JVM มาใช้ พื้นที่จัดเก็บหน่วยความจำของบัฟเฟอร์โดยตรงไม่อยู่ภายใต้การรวบรวมขยะเนื่องจากอยู่นอกฮีป JVM มาตรฐาน

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

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

เนื่องจาก DirectByteBuffers เป็นการจับคู่หน่วยความจำโดยตรงที่ระดับ OS

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

มันจะทำงานได้เร็วขึ้นด้วยการโทรออก / รับสาย

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

ดีที่สุดที่จะทำการวัดของคุณเอง คำตอบอย่างรวดเร็วดูเหมือนว่าการส่งจากallocateDirect()บัฟเฟอร์ใช้เวลาน้อยกว่าallocate()ตัวแปร25% ถึง 75% (ทดสอบเมื่อคัดลอกไฟล์ไปยัง / dev / null) ขึ้นอยู่กับขนาด แต่การจัดสรรตัวเองอาจช้าลงอย่างมาก ปัจจัย 100x)

แหล่งที่มา:

• ทำไมส่วนต่างของเส้นโค้งประสิทธิภาพคี่ระหว่าง ByteBuffer.allocate () และ ByteBuffer.allocateDirect ()

• ByteBuffer.allocateDirect ขันช้าๆ

• ควรใช้ Array, Buffer หรือ direct Buffer เมื่อใด