Java เตรียมจบยุคทดลอง Structured Concurrency แต่แอปยังไม่หายค้างทันที

Structured Concurrency ถูกเสนอให้เป็นเครื่องมือถาวรใน JDK 28 แปลว่าทีม Java อาจพ้นช่วงทดลองใช้การจัดกลุ่มงานพร้อมกัน โดยข้อเสนอย้ำว่าจะไม่เปลี่ยนรูปแบบเพิ่มเติม (OpenJDK) เครื่องมือนี้ตั้งใจลดงานที่ยังวิ่งต่อหลังคำขอหลักล้มเหลว แต่สถานะตอนนี้ยังเป็นข้อเสนอครับ (OpenJDK)

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

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

JEP คือเอกสารข้อเสนอเปลี่ยนความสามารถของ Java ส่วน JDK คือชุดเครื่องมือสำหรับพัฒนาและรันโปรแกรมภาษานี้ ข้อเสนอหมายเลข 543 อยู่ในสถานะ Proposed to Target แปลว่าเสนอให้บรรจุในรุ่นเป้าหมาย ยังไม่ใช่การยืนยันว่าฟีเจอร์ออกแล้ว (OpenJDK)

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

จุดเริ่มต้นอยู่ที่ JDK 19 แปลว่าความสามารถนี้เคยอยู่ในโมดูลบ่มเพาะก่อนเป็นส่วนทดลองของแพลตฟอร์ม (OpenJDK) จากนั้นเข้าสู่ preview ใน JDK 21 แปลว่าเปิดให้ลอง API ที่ยังมีโอกาสปรับเปลี่ยน และทดลองต่อในรุ่นถัดมา (OpenJDK)

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

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

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

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

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

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

ทำงานยังไง

คำว่า thread หมายถึงเส้นทางการทำงานที่โปรแกรมใช้เดินงานหนึ่งชิ้น ส่วน virtual thread คือเส้นทางทำงานแบบเบาที่ JDK จัดการให้ใช้ทรัพยากรร่วมกัน OpenJDK อธิบายว่าการมีเส้นทางทำงานจำนวนมากช่วยงานรอรับส่งข้อมูล แต่ก็ทำให้การดูแลชีวิตของแต่ละงานยากขึ้น (OpenJDK)

หัวใจของเครื่องมือนี้ชื่อ StructuredTaskScope ซึ่งเป็นตัวกำหนดขอบเขตของงานย่อย ขั้นตอนคือเปิดขอบเขต เริ่มงาน รอผลรวม แล้วปิดขอบเขต ก่อนออกไปทำขั้นตอนถัดไปต้องรอให้งานย่อยในขอบเขตจบทั้งหมด (เอกสาร API)

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

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

กติกาไม่ได้บังคับให้ทุกงานใช้เงื่อนไขเดียวกัน นักพัฒนาเลือก Joiner หรือตัวกำหนดวิธีรวมผลได้ เช่น รอผลสำเร็จทั้งหมด หรือเอาผลสำเร็จจากงานที่ตอบก่อนแล้วหยุดส่วนที่เหลือ การเลือกกติกาจึงต้องเริ่มจากว่าคำขอหลักต้องการอะไรจริง ๆ (เอกสาร API)

จุดหักมุม: คำว่า final ยังไม่ได้ทำให้ใช้ได้วันนี้

แต่การเสนอให้ API ถาวรยังไม่ใช่การเปิดตัวรุ่นเสร็จสมบูรณ์ครับ หน้าโครงการระบุว่ายังเปิดสายพัฒนา และมี early access หรือชุดทดลองก่อนออกจริงให้ดาวน์โหลด (หน้าโครงการ JDK)

JavaRubberDuck ชี้ว่าเมื่อรุ่นเป้าหมายออก ทีมที่เคยหลีกเลี่ยงฟีเจอร์ทดลองในระบบบริการจริงจะใช้ API นี้ได้โดยไม่ต้องเปิด --enable-preview ซึ่งเป็นตัวเลือกยอมรับความสามารถทดลอง แต่ประโยชน์นั้นเป็นเงื่อนไขในอนาคต ไม่ใช่สิ่งที่บทความนี้ประกาศว่าเกิดแล้ว (JavaRubberDuck)

และแม้รูปแบบจะถาวรแล้ว การยกเลิกก็ไม่ได้แปลว่าหยุดทันที เอกสารเตือนว่างานที่ไม่ตอบสนองต่อสัญญาณหยุดอาจทำให้ปิดขอบเขตไม่ได้โดยไม่มีกำหนด ระบบจะรอให้งานย่อยจบ แทนที่จะทิ้งมันไว้แล้วเดินต่อ (เอกสาร API)

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

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

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

