Open Liberty รองรับ Java 27 แล้ว แอปบนคลาวด์กล่องเล็กต้องเช็กแรม

Open Liberty 26.0.0.10 รองรับ Java รุ่นใหม่แล้ว แปลว่าแอปบริษัทมีทางเลือกอัปเกรดเพิ่ม ตามประกาศ Open Liberty เมื่อวันที่ 6 ตุลาคม 2026 ครับ แต่ประกาศเดียวกันเตือนว่าเครื่องที่มีทรัพยากรจำกัดอาจมีพฤติกรรมจัดการหน่วยความจำต่างจากเดิม

รุ่นที่รองรับเพิ่มคือ Java 27 ซึ่งเป็นชุดเครื่องมือและระบบสำหรับพัฒนาและรันแอป Java แปลว่าเรื่องนี้อยู่เบื้องหลังแอป ไม่ได้ให้พนักงานทุกคนติดตั้งอะไรบนมือถือ ตามOpen Liberty การเปลี่ยนสำคัญอยู่ที่ตัวเก็บคืนหน่วยความจำอัตโนมัติ ซึ่งอาจกระทบแรมและเวลารอของแอปบนเครื่องเล็ก

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

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

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

Java รุ่นดังกล่าวมี 9 JEPs ตาม Open Liberty เพียงแหล่งเดียวในชุดข้อมูลนี้ แปลว่ามีข้อเสนอเปลี่ยนแปลงที่นำมารวมในรุ่นนี้หลายรายการ JEP คือเอกสารอธิบายสิ่งที่จะปรับใน Java แต่ประกาศ แยกไว้ว่ามีทั้งรายการทดลองและรายการที่ส่งมอบเต็มรูปแบบ อย่าเหมาว่าทุกอย่างพร้อมใช้จริงเท่ากัน

OpenJDK ระบุว่าเปิดให้ใช้ทั่วไปเมื่อวันที่ 15 กันยายน 2026 แปลว่าพ้นขั้นรอเปิดตัวแล้ว ส่วน Oracle ระบุว่าบริการ Java Management Service มีรุ่นนี้ให้ใช้ด้วย แต่ Open Liberty ย้ำว่าเป็น non-LTS คือรุ่นที่ไม่ได้จัดเป็นรุ่นสนับสนุนระยะยาว

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

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

คนทำงานทั่วไปไม่จำเป็นต้องจำชื่อส่วนประกอบทั้งหมดครับ ถ้าที่ทำงานใช้ระบบนี้ สิ่งที่ควรให้ทีม IT ตรวจคือแอปตอบสนองต่างไปหรือใช้ทรัพยากรต่างไปหลังอัปเกรดหรือไม่ เพราะ Open Liberty เตือนเฉพาะเรื่องพฤติกรรมที่อาจเปลี่ยนในสภาพแวดล้อมจำกัด ไม่ได้ประกาศว่าแอปทุกตัวจะช้าลง

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

กลุ่มที่ผู้พัฒนาระบุให้ระวังคือเครื่องที่มีหน่วยประมวลผลเดียวหรือหน่วยความจำน้อย รวมถึง container หรือพื้นที่รันแอปที่แยกสภาพแวดล้อมออกจากกัน ตามประกาศ Open Liberty คำนี้ไม่ใช่ขนาดเครื่องแน่นอนในตัวเอง ต้องให้ทีมดูข้อจำกัดจริงของพื้นที่ที่แอปทำงานด้วย

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

ทำงานยังไง

Garbage collector หรือ GC คือส่วนที่หาและคืนพื้นที่หน่วยความจำซึ่งแอปเลิกใช้แล้ว ระบบรัน Java ที่เรียกว่า JVM จัดการงานนี้ให้อัตโนมัติ ตาม OpenJDK นักพัฒนาจึงไม่ต้องจัดการคืนพื้นที่ทุกชิ้นเอง และมีตัวเก็บคืนหน่วยความจำหลายแบบให้เหมาะกับงานต่างกัน

