Spring Boot & Spring Cloud 應用內存管理
在整體應用架構中，非生產環境情況下，一般 1GB 或者 2GB 的 RAM 就足夠了。如果我們將這個應用程序劃分為 20 或 30 個獨立的微服務，那么很難期望 RAM 仍將保持在 1GB 或 2GB 左右。特別是如果我們使用 Spring Cloud 的時候。
首先，準備三個服務，Eureka 服務 + 提供 REST API 的兩個簡單的微服務，并將微服務注冊到 Eureka。此處，不以任何方式限制這些應用程序的內存使用。
提示：Spring Cloud 簡單應用的搭建示例：https://www.ictgu.cn/share/6644e468
就像你在下圖看到的一樣，三個微服務大概占用了電腦 1.5GB 的 RAM 內存。這三個服務是最簡單的應用程序，基本沒有數據處理量，對于這樣的內存消耗量，顯然是不理想的。RAM 的***使用量是用于 Eureka 發現服務，***的用于初始化聲明式客戶端以調用其他服務的 API。
未限制的內存用量
關于內存使用量如下圖 JProfiler 制作的圖表。如圖所示，內存使用受堆影響，與非堆相比，它占用了大量空間。
Heap
Non-Heap
當然，***個明顯的問題是我們是否需要在堆上運行我們的微服務應用程序的空間。答案是否定的，我們沒有。現在，我們來簡要介紹一下在 Java 8 中如何進行內存管理過程。
我們可以將JVM內存分為兩個不同的部分：堆(Heap)、 非堆(Non-Heap)。如上圖所示，我們的微服務器的大小為大小(〜600MB)。反過來，JVM 內存 由 年輕代(Young Generation) 、老年代(Old Generation)組成。所有新創建的對象都位于年輕代中。當年輕代被填滿時，執行次要垃圾收集(Minor GC)。
更準確的說，這些位于年輕代的一部分對象成為 Eden Space。Minor GC將所有仍然使用的對象從 Eden Space 移動到 Survivor 0。對于Survivor 0 和 Survivor 1 空間執行相同的過程。在 GC 的許多循環中幸存的所有對象都被移動到老年代內存空間。從哪里移除對象是由 Major GC負責的。為了更好地了解下圖，在運行 java -jar 命令時，可以使用以下參數設置 Java Heap 的內存限制：
- -Xms – JVM啟動時的初始堆大小
- -Xmx – ***堆大小
- -Xmn - 年輕代的大小，其余的空間是老年代
JVM 內存
JVM內存的第二部分，從我們的角度來看，上圖略顯不重要，它是Non-Heap。 Non-Heap 包括以下部分：
- Thread Stacks ：所有運行的線程的空間。可以使用 -Xss 參數設置***線程大小。
- Metaspace ： 它替代了 PermGem(Java 7中是JVM堆的一部分)。在 Metaspace 中，通過應用程序加載所有類和方法。看看Spring Cloud 包含的包數量，我們不會在這里節省大量的內存。可以通過設置 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 參數來管理 Metaspace 大小。
- Code Cache ： 這是由 JIT(即時)編譯器編譯為本地代碼的本機代碼(如JNI)或 Java 方法的空間。***大小設置-XX:ReservedCodeCacheSize 參數。
- Compressed Class Space ： 使用 -XX：CompressedClassSpaceSize 設置為壓縮類空間保留的***內存。
- Direct NIO Buffers
更簡單來說，Heap 是用于對象，Non-Heap 是用于類。可以想像，當我們的應用程序 Non-Heap 大于 Heap 時，我們可以結束這種情況。首先，讓我們用下面的參數來運行我們的服務發現。在我看來，如果您在 Spring Boot 上啟動具有內嵌 Tomcat 的 Eureka，這些配置是***的值。
- -Xms16m \
- -Xmx32m \
- -XX:MaxMetaspaceSize=48m \
- -XX:CompressedClassSpaceSize=8m \
- -Xss256k \
- -Xmn8m \
- -XX:InitialCodeCacheSize=4m \
- -XX:ReservedCodeCacheSize=8m \
- -XX:MaxDirectMemorySize=16m
如果使用REST API 的微服務(帶有 Feign 或 Ribbon)，我們需要增加一些值：
- -Xms16m \
- -Xmx48m \
- -XX:MaxMetaspaceSize=64m \
- -XX:CompressedClassSpaceSize=8m \
- -Xss256k \
- -Xmn8m \
- -XX:InitialCodeCacheSize=4m \
- -XX:ReservedCodeCacheSize=8m \
- -XX:MaxDirectMemorySize=16m
按照如上配置，JProfiler 生成了如下圖表。區別在于啟動和請求處理時間。與早期的設置相比，該應用程序的運行速度較慢。當然，我不會在生產環境下設置這樣的參數。
Heap
Non-Heap
當前的總內存使用情況如下。微服務仍然是內存占用***的，而Eureka 最小。
低配置的內存用量
我也嘗試使用不同的 Web 容器運行 Eureka 應用程序。您可以通過在 pom.xml 文件中包含以下的依賴關系輕松更改 Web 容器。
使用 Undertow
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-undertow</artifactId>
- </dependency>
使用 Jetty
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-jetty</artifactId>
- </dependency>
結果排名：Undertow(116MB)、Tomcat(122MB)、Jetty(128MB)。 此測試僅針對 Eureka 服務執行，而無需注冊任何微服務。
【本文為51CTO專欄作者“翟永超”的原創稿件，轉載請通過51CTO聯系作者獲取授權】
