Java เสนอปรับแรมเองใน JDK 28 เริ่มไวขึ้น แต่บิลคลาวด์จะลดจริงไหม

ข้อเสนอปรับ ZGC ตัวจัดการหน่วยความจำของ Java ลดเวลาวอร์มแอปได้เกือบ 90% ในกรณีศึกษาของ JEP 545 แปลว่าแอปตัวอย่างเข้าถึงความเร็วที่นิ่งเร็วขึ้นมากครับ Erik Österlund เสนอเรื่องนี้คู่กับการปรับขนาดหน่วยความจำอัตโนมัติ เพื่อเข้า JDK 28 ชุดซอฟต์แวร์สำหรับพัฒนาและรัน Java แต่ทั้งคู่ยังอยู่ขั้นเสนอให้บรรจุ ตามรายงาน JavaRubberDuck วันที่ 10 ตุลาคม

ประเด็นใกล้ตัวคือบริษัทจะเผื่อแรมให้ระบบมากแค่ไหน โดยไม่ทำให้คนใช้งานต้องรอ ตาม JEP 546 ตั้งหน่วยความจำน้อยเกินไปทำให้ระบบเสียเวลาจัดการข้อมูลบ่อยขึ้น แต่ตั้งมากเกินไปอาจเบียดโปรแกรมอื่น บทความนี้อ่านจากเอกสารและรายงานที่อ้างอิงเท่านั้น ผมยังไม่ได้ทดสอบกับระบบจริงครับ

สรุป 30 วินาที: เกิดอะไรขึ้น

JEP คือเอกสารข้อเสนอปรับปรุง Java รอบนี้ JEP 545 เน้นเริ่มแอปไวและวอร์มไว ส่วน JEP 546 เน้นปรับหน่วยความจำตามงานและทรัพยากรที่เหลือ ทั้งคู่ระบุเจ้าของเป็น Erik Österlund และสถานะ Proposed to Target แปลว่าเสนอให้บรรจุในรุ่นเป้าหมาย ยังไม่ใช่การยืนยันว่าปล่อยแล้ว

หน้ารวม JDK 28 ระบุวันสิ้นสุดการทบทวนข้อเสนอคู่นี้เป็น 14 ตุลาคม 2026 แปลว่ายังมีขั้นตอนให้ติดตามหลังวันที่เผยแพร่บทความนี้ แหล่งที่อ่านไม่ได้ให้วันเปิดใช้รุ่นสมบูรณ์ จึงยังไม่ควรนัดอัปเกรดระบบจากข่าวนี้อย่างเดียว

Heap หรือฮีป คือพื้นที่หน่วยความจำที่ใช้เก็บข้อมูลของแอป Java ตาม JEP 545 ตัวเลือก -Xms กำหนดขนาดเริ่มต้น ส่วน -Xmx กำหนดเพดาน เมื่อใช้แนวทางใหม่ร่วมกับการปรับขนาดอัตโนมัติ ผู้เสนอตั้งใจลดความจำเป็นในการกำหนดค่าเหล่านี้ด้วยมือ รวมถึง -XX:+AlwaysPreTouch ซึ่งสั่งเตรียมหน่วยความจำล่วงหน้า

แต่ การปรับขนาดอัตโนมัติไม่ได้เปิดเองเป็นค่าเริ่มต้นตามข้อเสนอ ครับ JEP 546 เรียกว่าเป็นนโยบายแบบเลือกเปิด ตัวอย่างต้องเลือก ZGC ด้วย -XX:+UseZGC และเปิดการปรับขนาดด้วย -XX:+ZAdaptiveHeapSizing ด้วย คำว่าค่าเริ่มต้นในเอกสารส่วนถัดไปจึงหมายถึงค่าภายในโหมดที่เปิดแล้ว

ทำไมเรื่องนี้เกี่ยวกับคุณ

ถ้าคุณใช้ระบบงานที่พัฒนาด้วย Java สิ่งที่ควรถามทีมระบบคือ หลังเริ่มแอปแล้วงานกลับมานิ่งเร็วแค่ไหน JEP 545 แยก startup เป็นเวลาถึงคำตอบแรก และ warmup เป็นเวลาจนถึงประสิทธิภาพสูงสุด แปลว่าตอบได้แล้วกับพร้อมรับงานหนักเป็นคนละเรื่อง การเห็นสถานะว่าเปิดสำเร็จจึงยังไม่ตอบประเด็นทั้งหมด

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

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

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

ทำงานยังไง