JavaRubberDuck มองว่าการเห็นต้นไม้นี้เป็นประโยชน์จริงต่อการหาสาเหตุในบริการที่ใช้ virtual thread มาก (JavaRubberDuck) แต่ยังไม่มีเวลาซ่อมระบบก่อนและหลังให้เทียบ จึงควรประเมินจากความชัดของข้อมูลที่ทีมได้รับ มากกว่านำไปตั้งเป้าว่าจะแก้เหตุขัดข้องเร็วขึ้นกี่เท่า

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

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

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

ฝั่งสนับสนุนคือผู้เขียนข้อเสนอของ OpenJDK ได้แก่ Alan Bateman, Viktor Klang และ Ron Pressler ซึ่งเสนอให้ทำ API ถาวรโดยไม่เปลี่ยนเพิ่ม (OpenJDK) ส่วน Stanislav Lentsov ผู้เขียน JavaRubberDuck อธิบายว่าการปรับรูปแบบในรอบก่อนทำให้การจบช่วงทดลองเป็นไปได้ พร้อมชี้ประโยชน์ต่อทีมที่ไม่ใช้ preview ในระบบจริง (JavaRubberDuck)

แต่อีกด้านของเอกสารทางการยังระบุ StructuredTaskScope ว่าเป็น preview API (เอกสาร API) จึงมีความต่างระหว่างข้อความเสนออนาคตกับสถานะในเอกสารที่อ่านได้ตอนนี้ ไม่ควรเอาคำว่า final ในข่าวมาแทนป้ายสถานะของชุดทดลอง

ชุดแหล่งข่าวนี้ไม่มีผู้คัดค้านการทำให้ถาวรที่แสดงความเห็นโดยตรง ผมจึงไม่สร้างเสียงค้านขึ้นมาแทน แต่ข้อจำกัดจากเอกสาร Java.net เป็นหลักฐานที่ทักท้วงความคาดหวังว่าเครื่องมือจะหยุดทุกงานได้ทันที โดยระบุชัดว่างานที่ไม่ตอบรับ interrupt อาจทำให้รอปิดขอบเขตต่อไป (เอกสาร API)

วันสิ้นสุดการทบทวนคือ 13 ตุลาคม แปลว่าเป็นจุดตรวจข้อเสนอ ไม่ใช่วันเปิดตัว ตามทั้งรายงาน JavaRubberDuck และตารางบนหน้าโครงการ (JavaRubberDuck, OpenJDK) แต่ไฟล์แหล่งข่าวที่อ่านไม่ได้ให้วันออกฉบับสมบูรณ์ จึงยังระบุวันให้ทีมไทยนัดย้ายระบบไม่ได้

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

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

คนทั่วไป พนักงาน ผู้ปกครอง และนักเรียน

1. ยังไม่ต้องเปลี่ยนอุปกรณ์หรือลงเครื่องมือเพิ่มเพื่อข่าวนี้ครับ เรื่องนี้เป็น API ฝั่งโปรแกรม และแหล่งข้อมูลยังไม่ได้ประกาศฟีเจอร์สำหรับผู้ใช้แอปโดยตรง (OpenJDK)
2. หากพบหน้าจอค้าง ให้เก็บชื่อหน้าจอและสิ่งที่กำลังทำเพื่อแจ้งผู้ให้บริการ ไม่ต้องสรุปว่าเหตุเกิดจาก Java เพราะแหล่งข่าวนี้ไม่ได้ตรวจระบบของแอปที่คุณใช้
3. รอประกาศจากบริการของตัวเองก่อนคาดหวังผล ไม่มีข้อมูลในแหล่งข่าวที่ยืนยันว่าผู้ให้บริการไทยรายใดกำลังนำไปใช้

ทีม IT และนักพัฒนา Java

