内存管理在整体应用架构中，在非生产环境中，一般1GB或2GB内存就足够了。如果我们将这个应用程序分成20或30个独立的微服务，很难期望RAM会保持在1GB或2GB左右。特别是如果我们使用SpringCloud。首先准备三个服务，Eureka服务+两个提供RESTAPI的简单微服务，将微服务注册到Eureka。在这里，这些应用程序的内存使用不受任何限制。提示：构建一个简单的SpringCloud应用的例子：https://www.ictgu.cn/share/6644e468如下图所示，这三个微服务在电脑上占用了大约1.5GB的RAM内存。这三个服务是最简单的应用，基本没有数据处理，对于这样的内存消耗显然不理想。RAM的最大用途是用于Eureka发现服务，这是用于初始化声明式客户端以调用其他服务的最大API。不受限制的内存使用情况关于内存使用情况，请参见JProfiler制作的图表，如下所示。如图所示，内存使用受堆影响，相比非堆占用空间大。HeapNon-Heap当然，第一个明显的问题是我们是否需要空间来在堆上运行我们的微服务应用程序。答案是否定的，我们没有。现在，让我们简单了解一下Java8中内存管理过程是如何工作的。我们可以将JVM内存分为两个不同的部分：堆（Heap）和非堆（Non-Heap）。如上图所示，我们的微服务器大小为(~600MB)。反过来，JVM内存由新生代和老年代组成。所有新创建的对象都位于年轻代。当年轻代被填满时，会进行次要垃圾回收（MinorGC）。更准确地说，其中一些位于年轻一代的对象成为EdenSpace。MinorGC将所有仍在使用的对象从EdenSpace移动到Survivor0。对Survivor0和Survivor1空间执行相同的过程。所有在多次GC循环中幸存下来的对象都被移动到老年代内存空间。从哪里移除对象是MajorGC的责任。为了更好的理解下图，在运行java-jar命令时，可以使用以下参数来设置JavaHeap的内存限制：-Xms-JVM启动时的初始堆大小-Xmx-***堆大小-Xmn-younggeneration剩下的空间是老年代JVM内存的第二部分。从我们的角度来看，上图略显不重要，是Non-Heap。Non-Heap包括以下部分：ThreadStacks：所有运行线程的空间。可以使用-Xss参数设置最大线程大小。Metaspace：它取代了PermGem（Java7中JVM堆的一部分）。在Metaspace中，所有类和方法都由应用程序加载。看看SpringCloud自带的包数量，这里就不多省内存了。可以通过设置-XX:MetaspaceSize和-XX:MaxMetaspaceSize参数来管理元空间大小。代码缓存：这是本地代码（例如JNI）或由JIT（即时）编译器编译为本地代码的Java方法的空间。***大小设置-XX:ReservedCodeCacheSize参数。压缩类空间：使用-XX:CompressedClassSpaceSize设置为压缩类空间保留最大内存。DirectNIOBuffers更简单，Heap用于对象，Non-Heap用于类。可以想象，当我们的应用程序Non-Heap大于Heap时，我们就可以结束这种情况。首先，让我们使用以下参数运行我们的服务发现。在我看来，如果你使用SpringBoot上嵌入的Tomcat启动Eureka，这些配置是最佳值。-Xms16m\-Xmx32m\-XX:MaxMetaspaceSize=48m\-XX:CompressedClassSpaceSize=8m\-Xss256k\-Xmn8m\-XX:InitialCodeCacheSize=4m\-XX:ReservedCodeCacheSize=8m\-XX:MaxDirectMemorySize=16m如果使用RESTAPI微服务（使用Feign或Ribbon），我们需要增加一些值：-Xms16m\-Xmx48m\-XX:MaxMetaspaceSize=64m\-XX:CompressedClassSpaceSize=8m\-Xss256k\-Xmn8m\-XX:InitialCodeCacheSize=4m\-XX:ReservedCodeCacheSize=8m\-XX:MaxDirectMemorySize=16m根据以上配置，JProfiler生成如下图表。区别在于启动和请求处理时间。与早期设置相比，该应用程序运行速度较慢。当然，我不会在生产环境中设置这样的参数。HeapNon-Heap目前总的内存使用情况如下。微服务仍然是内存最密集的，而Eureka是最小的。低配置内存使用我还尝试使用不同的Web容器运行Eureka应用程序。您可以通过在pom.xml文件中包含以下依赖项来轻松更改Web容器。使用Undertow