ตัวที่ชื่อ G1 ออกแบบให้สมดุลระหว่างปริมาณงานที่ทำได้กับเวลารอตอบสนอง ตาม JEP ส่วน Serial เป็นอีกทางเลือกซึ่งเคยได้เปรียบในเครื่องจำกัดทรัพยากร Parallel เป็นทางเลือกที่เน้นปริมาณงานที่ทำได้ เราจึงไม่ควรตัดสินจากชื่อว่าตัวไหนใหม่กว่าหรือดูเก่งกว่า

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

ก่อนหน้านี้ JVM เคยเลือก Serial ให้เครื่องที่มีหน่วยประมวลผลเดียว ตาม JEP แปลว่าเครื่องเล็กบางเครื่องได้รับทางเลือกต่างจากเครื่องใหญ่โดยอัตโนมัติ เมื่ออัปเกรดครั้งนี้ แอปเดิมและงานเดิมจึงอาจทำงานด้วยตัวจัดการหน่วยความจำคนละตัว แม้ทีมไม่ได้แก้โค้ดแอป

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

จุดหักมุม: เปลี่ยนค่าเริ่มต้น ไม่ได้บังคับให้ทุกแอปเปลี่ยนตาม

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

Open Liberty ระบุชื่อ flag หรือค่าตอนเริ่มโปรแกรมไว้ว่า -XX:+UseSerialGC และ -XX:+UseParallelGC สำหรับเลือกกลับไปใช้ตัวเดิม แต่ต้องรู้ก่อนว่าเครื่องของคุณใช้ตัวไหน ไม่ควรเลือกตามชื่อที่เห็นในข่าว

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

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

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

สิ่งที่วัดควรมีมากกว่าแอปเปิดติดหรือไม่ Memory footprint คือพื้นที่หน่วยความจำที่ใช้ latency คือเวลารอตอบสนอง throughput คือปริมาณงานที่ทำได้ในช่วงเวลา และ startup time คือเวลาเริ่มระบบ ทั้งหมดเป็นด้านที่ JEP ของ OpenJDK ระบุในการประเมิน GC แปลว่าประหยัดแรมอย่างเดียวไม่ได้ตอบทุกความต้องการ

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

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

ในรายการนั้นมีช่องโหว่ประเภท server-side request forgery คือการทำให้ฝั่งเซิร์ฟเวอร์ส่งคำขอที่ไม่ควรส่ง ตามประกาศ Open Liberty เพียงแหล่งเดียวในชุดนี้ ผู้พัฒนาระบุว่ากระทบชุดฟีเจอร์บางกลุ่ม แปลว่าต้องตรวจส่วนประกอบที่เปิดใช้จริง ไม่ใช่สรุปว่าทุกระบบมีขอบเขตเสี่ยงเท่ากัน

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

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

เสียงสนับสนุนมาจาก OpenJDK ครับ JEP ซึ่งมี Thomas Schatzl เป็นเจ้าของ ระบุว่าการปรับปรุงทำให้ G1 แข่งขันกับ Serial ได้ในทุกขนาดพื้นที่หน่วยความจำของแอป เอกสารยังระบุว่าได้ลดการใช้หน่วยความจำส่วนที่ระบบรันจัดการเองลงจนเทียบเคียง Serial ข้อเสนอจึงมีเหตุผลด้านประสิทธิภาพรองรับตามคำอธิบายของผู้พัฒนา

ข้อทักท้วงเรื่องเครื่องเล็กมาจาก Open Liberty ซึ่งประกาศ ให้ผู้ใช้ระวังพฤติกรรม GC ที่ต่างจากรุ่นก่อน ขณะเดียวกัน OpenJDK เองยอมรับในหัวข้อความเสี่ยงว่าแอปบางตัวในสภาพแวดล้อมจำกัดอาจยังเหมาะกับ Serial ที่สุด นี่คือข้อยกเว้นที่มีชื่อแหล่งชัดเจน ไม่ได้มีผู้คัดค้านนิรนาม

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

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

สิ่งที่ยังไม่รู้คือผลกับแอปของคุณครับ แหล่งชุดนี้ไม่ได้แจกผลวัดรายแอปที่ใช้ตัดสินแทนทีมได้ และไม่มีตัวเลขค่าใช้จ่ายในไทย ผมยังไม่ได้ทดสอบเองด้วย ส่วนระยะสนับสนุนที่ตรงกับผู้ให้บริการของบริษัทต้องตรวจเงื่อนไขเพิ่มเติม เพราะคำว่า non-LTS ในบล็อก Open Liberty ไม่ได้บอกกำหนดสัญญาของทุกผู้ขาย

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

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