Garbage collection หรือ GC คือการเก็บกวาดข้อมูลที่แอปไม่ใช้แล้วเพื่อคืนพื้นที่ JEP 546 อธิบายว่า ZGC ติดตามข้อมูลที่ยังใช้อยู่ ก่อนย้ายและคืนพื้นที่ส่วนเก่า เมื่อฮีปใกล้เต็มจึงเริ่มรอบเก็บกวาด ถ้าพื้นที่น้อย ก็ต้องทำงานนี้ถี่ขึ้น แม้ต้นทุนต่อรอบไม่ได้ขึ้นกับขนาดฮีปทั้งหมดโดยตรง

ฝั่ง JEP 545 เสนอให้เริ่มฮีปเพียง 2 MB แปลว่าขอแรมจริงช่วงเปิดแอปเท่าที่จำเป็นก่อน เมื่อพบว่าการเก็บกวาดถี่ ระบบจะขยายล่วงหน้าเป็นขั้นที่ใหญ่ขึ้นเรื่อย ๆ งานขยายใช้ชุดงานเบื้องหลังของ ZGC แทนการให้ชุดงานหลักของแอปรอทำเอง

ขั้นต่อมาคือ pre-touch หรือการแตะพื้นที่หน่วยความจำล่วงหน้าเพื่อให้พร้อมใช้ ตาม JEP 545 ระบบปฏิบัติการมักจัดการรายละเอียดบางส่วนเมื่อพื้นที่ถูกใช้ครั้งแรก แนวทางใหม่ให้ ZGC เตรียมส่วนที่เพิ่งขยายในเบื้องหลัง แอปจึงไม่ต้องรับภาระนี้ทั้งหมดตอนกำลังทำงาน และไม่ต้องเตรียมฮีปใหญ่ทั้งหมดก่อนเปิดบริการ

เอกสารยังเสนอใช้ large pages คือแบ่งหน่วยความจำเป็นหน่วยใหญ่ขึ้น เพื่อให้เข้าถึงข้อมูลมีประสิทธิภาพกว่าเดิม โดย JEP 545 ระบุ Linux รุ่น 6.1 ขึ้นไป แปลว่าระบบกลุ่มนี้มีช่องทางขอเปลี่ยนหน่วยเล็กเป็นหน่วยใหญ่โดยไม่ต้องตั้งค่าเคอร์เนลก่อน เคอร์เนลคือส่วนหลักที่ควบคุมทรัพยากรเครื่อง แต่วิธีจัดการนี้ไม่ได้รับประกันว่าจะเหมือนกันทุกระบบปฏิบัติการ

นึกถึงร้านอาหารที่ทยอยตั้งโต๊ะตามลูกค้าที่เข้ามา แทนเช่าห้องโถงเต็มพื้นที่ตั้งแต่เช้าครับ การเริ่มฮีปเล็กเหมือนเปิดโต๊ะเท่าที่ต้องใช้ ส่วนการขยายและเตรียมพื้นที่เบื้องหลังเหมือนจัดโต๊ะเพิ่มก่อนลูกค้าชุดใหม่มาถึง นี่คือภาพเปรียบเทียบของกลไกใน JEP 545 โต๊ะว่างเยอะก็ไม่ได้แปลว่าร้านขายดีขึ้นเอง

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

ตัวเลือก -XX:ZGCIntensity ตั้งระดับความเข้มข้นของการเก็บกวาด โดย JEP 546 ให้ค่าเริ่มต้นเป็น 5 แปลว่าเป็นระดับตั้งต้นสำหรับบอกความต้องการของผู้ใช้ ไม่ใช่เปอร์เซ็นต์ CPU ลดค่าลงหมายถึงยอมใช้แรมเพิ่มเพื่อใช้ CPU น้อยลง ส่วนเพิ่มค่าคือยอมใช้ CPU เพิ่มเพื่อประหยัดแรม ความสัมพันธ์กับ CPU จริงไม่ได้ถูกกำหนดตายตัว

จุดหักมุม: เริ่มไว ไม่ได้แปลว่ากินแรมน้อยเสมอ

แต่เมื่อเปิดการปรับอัตโนมัติ JEP 546 เสนอเพดานเริ่มต้นเป็น 100% ของแรมจริงหักส่วนสำรองเล็กน้อย แปลว่าระบบมีช่องให้ขยายเกือบเต็มทรัพยากร ไม่ได้แปลว่าจองแรมจริงทั้งหมดทันที และไม่ได้แปลว่าจะใช้แรมน้อยกว่ารุ่นเดิมทุกแอป

