Dành cho những người đã đọc về vùng chứa và Docker nhưng không hiểu Java đã bám vào vùng chứa như thế nào. Đầu tiên, hãy làm mới bộ nhớ của chúng ta về bộ nhớ Java . Hãy để tôi nhắc bạn rằng bộ nhớ bao gồm Stack và Heap, sử dụng RAM (bộ nhớ truy cập ngẫu nhiên) của máy chủ; khi nói thêm về bộ nhớ, chúng ta sẽ muốn nói đến RAM. Bây giờ chúng ta hãy nhìn vào mặt cắt ngang của thùng chứa. Không, tất nhiên là không, chúng ta không quan tâm đến phần mông và đùi, chúng ta sẽ xem xét cấu trúc bộ nhớ trong thùng chứa. Nó có thể được chia thành ba phần: • Bộ nhớ heap – chính heap; • Off Heap là mọi thứ không có trong heap; • Chi phí hệ điều hành là chi phí bộ nhớ để triển khai các quy trình bên trong vùng chứa. Giả sử: Chúng tôi đã phân bổ 1 Gb cho vùng chứa, trong hình sẽ là Giới hạn vùng chứa - ranh giới của nó được biểu thị bằng hình chữ nhật màu xanh lam. Chúng tôi đã phân bổ 80%, tức là 0,8 Gb, cho bộ nhớ Java trong vùng chứa và Heap đã chiếm khoảng 80% vùng chứa, tức là không ít hơn 0,8 Gb, vì OS Overhead đã chiếm một phần tài nguyên (chi phí chung) để duy trì các quá trình. Khoảng 20% vùng chứa còn lại dành cho mọi thứ không được kết nối với heap ( Off Heap ). Vùng Đã sử dụng trong hình hiển thị vùng bộ nhớ đã sử dụng để chạy ứng dụng. Bây giờ chúng ta cần nói về các tình huống khi bộ nhớ trong vùng chứa có thể hết. OutOfMemoryError Nếu mức tiêu thụ bộ nhớ của ứng dụng ( Khu vực sử dụng ) đạt đến giới hạn heap ( Heap ), chúng tôi sẽ bắt gặp OutOfMemoryError (Lỗi OOM) . Điều này nói lên rằng không có đủ dung lượng trong vùng heap, cụ thể là trong vùng bộ nhớ nơi đặt các đối tượng được tạo theo chương trình trong ứng dụng. Nếu nó vẫn chưa hoàn toàn rõ ràng, tôi sẽ giải thích nó ở mèo. Lỗi OOM là khi một con mèo hét rất lâu trước cửa ra ban công, khi cánh cửa này mở ra, nó đứng ở ngưỡng cửa và không đi về phía nào, người ta thường nói rằng con mèo bị đóng băng. Nếu bạn đẩy anh ta kịp thời, anh ta sẽ há hốc mồm và đi ra ban công để làm việc với mèo con của mình. OOM Killer Đây là một tình huống khác có thể xảy ra trong vùng chứa khi hết bộ nhớ. Nếu một chương trình nằm ngoài vùng chứa, chúng ta sẽ nhận được OutOfMemory Killer (OOM Killer) - đây là quá trình chấm dứt ứng dụng để cứu kernel khỏi bị lỗi. Nó hy sinh ứng dụng để giữ cho container hoạt động. Thực tế không phải container sẽ rơi mà ứng dụng chạy trong đó chắc chắn sẽ rơi. Điều này xảy ra nếu bạn không kiểm soát mức tiêu thụ bộ nhớ của ứng dụng Java. Một lần nữa về mèo. Nếu bạn quyết định ngủ lâu hơn vào thứ Bảy và quên cho mèo ăn, thì OOM KillerHoa đảm bảo, chậu có thể không bị hư nhưng hoa sẽ phải trồng lại. Sự khác biệt giữa Lỗi OOM và OOM Killer là gì? Bạn có thể xử lý Lỗi OOM và thực hiện một số hành động (ví dụ: mở rộng quy mô ứng dụng) và OOM Killer sẽ chỉ hủy toàn bộ quá trình. OOM Killer tương tự như kill-9 (kill trừ chín) - lệnh giết chết một tiến trình trong Linux . Vấn đề là việc triển khai vùng chứa phổ biến nhất là vùng chứa Docker , dựa trên Linux , ngay cả khi bạn chạy nó trong Windows , kernel vẫn sẽ từ Linux . Trong Linux, chúng ta quan tâm đến một khái niệm: CGroups (nhóm điều khiển tiếng Anh) - một cơ chế nhân Linux nhằm giới hạn và cô lập các tài nguyên tính toán (bộ xử lý, mạng, tài nguyên bộ nhớ, tài nguyên I/O) cho các nhóm tiến trình. Nói một cách đơn giản, cơ chế này cho phép bạn quản lý tài nguyên trong một thùng chứa, trong bộ nhớ trường hợp của chúng tôi. Java liên quan đến điều này như thế nào? Thông qua cơ chế CGroups , Java có thể bám vào bộ nhớ vùng chứa. Nhưng tất cả điều này phụ thuộc vào phiên bản Java. Ví dụ: Java 7 không biết cách sử dụng CGroups và giới hạn vùng chứa không được biết đến. Theo mặc định, kích thước heap tối đa = ¼ bộ nhớ vật lý. Nếu ứng dụng vượt quá giới hạn vùng chứa thì sẽ xảy ra OOM Killer và nếu không đặt giới hạn vùng chứa thì ứng dụng sẽ lấy bộ nhớ từ các ứng dụng khác trên máy chủ (tốt hơn là nên đặt giới hạn, nếu không mọi người sẽ mất) . Tất nhiên, bạn có thể sử dụng cài đặt heap hoặc sử dụng "hình ảnh" đặc biệt để giải quyết vấn đề này, nhưng cách dễ nhất là sử dụng đúng phiên bản Java. Các phiên bản đúng bắt đầu bằng Java 8 x131 (được chuyển từ Java 9), nó bắt đầu hiểu CGroups . Và trong Java 10, hỗ trợ cho các container đã xuất hiện: UseContainerSupport , sau này chức năng này đã được chuyển sang Java 8 x 191 . Hoặc bạn chỉ có thể sử dụng Java: 11+ . Có thể kết luận gì: Khi sử dụng bộ nhớ vùng chứa, bạn có thể nhận được OutOfMemoryError (Lỗi OOM) hoặc OutOfMemoryKiller (OOM Killer). Trong trường hợp đầu tiên, ứng dụng sẽ không gặp sự cố ngay lập tức, có thể bắt gặp Lỗi OOM, có thể thực hiện các hành động được xử lý và kiểm soát. Ví dụ: mở rộng quy mô ứng dụng. Nếu OOM Killer xảy ra, ứng dụng sẽ gặp sự cố ngay lập tức và sẽ không còn tùy chọn nào để lưu nó. Và điều tồi tệ nhất là bề ngoài bản thân thùng chứa sẽ không sao, tức là bạn thậm chí có thể không nghi ngờ rằng có thứ gì đó đã rơi ở đó. Các cơ chế Linux được sử dụng để tương tác với vùng chứa và bộ nhớ Java. Nhưng không phải mọi Java đều triển khai chúng. Để tránh sự cố đối với Java 8, bạn cần sử dụng phiên bản bắt đầu từ 131 hoặc tốt hơn là từ 191. Hoặc sử dụng Java: 11+. Để thực hành: OutOfMemoryError: hãy bắt nó nếu bạn có thể
Không, tất nhiên là không, chúng ta không quan tâm đến phần mông và đùi, chúng ta sẽ xem xét cấu trúc bộ nhớ trong thùng chứa. Nó có thể được chia thành ba phần: • Bộ nhớ heap – chính heap; • Off Heap là mọi thứ không có trong heap; • Chi phí hệ điều hành là chi phí bộ nhớ để triển khai các quy trình bên trong vùng chứa. 
Giả sử: Chúng tôi đã phân bổ 1 Gb cho vùng chứa, trong hình sẽ là Giới hạn vùng chứa - ranh giới của nó được biểu thị bằng hình chữ nhật màu xanh lam. Chúng tôi đã phân bổ 80%, tức là 0,8 Gb, cho bộ nhớ Java trong vùng chứa và Heap đã chiếm khoảng 80% vùng chứa, tức là không ít hơn 0,8 Gb, vì OS Overhead đã chiếm một phần tài nguyên (chi phí chung) để duy trì các quá trình. Khoảng 20% vùng chứa còn lại dành cho mọi thứ không được kết nối với heap ( Off Heap ). Vùng Đã sử dụng trong hình hiển thị vùng bộ nhớ đã sử dụng để chạy ứng dụng. Bây giờ chúng ta cần nói về các tình huống khi bộ nhớ trong vùng chứa có thể hết. OutOfMemoryError Nếu mức tiêu thụ bộ nhớ của ứng dụng ( Khu vực sử dụng ) đạt đến giới hạn heap ( Heap ), chúng tôi sẽ bắt gặp OutOfMemoryError (Lỗi OOM) . Điều này nói lên rằng không có đủ dung lượng trong vùng heap, cụ thể là trong vùng bộ nhớ nơi đặt các đối tượng được tạo theo chương trình trong ứng dụng. 
Nếu nó vẫn chưa hoàn toàn rõ ràng, tôi sẽ giải thích nó ở mèo. Lỗi OOM là khi một con mèo hét rất lâu trước cửa ra ban công, khi cánh cửa này mở ra, nó đứng ở ngưỡng cửa và không đi về phía nào, người ta thường nói rằng con mèo bị đóng băng. Nếu bạn đẩy anh ta kịp thời, anh ta sẽ há hốc mồm và đi ra ban công để làm việc với mèo con của mình. 
OOM Killer Đây là một tình huống khác có thể xảy ra trong vùng chứa khi hết bộ nhớ. 
Nếu một chương trình nằm ngoài vùng chứa, chúng ta sẽ nhận được OutOfMemory Killer (OOM Killer) - đây là quá trình chấm dứt ứng dụng để cứu kernel khỏi bị lỗi. Nó hy sinh ứng dụng để giữ cho container hoạt động. Thực tế không phải container sẽ rơi mà ứng dụng chạy trong đó chắc chắn sẽ rơi. Điều này xảy ra nếu bạn không kiểm soát mức tiêu thụ bộ nhớ của ứng dụng Java. Một lần nữa về mèo. Nếu bạn quyết định ngủ lâu hơn vào thứ Bảy và quên cho mèo ăn, thì OOM KillerHoa đảm bảo, chậu có thể không bị hư nhưng hoa sẽ phải trồng lại. 
Sự khác biệt giữa Lỗi OOM và OOM Killer là gì? Bạn có thể xử lý Lỗi OOM và thực hiện một số hành động (ví dụ: mở rộng quy mô ứng dụng) và OOM Killer sẽ chỉ hủy toàn bộ quá trình. OOM Killer tương tự như kill-9 (kill trừ chín) - lệnh giết chết một tiến trình trong Linux . 
Vấn đề là việc triển khai vùng chứa phổ biến nhất là vùng chứa Docker , dựa trên Linux , ngay cả khi bạn chạy nó trong Windows , kernel vẫn sẽ từ Linux . Trong Linux, chúng ta quan tâm đến một khái niệm: CGroups (nhóm điều khiển tiếng Anh) - một cơ chế nhân Linux nhằm giới hạn và cô lập các tài nguyên tính toán (bộ xử lý, mạng, tài nguyên bộ nhớ, tài nguyên I/O) cho các nhóm tiến trình. Nói một cách đơn giản, cơ chế này cho phép bạn quản lý tài nguyên trong một thùng chứa, trong bộ nhớ trường hợp của chúng tôi. Java liên quan đến điều này như thế nào? Thông qua cơ chế CGroups , Java có thể bám vào bộ nhớ vùng chứa. Nhưng tất cả điều này phụ thuộc vào phiên bản Java. Ví dụ: Java 7 không biết cách sử dụng CGroups và giới hạn vùng chứa không được biết đến. Theo mặc định, kích thước heap tối đa = ¼ bộ nhớ vật lý. Nếu ứng dụng vượt quá giới hạn vùng chứa thì sẽ xảy ra OOM Killer và nếu không đặt giới hạn vùng chứa thì ứng dụng sẽ lấy bộ nhớ từ các ứng dụng khác trên máy chủ (tốt hơn là nên đặt giới hạn, nếu không mọi người sẽ mất) . Tất nhiên, bạn có thể sử dụng cài đặt heap hoặc sử dụng "hình ảnh" đặc biệt để giải quyết vấn đề này, nhưng cách dễ nhất là sử dụng đúng phiên bản Java. Các phiên bản đúng bắt đầu bằng Java 8 x131 (được chuyển từ Java 9), nó bắt đầu hiểu CGroups . Và trong Java 10, hỗ trợ cho các container đã xuất hiện: UseContainerSupport , sau này chức năng này đã được chuyển sang Java 8 x 191 . Hoặc bạn chỉ có thể sử dụng Java: 11+ . Có thể kết luận gì: Khi sử dụng bộ nhớ vùng chứa, bạn có thể nhận được OutOfMemoryError (Lỗi OOM) hoặc OutOfMemoryKiller (OOM Killer). Trong trường hợp đầu tiên, ứng dụng sẽ không gặp sự cố ngay lập tức, có thể bắt gặp Lỗi OOM, có thể thực hiện các hành động được xử lý và kiểm soát. Ví dụ: mở rộng quy mô ứng dụng. Nếu OOM Killer xảy ra, ứng dụng sẽ gặp sự cố ngay lập tức và sẽ không còn tùy chọn nào để lưu nó. Và điều tồi tệ nhất là bề ngoài bản thân thùng chứa sẽ không sao, tức là bạn thậm chí có thể không nghi ngờ rằng có thứ gì đó đã rơi ở đó. Các cơ chế Linux được sử dụng để tương tác với vùng chứa và bộ nhớ Java. Nhưng không phải mọi Java đều triển khai chúng. Để tránh sự cố đối với Java 8, bạn cần sử dụng phiên bản bắt đầu từ 131 hoặc tốt hơn là từ 191. Hoặc sử dụng Java: 11+. Để thực hành: OutOfMemoryError: hãy bắt nó nếu bạn có thể
GO TO FULL VERSION