คนทั่วไปและเจ้าของธุรกิจ

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

ทีม IT และคนดูแลงบระบบ

1. ทำรายการเวอร์ชันและค่า GC ที่ใช้อยู่จริงก่อน อย่าเดาว่าเครื่องเล็กทั้งหมดใช้ Serial และอย่าเดาว่าค่าที่เคยตั้งยังอยู่หลังอัปเกรด
2. ทดลองใน staging หรือระบบทดสอบก่อนเปิดให้ผู้ใช้จริง โดยรักษาข้อจำกัดทรัพยากรและชุดงานให้เปรียบเทียบกับของเดิมได้
3. วัดแรม เวลาตอบสนอง ปริมาณงาน และเวลาเริ่มระบบร่วมกัน เก็บทั้งค่าก่อนและหลัง แล้วจึงพิจารณาว่าจำเป็นต้องเปลี่ยนทรัพยากรหรือไม่
4. อ่านรายการ CVE และขอบเขตฟีเจอร์ในประกาศรุ่นนี้ ให้ครบ ระบุส่วนที่เกี่ยวกับระบบบริษัท และจัดแผนทดสอบแพตช์ด้วย
5. อย่าย้าย production หรือระบบที่คนใช้งานจริงไป non-LTS เพียงเพราะมีรุ่นใหม่ กำหนดเหตุผล เจ้าของงาน และวิธีกลับไปสภาพเดิมก่อนตัดสินใจ

นักพัฒนาและผู้ดูแลการเริ่มโปรแกรม

1. ตรวจว่ามีการเลือก GC ชัดเจนหรือปล่อยค่าเริ่มต้น ตาม JEP ค่าที่ผู้ใช้กำหนดเองยังมาก่อนการเลือกอัตโนมัติ
2. ถ้าต้องเทียบพฤติกรรมเดิม ให้ทดลองตัวเดิมที่ยืนยันแล้วโดยใช้ชื่อ flag ตาม Open Liberty คือ -XX:+UseSerialGC หรือ -XX:+UseParallelGC เลือกให้ตรงกับกรณีของระบบ
3. บันทึกผลทดสอบพร้อมเงื่อนไขเครื่องและงานที่ใช้ ส่งให้คนดูแลงบอ่านได้ด้วยคำธรรมดา ถ้าผลยังไม่ชัด ให้บอกว่ายังไม่ชัดแทนการรับรองว่าไม่มีผลกระทบ

ผมมองว่า…

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

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

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

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

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

Recap

• เกิดอะไรขึ้น: Open Liberty รุ่นใหม่รองรับ Java ใหม่และมีรายการแก้ช่องโหว่ ตามประกาศผู้พัฒนา
• ตัวเลขที่จำ: JEP 523 แปลว่าค่าเริ่มต้นเปลี่ยนเป็น G1 ทุกสภาพแวดล้อมเมื่อไม่ได้เลือกเอง ตามOpenJDK
• ใครเห็นต่าง: OpenJDK ให้เหตุผลด้านประสิทธิภาพ ส่วน Open Liberty เตือนเครื่องจำกัดทรัพยากร ไม่ได้มีฝ่ายใดยืนยันว่าทุกแอปกินแรมเพิ่ม
• ยังไม่รู้: ผลกับแอปของคุณ ปริมาณแรมที่ต่าง และค่าใช้จ่ายในไทย ไม่มีผลทดลองของผมในบทความนี้
• กระทบคุณอย่างไร: ถ้าระบบเกี่ยวข้อง ขอผลทดสอบก่อนเปลี่ยนเครื่องหรือเพิ่มงบ พร้อมตรวจขอบเขตช่องโหว่
• สิ่งที่ต้องจับตา: ผล staging ภายใต้งานเดิม และเหตุผลที่ทีมจะเลือก non-LTS ไปใช้จริง
• แหล่งข้อมูล: 1 — Open Liberty, 2 — OpenJDK JDK, 3 — JEP, 4 — Oracle