1. เลือกงานที่ต้องรวมผลจากบริการหลายส่วนมาทดลองในสภาพแวดล้อมทดสอบ ใช้ JDK 27 ซึ่งยังเป็น preview แปลว่าต้องยอมรับสถานะทดลองให้ชัดก่อนประเมิน (OpenJDK) หรือใช้ชุด early access ของรุ่นเป้าหมายที่หน้าโครงการให้ไว้ โดยไม่ถือว่าเป็นรุ่นเสร็จสมบูรณ์ (หน้าโครงการ)
2. ทดสอบทั้งกรณีสำเร็จ งานย่อยล้มเหลว และงานไม่ตอบรับคำสั่งหยุด ตรวจว่าการปิดขอบเขตรออะไรอยู่ เพราะเอกสารรับรองการรอให้งานจบ ไม่ได้รับรองว่าการรอนั้นสั้นเสมอ (เอกสาร API)
3. เลือกกติกาการรวมผลให้ตรงความต้องการ หากบางข้อมูลเป็นส่วนเสริม อย่าใช้กติกาล้มทั้งชุดโดยไม่คิดผลต่อหน้าจอ ผู้พัฒนาเลือก Joiner อื่นหรือจัดการความผิดพลาดในงานย่อยเพื่อคืนค่าทดแทนได้ตามเอกสาร (เอกสาร API)
4. ตั้งเวลารอให้ชัดแล้วทดสอบด้วย ค่าเริ่มต้นไม่มี timeout ซึ่งหมายถึงเพดานเวลารอ และการตั้งเพดานเริ่มนับเมื่อเปิดขอบเขต ไม่ใช่เมื่อเริ่มรอผล (เอกสาร API)
5. ฝึกอ่านภาพสถานะงานแบบต้นไม้ และวางแผนสอนทีมเรื่องเจ้าของขอบเขต เอกสารจำกัดให้ผู้เปิดขอบเขตเป็นผู้เริ่มงาน รอผล และปิดงานเอง จึงควรตรวจการใช้งานจริงมากกว่าเปลี่ยนชื่อคำสั่งจากเครื่องมือเก่า (OpenJDK, เอกสาร API)

ผู้จัดการและเจ้าของธุรกิจ

1. ยังไม่มีงานเร่งด่วนจากข่าวนี้ ให้ทีมสำรวจปัญหาปัจจุบันก่อนเปิดโครงการใหม่ แหล่งข้อมูลยังไม่ให้กำหนดออกฉบับสมบูรณ์หรือตัวเลขคืนทุน
2. ขอผลทดลองที่บอกว่ายกเลิกงานได้ถูกต้อง และตามหางานค้างได้ง่ายขึ้นอย่างไร แทนการขอแค่ผลความเร็ว เพราะเป้าหมายของข้อเสนอครอบคลุมความน่าเชื่อถือและการมองเห็นงานด้วย (OpenJDK)
3. ไม่ต้องสั่งเขียนระบบที่ทำงานดีอยู่ใหม่ทั้งหมด เครื่องมือเดิมไม่ได้ถูกประกาศให้เลิกใช้ในข้อเสนอนี้ จึงควรเลือกย้ายเฉพาะจุดที่ได้ประโยชน์ชัด (OpenJDK)

ผมมองว่า…

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

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

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

คุณภาพของแอปควรวัดรวมถึงตอนที่งานทำต่อไม่ได้ และตอนที่ระบบต้องหยุดให้เรียบร้อยด้วย จับตาผลหลังสิ้นสุดการทบทวนวันที่ 13 ตุลาคม แปลว่าให้ดูว่าข้อเสนอเปลี่ยนสถานะอย่างไร ไม่ใช่รอโหลดรุ่นสมบูรณ์ในวันนั้น (หน้าโครงการ JDK) จากนั้นค่อยดูประกาศออกจริงและเอกสาร API ว่าป้าย preview ถูกเปลี่ยนแล้วหรือยัง (เอกสาร API ปัจจุบัน)

หน้าจอไหนของแอปที่คุณใช้ประจำทำให้เสียเวลารอมากที่สุด และตอนรอคุณกำลังพยายามทำอะไรอยู่?

Recap

• เกิดอะไรขึ้น: มีข้อเสนอทำ Structured Concurrency ให้ถาวรโดยไม่เปลี่ยนรูปแบบเพิ่มเติม ตาม แหล่ง 1: OpenJDK
• รุ่นที่จำ: JDK 28 เป็นรุ่นเป้าหมาย แปลว่ายังต้องแยกข้อเสนอออกจากการเปิดตัวจริง ตาม แหล่ง 2: JavaRubberDuck
• กลไกหลัก: รวมงานเป็นชุด ยกเลิกตามกติกา และรอให้ทุกงานจบก่อนออกจากขอบเขต ตาม แหล่ง 3: เอกสาร API
• ใครเห็นต่าง: ไม่มีเสียงคัดค้านโดยตรงในแหล่งชุดนี้ แต่ข่าวพูดถึงการทำให้ถาวร ขณะที่เอกสาร API ยังติดป้าย preview
• ยังไม่รู้: วันออกฉบับสมบูรณ์ ผลลดเวลารอ และรายชื่อองค์กรไทยที่นำไปใช้
• ผลต่อคุณ: ผู้ใช้แอปรับผลทางอ้อม ทีม Java ควรทดสอบการล้มเหลว การหยุดงาน และเพดานเวลารอ
• สิ่งที่จับตา: ผลทบทวนและประกาศรุ่นจริง ตาม แหล่ง 4: หน้าโครงการ