เพดานเดิมที่ JEP 546 อธิบายคือ 25% ของแรมจริง แปลว่าการเปิดโหมดใหม่เปลี่ยนขอบเขตที่ระบบอาจใช้ได้อย่างมีนัยสำคัญ ผู้เสนอเตือนเองว่าอาจใช้แรมมากขึ้นจนโปรแกรมอื่นเหลือไม่พอ ดังนั้นข่าวนี้ยังไม่ใช่ใบรับรองว่าบิลคลาวด์จะลดครับ

เรื่องเงิน / ผลกระทบ

มาดูตัวเลขก่อนคุยงบครับ กรณีศึกษา Spring PetClinic แอปตัวอย่างใน JEP 545 ใช้เครื่องที่มีแรม 32 GB แปลว่าผลมาจากสภาพทดสอบที่ระบุไว้ ไม่ใช่ค่าเฉลี่ยของระบบ Java ทุกแห่ง ตัวเลขต่อไปทั้งหมดเป็นผลที่เอกสารข้อเสนอรายงาน ไม่ใช่การทดสอบของผมหรือผลอิสระเพิ่มเติม

แบบเดิมบน JDK 25 ที่เริ่มฮีปเล็กและไม่เตรียมพื้นที่ล่วงหน้า ตอบครั้งแรกใน 5.86 วินาที ตาม JEP 545 แปลว่าเปิดบริการได้เร็ว แต่ในกรณีศึกษาเดียวกันใช้เวลาวอร์มประมาณ 80 วินาที แปลว่าความเร็วของคำตอบยังไม่นิ่งอยู่อีกระยะ เพราะต้องทยอยขยายและเตรียมหน่วยความจำ

เมื่อเปลี่ยนเป็นฮีปใหญ่และเตรียมพื้นที่ล่วงหน้า ผลใน JEP 545 ใช้เวลาเปิด 9.45 วินาที แปลว่ารอคำตอบแรกนานขึ้น แต่กรณีศึกษานี้วอร์มเสร็จหลังช่วงเพิ่มงาน 10 วินาที แปลว่าการเตรียมแรมไว้ช่วยช่วงรับงาน แม้ต้องจ่ายด้วยเวลาเปิดแอป

แนวทางที่เสนอใหม่ให้เวลาเปิด 5.84 วินาที ในกรณีศึกษา JEP 545 แปลว่าใกล้แบบฮีปเล็กเดิม ขณะเดียวกันวอร์มเสร็จหลังช่วงเพิ่มงาน 10 วินาที ในการทดลองเดียวกัน แปลว่าได้ช่วงวอร์มใกล้แบบเตรียมฮีปใหญ่ โดยไม่ต้องรอเปิดนานเท่าแบบนั้น

คำกล่าวว่า startup ลดเกือบ 40% ใน JEP 545 จึงหมายถึงเทียบกับแบบฮีปใหญ่ที่เตรียมพื้นที่ก่อนเปิด ส่วนคำกล่าวว่า warmup ลดเกือบ 90% หมายถึงเทียบกับแบบฮีปเล็กที่ไม่เตรียมพื้นที่ล่วงหน้า JavaRubberDuck สรุปตัวเลขชุดนี้จาก JEP อีกที ไม่ได้เพิ่มผลทดลองอิสระ ตัวเลขสองอย่างมีฐานเปรียบเทียบคนละแบบครับ

การวอร์มในกรณีศึกษานี้วัดด้วย P99 คือเวลาตอบที่ครอบคลุมคำขอส่วนใหญ่และสะท้อนกลุ่มที่ตอบช้า JEP 545 ใช้เกณฑ์ต่ำกว่า 20 มิลลิวินาทีอย่างสม่ำเสมอ แปลว่าวัดความนิ่งของบริการด้วย ไม่ใช่ดูเฉพาะค่าเฉลี่ย เครื่องมือทดสอบค่อย ๆ เพิ่มงานก่อนรับงานเต็ม จึงไม่ควรยกผลนี้ไปอ้างว่าแอปจะรับโหลดเต็มทันทีที่เปิด

สำหรับการแบ่งทรัพยากร JEP 546 ทดลองหลาย JVM หรือโปรแกรมตัวรัน Java ในคอนเทนเนอร์เดียว คอนเทนเนอร์คือสภาพแวดล้อมรันงานที่กำหนดทรัพยากรไว้ การทดลองใช้แรม 16 GB แปลว่าทุกโปรแกรมต้องอยู่ร่วมกันภายใต้พื้นที่จำกัด เมื่อเพิ่มงานฐานข้อมูล โปรแกรมเดิมย่อฮีปให้ แต่ใช้ CPU เก็บกวาดมากขึ้น และทั้งเวลาตอบกับปริมาณงานที่ทำได้แย่ลง

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

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

