容器和 Java 有什麼關係？

適合那些讀過容器和 Docker，但不了解 Java 如何與容器結合的人。首先，讓我們回顧一下Java記憶體。讓我提醒您，記憶體由堆疊和堆疊組成，它們使用伺服器的RAM（隨機存取記憶體）；當進一步談到記憶體時，我們指的是RAM。 現在讓我們看看容器的橫截面。 不，當然不是，我們對臀部和大腿不感興趣，我們會看容器中的記憶結構。它可以分為三個部分： • 堆記憶體－堆本身；• 堆外是指不在堆內的所有內容；• OS Overhead 是在容器內實現進程的記憶體開銷。 比方說：我們為容器分配了 1 Gb，在圖中它將是容器限制- 其邊界由藍色矩形表示。我們為容器中的Java記憶體分配了80%，即0.8 Gb，而Heap佔用了我們大約80%的容器，即不小於0.8 Gb，因為OS Overhead佔用了部分資源（開銷）用於維護流程。容器中大約有 20% 的空間留給未連接到堆（Off Heap）的所有內容。圖中的Used區域顯示了執行應用程式時所使用的記憶體區域。現在我們需要談談容器中的記憶體可能會耗盡的情況。 OutOfMemoryError 如果應用程式的記憶體消耗（已使用區域）達到堆限制（Heap），我們將捕獲OutOfMemoryError（OOM 錯誤）。這表示堆中沒有足夠的空間，即放置應用程式中以程式設計方式建立的物件的記憶體區域。 如果還不完全清楚，我會用貓來解釋。 OOM錯誤 是當一隻貓在陽台的門前尖叫了很長很長時間，而當這扇門打開時，他站在門口不走任何一條路，他們常說貓被凍住了。如果你及時推他，他就會驚掉下巴，去陽台上做他的小貓生意。 OOM Killer 這是當記憶體耗盡時容器中可能發生的另一種情況。 如果程式超出容器，我們會遇到OutOfMemory Killer (OOM Killer) - 這是一個終止應用程式以防止核心崩潰的進程。它犧牲了應用程式來保持容器運行。容器不會倒下並不是事實，但其中運行的應用程式肯定會倒下。如果您不控制 Java 應用程式的記憶體消耗，就會發生這種情況。再說貓。如果你決定週六多睡一會兒卻忘記給貓吃食物，那麼OOM Killer花有保證，花盆可能不會損壞，但花必須重新種植。 OOM 錯誤和 OOM Killer 有什麼不同？ 您可以處理OOM 錯誤並執行一些操作（例如：擴充應用程式），OOM Killer將簡單地終止整個進程。 OOM Killer類似於kill-9 （kill 減九）－ Linux中殺死程序的命令。 問題是，最受歡迎的容器實作是Docker容器，它基於Linux，即使你在Windows下運行它，核心仍然來自Linux。在Linux中，我們感興趣的是一個概念： CGroups（英文控制組）－一種限制和隔離進程組的運算資源（處理器、網路、記憶體資源、I/O資源）的Linux核心機制。 簡而言之，這種機制允許您管理容器中的資源，在我們的例子中是記憶體。 Java 與此有何關係？Java 正是透過CGroups 機制來取得容器記憶體。但這一切都取決於Java的版本。例如，Java 7不知道如何使用CGroups，也不知道容器限制。預設情況下，最大堆大小 = 1/4實體記憶體。如果應用程式超出了容器限制，那麼就會出現OOM Killer，如果不設定容器限制，那麼應用程式會從伺服器上的其他應用程式中獲取記憶體（最好設定限制，否則大家都會輸） 。當然，您可以使用堆疊設定或使用特殊的「圖像」來解決此問題，但最簡單的方法是使用正確的 Java 版本。正確的版本從Java 8 x131 （從 Java 9 移植）開始，它開始理解CGroups。而在Java 10 中，出現了對容器的支援：UseContainerSupport，後來這個功能被移植到Java 8 x 191。或者您可以只使用Java: 11+。可以得到什麼結論： 使用容器記憶體時，您可能會收到 OutOfMemoryError（OOM 錯誤）或 OutOfMemoryKiller（OOM Killer）。在第一種情況下，應用程式不會立即崩潰，OOM Error 可以被捕獲、處理並可以採取控制操作。例如，擴展應用程式。如果發生 OOM Killer，應用程式將立即崩潰，並且沒有任何選項可以保存它。最糟糕的是，從表面上看，容器本身並沒有什麼問題，也就是說，你甚至可能不會懷疑有東西掉在那裡。Linux機制用於與容器和Java記憶體互動。但並不是每個 Java 都實作它們。為了避免 Java 8 出現問題，您需要使用從 131 開始的版本，或者更好的是從 191 開始。或使用 Java：11+。 練習： OutOfMemoryError：如果可以的話捕捉它