Tôi đã từng nghĩ rằng nó không phải, nhưng hôm qua tôi phải làm điều đó. Đây là một ứng dụng sử dụng Akka (một triển khai hệ thống tác nhân cho JVM) để xử lý các công việc không đồng bộ. Một trong những diễn viên thực hiện một số thao tác PDF và vì thư viện bị lỗi, nên StackOverflowErrormọi lúc mọi nơi đều chết .
Khía cạnh thứ hai là Akka được cấu hình để tắt toàn bộ hệ thống diễn viên của nó nếu có bất kỳ lỗi nghiêm trọng nào của JVM (ví dụ StackOverflowError) bị bắt.
Khía cạnh thứ ba là hệ thống diễn viên này được nhúng bên trong một ứng dụng web (đối với WTF-ish, di sản, lý do), vì vậy khi hệ thống diễn viên bị tắt, ứng dụng web không hoạt động. Hiệu quả ròng là trên một StackOverflowErrorứng dụng xử lý công việc của chúng tôi trở thành một ứng dụng web trống.
Như một cách khắc phục nhanh, tôi đã phải bắt quả tang StackOverflowError, để nhóm chủ đề của hệ thống diễn viên không bị phá hủy. Điều này khiến tôi nghĩ rằng đôi khi có thể gặp phải những lỗi như vậy, đặc biệt là trong những bối cảnh như thế này? Khi có một nhóm xử lý các tác vụ tùy ý? Không giống như OutOfMemoryErrortôi không thể tưởng tượng làm thế nào một người StackOverflowErrorcó thể để một ứng dụng ở trạng thái không nhất quán. Ngăn xếp bị xóa sau một lỗi như vậy, vì vậy tính toán có thể tiếp tục bình thường. Nhưng có lẽ tôi đang thiếu một cái gì đó quan trọng.
Ngoài ra, hãy lưu ý rằng tôi là tất cả để sửa lỗi ngay từ đầu (vì thực tế tôi đã sửa một SOE trong cùng ứng dụng này vài ngày trước), nhưng tôi thực sự không biết khi nào loại tình huống có thể phát sinh.
Tại sao nên khởi động lại quy trình JVM thay vì bắt StackOverflowError, đánh dấu công việc đó là thất bại và tiếp tục với công việc của tôi?
Có bất kỳ lý do thuyết phục để không bao giờ bắt các doanh nghiệp nhà nước? Ngoại trừ "thực hành tốt nhất", đó là một thuật ngữ mơ hồ không cho tôi biết gì.
StackOverflowExceptions thường là do một chuỗi các cuộc gọi phương thức không kết thúc - tăng không gian ngăn xếp sau đó sẽ làm tăng chi phí bộ nhớ của một luồng mới mà không có lợi ích.
:-)