内存泄漏不必然导致溢出，溢出也不一定由泄漏引起：泄漏是“该收没收”，缓慢累积；溢出是“要不到”，直接报错；二者本质不同，仅存在可能的引发关系。
不一定。
内存泄漏不必然触发内存溢出
内存泄漏是指本该被垃圾回收的对象因被长生命周期引用（比如静态集合、缓存、监听器）持续持有，导致无法回收。但只要泄漏速度慢、总量小，且 JVM 堆空间足够大、应用运行时间短，就可能始终未触达内存上限——程序正常结束前，泄漏的内存还没“堆满”系统，自然不会报 OutOfMemoryError。
- 例如：一个命令行工具启动后处理单个文件，过程中有少量静态 Map 未清理，但只跑几秒就退出，泄漏内存根本没机会积累
- 又如：JVM 堆设为 4GB，而泄漏速率是每天 1MB，运行几个月都未必溢出
内存溢出也不一定由泄漏引起
OOM 是结果，成因多样。即使没有任何泄漏，以下情况也会直接触发溢出：
- 一次性加载超大文件或全量数据库结果集到内存
- 递归过深导致栈空间耗尽（StackOverflowError 属于 OOM 的一种）
- JVM 启动参数设置过小（如 -Xmx256m），但业务实际需要 512m
- 大量字符串常量涌入方法区（Java 8+ 的元空间），未合理限制大小
真正危险的是“隐式泄漏”和“常发性泄漏”
这两类泄漏容易被忽视，却最可能演变为 OOM：
- 隐式泄漏：比如 Spring 中用 static 缓存用户会话，没配过期策略，服务跑三个月后内存缓慢爬升
- 常发性泄漏：每次 HTTP 请求都往全局 List 添加对象却不清理，QPS 高时几小时内就撑爆堆
这类场景下，泄漏与溢出之间只是时间问题，不是“是否”，而是“何时”。
判断泄漏是否已造成危害，关键看内存趋势
不能只看某次 GC 后的内存占用，而要看：
- 老年代内存是否随时间推移持续上升，且 Full GC 后下降不明显
- 堆 dump 中是否存在大量本该回收却仍被 static 字段或 ThreadLocal 持有的对象
- 应用重启后内存曲线是否重新归零，再缓慢爬升
有持续增长趋势才说明泄漏正在累积；没有，则当前泄漏尚不构成溢出风险。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
