Spring Boot（Spring Web）HTTP服务中Java Garbage Collection工作机制问询

核心回收逻辑说明 #

JVM的垃圾回收不会在对象失去引用后立刻直接清理，所有不可达对象都会先驻留在内存中，直到GC被触发（JVM会根据内存占用、回收器策略自行判断触发时机）时才会被清理，请求链路中的对象也遵循这个规则。

请求级对象的生命周期 #

你提到的数据库查询结果对象、自行通过new实例化的非Spring托管对象、用来承载返回结果的ArrayList都属于请求级对象：

• Tomcat处理每一个HTTP请求时都会分配独立的工作线程，请求处理全流程中产生的所有局部变量的引用，都保存在该线程对应的栈帧中。
• 当请求处理完成、HTTP响应返回给客户端后，该请求对应的工作线程栈帧会被销毁，这些对象的强引用根就会消失，只要你没有主动将这些对象存到长生命周期的持有载体中，它们就会自动进入可回收状态，本质上和你示例代码中手动执行myList = null的效果完全一致，不需要你手动做任何解引用操作。

禁止手动触发GC #

完全不需要手动调用System.gc()：这个方法仅仅是给JVM发送垃圾回收的建议，JVM并不一定会执行该建议；反而随意调用System.gc()很可能触发不必要的Full GC，导致服务全局停顿（STW），严重影响接口性能和服务可用性。

需规避的内存泄漏场景 #

只有一种情况会导致这类请求级对象无法被正常回收：你主动将请求级对象赋值给了单例Controller/Service的成员变量、静态集合、全局缓存这类不会随请求结束销毁的长生命周期对象，导致对象始终存在可达的强引用链，这种情况才会引发内存泄漏，日常开发注意规避即可。

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