Điều cần xem xét khi viết một chương trình java được cho là chạy 'mãi mãi'

Question

Tôi phải viết một chương trình được cho là chạy 'mãi mãi', có nghĩa là chương trình sẽ không chấm dứt thường xuyên. Cho đến bây giờ, tôi luôn viết các chương trình sẽ chạy và chấm dứt vào cuối ngày. Chương trình phải thực hiện một số đồng bộ hóa, tạm dừng n phút và đồng bộ hóa lại.

AFAIK sẽ không có vấn đề gì với việc triển khai hiện tại của tôi và về lý thuyết nó sẽ chạy tốt, nhưng tôi thiếu kinh nghiệm thực tế.

Vì vậy, có bất kỳ 'mẫu' hay phương pháp hay nhất nào để viết các chương trình java rất hiệu quả và tài nguyên có thời gian chạy rất dài không? Điều gì có thể là vấn đề có thể xảy ra sau ví dụ một tháng/năm của thời gian chạy?

Một số nền:

• Java: 1,7 nhưng biên soạn xuống 1,5
• Hệ điều hành: Windows (phiên bản chính xác là không chắc chắn chưa)

Cảm ơn trước

Answer 1

Just một đống não của tất cả những điều tôi đã phải ghi nhớ khi viết loại ứng dụng này.

Tránh rò rỉ bộ nhớ

Tôi đã có một ứng dụng có thể chạy một lần vào giữa ngày, mỗi ngày, và trong đó tôi đã có một FileWriter. Tôi đã không đóng cửa đúng cách, và sau đó chúng tôi bắt đầu tự hỏi tại sao máy ảo của chúng tôi sẽ biến mất sau một vài tuần. Rò rỉ bộ nhớ có thể đến dưới dạng tiếng ồn thực sự, với một trong những ví dụ phổ biến nhất là bạn không de-reference một đối tượng phù hợp. Ví dụ: sử dụng trường của lớp làm phương thức lưu trữ tạm thời. Thường thì lớp học vẫn tồn tại, và do đó, các tham chiếu. Điều này khiến bạn bị đối tượng, ngồi trong ký ức và không làm gì cả.

Sử dụng đúng loại Scheduler

tôi đã sử dụng một java Timer trong ứng dụng đó, và sau đó tôi biết được rằng nó tốt hơn để sử dụng một ScheduledThreadPoolExecutor khi ứng dụng khác đã được thay đổi đồng hồ hệ thống. Vì vậy, nếu bạn có kế hoạch giữ nó hoàn toàn dựa trên Java, tôi khuyên bạn nên sử dụng nó trên một bộ đếm thời gian cho tất cả các lý do chi tiết trong this question.

Quan tâm đến việc sử dụng bộ nhớ và môi trường của bạn

Nếu ứng dụng của bạn đang tải một lượng lớn dữ liệu mỗi ngày, và bạn có các ứng dụng khác chạy trên cùng một máy chủ, bạn có thể muốn cẩn thận về thời gian. Ví dụ, nói vào giữa ngày, ba trong số các ứng dụng chạy hoạt động theo lịch trình của họ, tôi sẽ nói chạy nó tại bất kỳ lúc nào khác có lẽ sẽ là một động thái thông minh. Hãy chú ý đến môi trường mà bạn đang thực hiện mã của bạn trong.

xử lý

Có thể bạn muốn cấu hình ứng dụng của bạn để cho bạn biết nếu có điều gì đã đi sai, mà không cần ứng dụng phá vỡ Lỗi.Nếu nó chạy vào một thời điểm nhất định vài giờ một lần, điều đó có nghĩa là mọi người có thể phụ thuộc vào nó, vì vậy tôi sẽ có một hàm trong mã Java của bạn gửi email cho bạn, nêu chi tiết bản chất của ngoại lệ.

Làm cho nó cấu hình