เสียงสนับสนุน มาจาก Erik Österlund ผ่าน JEP 545 ที่คาดว่าภาพรวมจะเป็นผลดีต่อเวลาเปิดและวอร์ม ส่วน JEP 546 ตั้งเป้าให้ได้ความเร็วใกล้ฮีปที่คนจูนอย่างดี JavaRubberDuck รายงานไปในทิศทางเดียวกันว่าแนวทางคู่นี้มุ่งลดการตั้งค่าฮีปด้วยมือ

เสียงเตือนอยู่ในข้อเสนอเอง ไม่พบผู้คัดค้านอิสระที่ระบุชื่อในแหล่งชุดนี้ JEP 545 เตือนว่าแอปที่จูนโดยคาดว่าจะเริ่มด้วยฮีปใหญ่ อาจวอร์มช้าลงหลังเปลี่ยนนโยบาย ส่วน JEP 546 เตือนเรื่องใช้แรมเพิ่มและกระทบโปรแกรมอื่น จึงไม่มีหลักฐานให้แต่งว่าชุมชนแบ่งเป็นสองฝ่าย

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

อีกจุดคือบทกรณีศึกษาใน JEP 545 ยังใช้ชื่อสถานการณ์ว่า JDK NN เป็นตัวแทนชื่อรุ่น แม้ข้อมูลด้านบนระบุรุ่นเป้าหมายแล้ว จึงควรเรียกตัวเลขว่า “ผลของแนวทางที่เสนอ” มากกว่าผลรุ่นสมบูรณ์ เอกสารยังระบุด้วยว่าการจัดการหน่วยความจำไม่จำเป็นต้องเหมือนกันทุกระบบปฏิบัติการ

ส่วนที่ยังไม่มีคำตอบคือแอปของคุณจะวอร์มเร็วขึ้นแค่ไหน และเปลี่ยนเป็นเงินประหยัดจริงเท่าไร ผล PetClinic ใน JEP 545 กับผลแบ่งทรัพยากรใน JEP 546 ตอบแทนระบบงานจริงทุกแบบไม่ได้ แหล่งชุดนี้ยังไม่ให้ผลจากธุรกิจไทย หรือกำหนดปล่อยรุ่นสมบูรณ์ที่นำไปวางแผนอัปเกรดได้

แล้วเราควรทำอะไร

ขั้นต่อไปนี้เป็นคำแนะนำจากข้อแลกเปลี่ยนในเอกสารครับ ยังไม่ใช่คำสั่งให้เปลี่ยนระบบจริงทันที ทั้ง JEP 545 และ JEP 546 ยังอยู่ขั้นเสนอให้บรรจุ จึงควรเก็บข้อมูลเดิมไว้เทียบและทดลองแยกก่อน

คนทั่วไปและเจ้าของกิจการที่ไม่ได้ดูแลระบบเอง

1. ถามผู้ดูแลว่าระบบใช้ Java และ ZGC หรือไม่ก่อนผูกข่าวนี้กับปัญหาที่เจอ จดงานที่ช้าหลังเริ่มบริการ พร้อมเวลาที่เริ่มนิ่ง เพื่อใช้คุยเรื่อง startup กับ warmup ตามนิยามของ JEP 545
2. ขอให้ทีมรายงานทั้งเวลาตอบช่วงเริ่มต้นและช่วงรับงานตามปกติ อย่าขอแค่คำตอบว่าเปิดระบบได้เร็วขึ้นหรือยัง เพราะ JEP 545 วัดสองช่วงนี้แยกกัน
3. รอผลทดสอบของระบบตัวเองก่อนอนุมัติคำกล่าวเรื่องประหยัดค่าใช้จ่าย ตัวเลขใน JavaRubberDuck เป็นการรายงานกรณีศึกษาของ JEP ไม่ใช่หลักฐานว่าธุรกิจคุณจะได้ผลเท่ากัน

ทีมดูแลระบบหรือ ops ซึ่งรับผิดชอบการรันบริการ

