看来你遇到了Spring Boot应用堆内存无限制增长的问题，结合你用Visual VM观察到的现象——HeapSize（堆上限）持续上涨但已用堆空间有波动，我来给你拆解下问题和解决办法：

首先明确这个现象的核心：HeapSize持续增长说明JVM在自动扩容堆内存，而已用堆的波动则说明垃圾回收（GC）其实能正常回收垃圾——这意味着暂时没有内存泄漏，只是JVM的自动调优策略不符合你的预期，导致它一直试图占用更多服务器内存。

下面是具体的解决和优化步骤：

1. 快速解决：固定堆内存大小 #

避免JVM无限制扩容的最简单有效的方式，就是把堆的初始值（-Xms）和最大值（-Xmx）设为同一个固定值。这样JVM启动时就会分配好固定大小的堆，不会再动态调整上限。

你已经手动限制到1800MB，直接在应用启动参数里加上：

-Xms1800m -Xmx1800m

设置后，HeapSize就会固定在1800MB，不会再持续增长。而已用堆空间的波动是完全正常的——这恰恰说明GC在有效回收垃圾，不用过度担心。

2. 深挖根源：排查扩容原因（可选） #

如果想搞清楚背后的原因（或者需要进一步优化内存使用），可以做这些排查：

• 开启GC日志分析：给应用添加启动参数生成详细GC日志：

  -Xlog:gc*:file=gc.log:time,level,tags
  

  拿到日志后重点看：是不是频繁触发Full GC？如果是，说明老年代回收不及时，JVM会误以为需要更大的堆来缓解压力；另外也可以调整-XX:NewRatio或-XX:NewSize/-XX:MaxNewSize优化年轻代分配比例，减少年轻代垃圾溢出到老年代的频率。
• 用Visual VM做堆Dump分析：在应用运行时（比如完成200次REST调用后），右键Visual VM里的应用选择「Heap Dump」，生成堆快照后分析：
  • 哪些对象占用了大量内存？有没有大对象（比如大的请求响应体、缓存集合）频繁创建又回收？
  • 有没有本该被回收的对象被静态引用、ThreadLocal之类的持有，导致生命周期过长？
• 排查REST调用相关逻辑：重点检查调用过程中创建的对象——比如请求参数、响应结果、临时缓存、数据库连接/结果集有没有被正确释放，有没有ThreadLocal未清理的情况。

3. 其他辅助配置（不想固定堆大小的情况） #

如果出于某些原因不想固定堆大小，可以通过以下参数限制JVM的扩容行为：

-XX:MaxHeapFreeRatio=70 -XX:MinHeapFreeRatio=40

这个配置的意思是：当堆的空闲空间超过70%时，JVM会尝试缩容；当空闲空间低于40%时，才会尝试扩容，避免堆无限制占用服务器内存。

另外，推荐使用G1GC垃圾回收器（Java 9及以上默认），它对大堆内存的管理更高效，适合Spring Boot这类应用，启动参数只需加上：

-XX:+UseG1GC

总结一下：最快速解决当前问题的方式就是固定堆的初始值和最大值；如果需要深入优化，再通过GC日志和堆Dump去排查内存使用的细节。

内容的提问来源于stack exchange，提问作者vijay