lần nữa, nếu nó cần phải chạy ở các điểm khác nhau trong ngày, bạn không muốn phải kéo điều xuống trong một vài giờ để làm việc ra một số thay đổi nhỏ để ma cua ban. Thay vào đó, hãy chuyển nó thành tệp thuộc tính java, hoặc vào một Cấu hình XML (hoặc thực sự, bất cứ điều gì). Ưu điểm của việc này là bạn có thể cập nhật chương trình của mình và bắt đầu và chạy nó trước khi bất kỳ ai thực sự nhận thấy sự khác biệt.

Hãy sợ static từ khóa

Đó bad boy sẽ làm cho đối tượng tồn tại, ngay cả khi bạn phá hủy tài liệu tham khảo mẹ. Nó là mẹ của tất cả các rò rỉ bộ nhớ nếu bạn không cẩn thận với nó. Nó tốt cho hằng số, và những thứ bạn biết không cần thay đổi và cần tồn tại trong dự án để chạy tốt, nhưng nếu bạn sử dụng nó cho các giá trị ngẫu nhiên bên trong một dự án, bạn sẽ nhanh chóng tự hỏi tại sao ứng dụng bị lỗi vài giờ một lần thay vì syncing.

Đạo cụ cho @ X86 để nhắc tôi về điều đó.

Answer 2

Rò rỉ bộ nhớ có thể là vấn đề lớn nhất. Đảm bảo rằng không có tài liệu tham khảo dài hạn nào được tổ chức sau khi lặp lại logic của bạn. Ngay cả một đối tượng tương đối nhỏ được tham chiếu mãi mãi, sẽ làm cạn kiệt bộ nhớ cuối cùng là (và tệ hơn, nó sẽ khó phát hiện hơn trong quá trình kiểm tra nếu tốc độ tăng trưởng là 1GB/tháng). Một cách tiếp cận có thể giúp là sử dụng chức năng chụp nhanh của profilers: chụp nhanh trong khi tạm dừng, để đồng bộ hóa chạy một vài lần và chụp lại một lần nữa. So sánh những điều này nên hiển thị đồng bằng giữa các đồng bộ hóa, hy vọng sẽ bằng không.

Bảo trì bộ nhớ cache là một vấn đề khác. Kích thước tổng thể của một bộ nhớ cache cần phải được giới hạn nghiêm ngặt (trong khi thường bạn có thể lấy đi mà không có trong các chương trình chạy ngắn, bởi vì mọi thứ được nhìn thấy sẽ đủ nhỏ để không gây ra vấn đề). Không kém phần quan trọng trong việc xóa bộ nhớ cache - nói chung, mọi thứ được lưu trong bộ nhớ cache sẽ trở nên cũ tại một số điểm trong khi chương trình của bạn vẫn đang chạy và bạn cần có khả năng phát hiện điều này và thực hiện hành động thích hợp. Điều này có thể phức tạp tùy thuộc vào nguồn dữ liệu được lưu trữ ở đâu.

Điều cuối cùng tôi sẽ đề cập đến là xử lý ngoại lệ. Đối với các quy trình chạy ngắn, nó thường đủ để cho phép quá trình chết khi một ngoại lệ gặp phải, vì vậy vấn đề có thể được giải quyết và ứng dụng chạy lại. Với quy trình chạy dài, bạn có thể cần phải phòng thủ hơn thế. Hãy xem xét chạy các phần của chương trình của bạn trong các chủ đề, có thể được khởi động lại * nếu/khi chúng không thành công. Bạn có thể cần một mô-đun giám sát kiểu, kiểm tra rằng mọi thứ khác vẫn còn timbeating và khởi động lại nó nếu không. Nếu thích hợp với cấu trúc của bạn, điều này có thể dễ dàng hơn nhiều để đạt được với các thư viện kiểu diễn viên hơn là các trình thực thi chuẩn của Java. Và nếu có thể, bạn có thể muốn có móc (có thể bị lộ trên JMX/MBeans) cho phép bạn sửa đổi hành vi một chút, để cho phép hack/workaround ngắn hạn bị ảnh hưởng mà không phải mang lại quá trình. Mặc dù điều này đòi hỏi khá một số lượng tầm nhìn xa để dự đoán chính xác những gì đang diễn ra để đi sai trong vài tháng ...

* hay đúng hơn, công việc có thể được khởi động lại trong chủ đề khác