Spring Boot(Kotlin+协程)Webflux应用运行时内存消耗疑问：闲置时内存未回落是否正常

兄弟，先给你拍板：这种情况绝对不正常。Webflux + Kotlin协程的技术栈本身就是为高并发、低资源消耗设计的，正常情况下，当应用闲置时，GC应该会回收掉渗透测试产生的临时对象，内存使用率会回落，CPU也会降到极低的 idle 水平。你遇到的「内存不下降、CPU持续飙升」，肯定是应用存在性能隐患。

可能的核心原因拆解 #

1. 内存泄漏（最常见的罪魁祸首） #

• 协程相关泄漏：如果代码里滥用了GlobalScope启动协程，或者自定义的CoroutineScope没有在合适时机（比如请求结束、服务停止时）取消，会导致协程实例和它持有的业务对象一直被引用，无法被GC回收；另外，协程中如果订阅了Webflux的Flux/Mono但没处理取消信号，也会导致资源长期占用。
• Webflux订阅泄漏：比如直接调用subscribe()但没保存Disposable对象，或者在请求结束时没有主动取消订阅，导致响应式流的订阅关系一直存在，持有大量请求数据或连接资源。
• 无边界的缓存/集合：如果业务代码里用了静态HashMap、自定义缓存但没设置过期或清理逻辑，渗透测试产生的大量请求数据会一直堆在内存里，永远不会被释放。

2. CPU持续飙升的关联原因 #

• 协程调度错误：如果在协程里用了Dispatchers.Default这类CPU密集型调度器处理阻塞IO操作（比如同步数据库调用），会导致调度器的线程池一直处于满负载状态；或者协程里有无限循环、无终止条件的重试逻辑，哪怕闲置后还在后台跑。
• 背压处理失效：渗透测试时请求量暴增，Webflux的背压机制如果没配置好（比如没有限制请求队列大小），会导致大量请求数据堆积在内存里，CPU一直忙着处理这些堆积任务，甚至闲置后还有未处理完的任务在持续消耗资源。
• 频繁GC触发：内存泄漏会导致老年代内存持续上涨，最终触发频繁的Full GC——Full GC本身会占用大量CPU，同时因为泄漏的对象无法被回收，内存也根本降不下来，形成恶性循环。

实用排查建议 #

• 内存快照分析：用jmap -dump:format=b,file=heap.hprof <pid>导出堆快照，然后用MAT（Memory Analyzer Tool）或者VisualVM打开，重点看「Dominator Tree」里的大对象、持续增长的对象类型，判断是协程相关对象、业务缓存还是Webflux的订阅对象。
• CPU采样排查：用AsyncProfiler或者jstack采样CPU使用情况，看线程（尤其是协程调度器的线程）在执行什么代码——有没有无限循环、阻塞调用、GC线程占比过高的情况。
• 协程代码审计：
  • 检查是否滥用GlobalScope，尽量用绑定请求生命周期的CoroutineScope（比如Spring提供的CoroutineScope bean），并在请求结束时取消协程。
  • 替换所有block()这类阻塞调用，改用awaitSingle()、awaitFirst()等协程友好的非阻塞方法。
  • 确保协程中的异常被正确捕获处理，未捕获的异常会导致协程挂起但不释放资源。
• Webflux资源检查：所有subscribe()调用都要保存Disposable对象，在请求结束时调用dispose()；或者用doFinally操作符在流结束时自动清理资源。

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