ฉันเคยคิดว่ามันไม่ได้ แต่เมื่อวานนี้ฉันต้องทำ มันเป็นแอพพลิเคชั่นที่ใช้Akka (ระบบการทำงานของนักแสดงสำหรับ JVM) เพื่อประมวลผลงานอะซิงโครนัส หนึ่งในนักแสดงทำการจัดการไฟล์ PDF บางส่วนและเนื่องจากห้องสมุดมีรถบั๊กมันก็ตายด้วยStackOverflowErrorทุก ๆ คราว
ด้านที่สองคือ Akka ได้รับการกำหนดค่าให้ปิดระบบนักแสดงทั้งหมดหากมีข้อผิดพลาดร้ายแรง JVM (เช่น StackOverflowError)
ประเด็นที่สามคือระบบนักแสดงนี้ถูกฝังอยู่ภายในเว็บแอพ (สำหรับ WTF-ish, มรดก, เหตุผล) ดังนั้นเมื่อระบบนักแสดงปิดตัวลงแอปพลิเคชันเว็บจะไม่ ผลกระทบสุทธิคือในStackOverflowErrorแอปพลิเคชันการประมวลผลงานของเรากลายเป็นเพียงเว็บแอปที่ว่างเปล่า
การแก้ไขอย่างรวดเร็วฉันต้องจับStackOverflowErrorการโยนเพื่อให้กลุ่มเธรดของระบบนักแสดงไม่ฉีกขาด นี่ทำให้ฉันคิดว่าบางทีมันก็โอเคที่จะจับข้อผิดพลาดโดยเฉพาะอย่างยิ่งในบริบทเช่นนี้? เมื่อใดที่มีเธรดพูลกำลังประมวลผลงานตามอำเภอใจ? ซึ่งแตกต่างจากOutOfMemoryErrorฉันไม่สามารถจินตนาการว่าStackOverflowErrorสามารถออกจากโปรแกรมที่อยู่ในสถานะที่ไม่สอดคล้องกัน สแต็กจะถูกล้างหลังจากข้อผิดพลาดดังกล่าวดังนั้นการคำนวณจึงสามารถดำเนินต่อได้ตามปกติ แต่บางทีฉันอาจพลาดสิ่งสำคัญไป
นอกจากนี้ขอให้สังเกตว่าฉันทั้งหมดเพื่อแก้ไขข้อผิดพลาดในสถานที่แรก (ตามความเป็นจริงฉันได้แก้ไข SOE ในแอพเดียวกันนี้เมื่อไม่กี่วันที่ผ่านมา) แต่ฉันไม่รู้จริง ๆ ว่าเมื่อใด สถานการณ์แบบนี้อาจเกิดขึ้นได้
เหตุใดจึงเป็นการดีกว่าที่จะเริ่มกระบวนการ JVM ใหม่แทนการจับStackOverflowErrorทำเครื่องหมายว่างานนั้นล้มเหลวและดำเนินธุรกิจของฉันต่อไป
มีเหตุผลที่น่าสนใจไหมที่จะไม่ใช้ SOE? ยกเว้น "แนวปฏิบัติที่ดีที่สุด" ซึ่งเป็นคำที่คลุมเครือซึ่งไม่ได้บอกอะไรเลย
StackOverflowExceptions มักเกิดจากสายโซ่ที่ไม่สิ้นสุดของการเรียกเมธอด - การเพิ่มพื้นที่สแต็กจะเพิ่มต้นทุนหน่วยความจำของเธรดใหม่โดยไม่มีประโยชน์
:-)