堆溢出与栈溢出本质不同：堆溢出是动态分配内存超限或内存泄漏导致堆空间耗尽，抛出outofmemoryerror；栈溢出是方法调用过深或局部变量过大导致栈空间不足，抛出stackoverflowerror。
这个问题存在概念混淆，需要先厘清关键点：堆溢出（Heap Overflow）和堆栈溢出（Stack Overflow）是两类不同机制的内存问题，而“配置中心限流”本质上是控制请求流量的手段，**无法直接防止或修复堆溢出**。
限流不能解决堆溢出的根本原因
堆溢出通常由以下情况引发：
- Java 中创建超大对象（如 500MB 的 char[]），常见于 SQL 拼接、大文件缓存、未分页的数据加载；
- 第三方组件内存泄漏（如 Druid 1.1.22 的 SQL 统计缓存无限堆积）；
- 对象长期被强引用持有（如静态 Map 缓存未清理、监听器未注销）。
这些是**内存分配与生命周期管理问题**，不是请求量过大导致的——即使每秒只来 1 个请求，只要该请求触发一次大对象分配或泄漏，照样 OOM。
限流在什么场景下能间接缓解 OOM？
仅当 OOM 是由**高频请求 → 高频对象创建 → 堆内存持续增长 → GC 跟不上**这一链路引发时，限流才有作用。典型例子：
- 某接口每秒接收 1000 条日志并全量转成 JSON 字符串缓存；
- 批量导出接口未做分页，单次请求拉取 100 万条记录到内存；
- Druid + 动态拼接 SQL 场景：请求越多，生成的 SQL 越多，缓存越膨胀。
此时，通过配置中心下发限流规则（如 QPS ≤ 5），可降低单位时间内的对象生成速率，为 GC 争取回收时间，延缓 OOM 发生——但这只是“拖时间”，不是“修漏洞”。
不改代码、靠配置中心实现限流的可行路径
若旧系统已接入 Spring Cloud Alibaba Nacos / Apollo / 自研配置中心，且具备统一网关或 AOP 切面能力，可按如下方式注入限流：
- 网关层限流：在 API 网关（如 Spring Cloud Gateway、Kong）中配置路由级规则，基于请求路径、Header 或参数动态限流，无需动业务代码；
- Filter/AOP 注入：若系统有通用 Filter 或切面入口（如所有 Controller 继承 BaseAction），可在不修改原有方法的前提下，用 @Around 切入，读取配置中心的限流开关与阈值，调用 RateLimiter（如 Guava 或 Resilience4j）拦截超额请求；
- JVM Agent 增强：使用 Java Agent（如 ByteBuddy）在类加载时织入限流逻辑，例如对指定包下的方法自动添加 @RateLimiter 注解行为，完全零代码侵入——但需额外部署 agent jar 并配置 JVM 参数。
真正治本：必须定位并修复堆溢出源头
配置中心限流只是“止痛药”。要根治，仍需结合堆 dump 分析（如用 jmap + Eclipse MAT 或 JProfiler），重点排查：
- 最大的对象实例（如 char[]、byte[]、HashMap$Node[]）是谁创建的？
- 谁在长期持有它们？（看 GC Roots 引用链）
- 是否用了有已知泄漏风险的组件版本？（如 Druid ≤1.2.8、FastJSON ≤1.2.83）
例如，发现是 Druid SQL 缓存泄漏，只需升级到 1.2.16+ 并关闭 sqlStat 或设置 maxPoolPreparedStatementPerConnectionSize=0，比加一百层限流都管用。
