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/66...

就像你在下圖看到的同樣，三個微服務大概佔用了電腦 1.5GB 的 RAM 內存。這三個服務是最簡單的應用程序，基本沒有數據處理量，對於這樣的內存消耗量，顯然是不理想的。RAM 的最低使用量是用於 Eureka
發現服務，最大的用於初始化聲明式客戶端以調用其餘服務的 API。

關於內存使用量以下圖 JProfiler 製做的圖表。如圖所示，內存使用受堆影響，與非堆相比，它佔用了大量空間。

固然，第一個明顯的問題是咱們是否須要在堆上運行咱們的微服務應用程序的空間。答案是否認的，咱們沒有。如今，咱們來簡要介紹一下在
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內存的第二部分，從咱們的角度來看，上圖略顯不重要，它是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 生成了以下圖表。區別在於啓動和請求處理時間。與早期的設置相比，該應用程序的運行速度較慢。固然，我不會在生產環境下設置這樣的參數。

當前的總內存使用狀況以下。微服務仍然是內存佔用最大的，而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 服務執行，而無需註冊任何微服務。

文末福利

Java 資料大全 連接:https://pan.baidu.com/s/1pUCC... 密碼:b2xc
更多資料： 2020 年 精選阿里 Java、架構、微服務精選資料等，加 v ❤ ：qwerdd111

本文由博客一文多發平臺 OpenWrite 發佈！