1. เก็บค่าปัจจุบันของ -Xms, -Xmx และการเตรียมหน่วยความจำล่วงหน้า พร้อมวัดแรม CPU และเวลาตอบ ใช้เป็นฐานเปรียบเทียบ เพราะ JEP 545 เตือนว่าค่าที่เคยจูนไว้อาจต้องทบทวน
2. เมื่อตัวซอฟต์แวร์ที่ใช้ทดสอบรองรับ ให้เลือก ZGC และเปิด -XX:+ZAdaptiveHeapSizing อย่างชัดเจนในสภาพทดสอบ ตรวจระบบปฏิบัติการด้วย อย่าคาดหวังประโยชน์จากหน่วยความจำใหญ่เหมือนกันทุกเครื่อง ตามเงื่อนไขของ JEP 545
3. ทดลองงานหนักพร้อมโปรแกรมข้างเคียง แล้วติดตามทั้งแรมและ CPU ไม่ดูแค่บริการเดียว การแบ่งพื้นที่ใน JEP 546 มีช่วงที่ยอมให้ประสิทธิภาพลดเพื่ออยู่ร่วมกันได้ จึงต้องตรวจว่ายังผ่านเกณฑ์บริการของทีม

นักพัฒนาและผู้จัดการงบประมาณ

1. นักพัฒนาควรสร้างงานทดสอบที่ใกล้พฤติกรรมจริง รวมช่วงเปิดและช่วงเพิ่มปริมาณงาน อย่าใช้คำตอบแรกแทนผลวอร์ม เพราะวิธีศึกษาใน JEP 545 ติดตามเวลาตอบจนคงที่
2. ถ้าจะปรับ -XX:ZGCIntensity ให้บันทึกว่าเลือกเพิ่มแรมหรือลดแรมเพื่อแลกกับ CPU อย่างไร ตาม JEP 546 ค่านี้บอกความต้องการเชิงสมดุล ไม่ใช่การล็อก CPU เป็นเปอร์เซ็นต์
3. ผู้จัดการควรให้ทีมสรุปผลประสิทธิภาพกับต้นทุนจริงร่วมกันก่อนเปลี่ยนการจัดสรรทรัพยากร ใช้เป้าหมายการลดงานจูนใน JEP 546 เป็นเหตุผลตั้งโครงการทดลอง ไม่ใช้แทนผลตอบแทนที่วัดแล้ว

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

ความคุ้มของแรมควรวัดจากงานที่ทำได้และเวลาที่คนต้องรอ มากกว่าตัวเลขขนาดฮีปเพียงค่าเดียวครับ ให้ติดตามผลการทบทวนวันที่ 14 ตุลาคม 2026 ตามหน้า JDK 28 แปลว่าเป็นหมุดหมายของข้อเสนอ ไม่ใช่วันปล่อยใช้งาน แล้วจับตาว่านโยบายกับเงื่อนไขเปิดใช้ใน JEP 546 เปลี่ยนระหว่างพัฒนาหรือไม่

ระบบงานที่คุณดูแลเคยเสียเวลารอหลังเปิดบริการ หรือเสียเงินกับการเผื่อแรมมากกว่ากัน?

Recap

• เกิดอะไรขึ้น: ข้อเสนอปรับ ZGC ของ Erik Österlund ยังอยู่ขั้น Proposed to Target เพื่อเข้า JDK 28 ตาม JEP 545 และ JEP 546
• ตัวเลขที่จำ: ผลวอร์มลดเกือบ 90% เป็นคำกล่าวจากกรณีศึกษา JEP 545 แปลว่าเร็วขึ้นในสภาพทดลองนั้น ไม่ใช่คำรับรองทุกระบบ
• เงื่อนไขสำคัญ: การปรับขนาดเป็นตัวเลือก ต้องเปิด -XX:+ZAdaptiveHeapSizing ร่วมกับการเลือก ZGC ตาม JEP 546
• ใครเตือน: ผู้เสนอผ่าน JEP 545 เตือนเรื่องจูนใหม่ และ JEP 546 เตือนเรื่องใช้แรมเพิ่ม ไม่มีเสียงคัดค้านอิสระในแหล่งชุดนี้
• ยังไม่รู้: ผลของแอปคุณ เงินบาทที่ประหยัดจริง และวันปล่อยรุ่นสมบูรณ์ แหล่งที่อ่านยังไม่ให้คำตอบ
• ผลต่อคนไทย: ใช้ข่าวนี้ตั้งโจทย์ทดลองเรื่องเวลารอกับต้นทุน ไม่ใช้เปอร์เซ็นต์ความเร็วแทนส่วนลดบิล
• จับตา: ผลทบทวนข้อเสนอวันที่ 14 ตุลาคม 2026 ตามหน้ารวมรุ่นเป้าหมาย แปลว่ายังต้องติดตามสถานะต่อ
• แหล่งอ่านต่อ: 1 — JEP 545, 2 — JEP 546, 3 — JavaRubberDuck, 4 — JDK 28