使用collections.emptymap()等单例空集合可降低gc压力，因其返回jvm预创建的全局共享不可变实例，避免堆分配、减少minor gc扫描与复制开销，并消除构造同步块等隐式成本。
在高频微服务接口中，频繁创建空集合（如 new hashmap()、new arraylist()）会持续产生短生命周期对象，加剧年轻代 gc 频率，尤其在 qps 上万的场景下，这种“小对象洪流”可能引发 stw 时间上升、cpu 毛刺甚至吞吐下降。使用 collections.emptymap()、emptylist()、emptyset() 这类单例空集合，是零成本、零风险、立竿见影的 gc 优化手段。
为什么空集合单例能降低 GC 压力
这些方法返回的是 JVM 内部预创建且全局共享的不可变实例（例如 Collections.EMPTY_MAP），无论被调用多少次，都指向同一个静态 final 对象。相比每次 new 一个新集合：
- 不触发堆内存分配，彻底避免 Eden 区对象生成
- 无引用逃逸，JIT 可进一步优化掉冗余操作
- 减少 Minor GC 扫描对象数量和复制开销
- 避免因对象构造引发的同步块（如
HashMap初始化桶数组）等隐式开销
高频接口中的典型误用与修正方式
常见于查询类接口：无数据时返回空结果集合，但实现不统一：
-
❌ 误用 new 实例：
return new HashMap();或return new ArrayList();—— 每次调用都新增 2~4 个对象（Map + Node[] + modCount 等） -
❌ 误用 null：
return null;—— 调用方需判空，且无法直接 stream/forEach，易导致 NPE 或防御性包装（如Optional.ofNullable(...).orElse(...)），反而增加对象创建 -
✅ 推荐写法：
return Collections.emptyMap();或return Collections.emptyList();—— 零分配、零GC、语义明确、线程安全
结合 Stream 和 Optional 的安全链式调用
当空集合作为中间结果参与流式处理时，单例空集合可天然兼容，无需额外判空：
- 直接调用
.stream()安全：空 List 的stream()返回空 Stream，不启动线程池、不分配 Spliterator - 搭配
Optional更健壮：Optional.ofNullable(userList).orElse(Collections.emptyList()).stream()... - 替代
Stream.empty()场景：若上游已确定为空集合（如 DAO 层返回），优先复用emptyList()，而非新建Stream.empty()—— 后者虽也轻量，但前者更贴近业务语义且复用已有对象
监控验证与上线建议
优化后可通过 JVM 监控确认效果：
- 观察
G1 Young Generation GC次数与平均耗时是否下降（重点关注 Eden 区存活对象数） - 使用 JFR（Java Flight Recorder）录制 1 分钟流量，对比 “对象分配速率（Allocation Rate）” 中
java.util.HashMap、java.util.ArrayList等类的实例数变化 - 灰度发布时，对比 A/B 分组的 P95 响应延迟与 GC pause 曲线，通常可见 3%~8% 的延迟改善（取决于空响应占比）
该优化无需改接口契约、不引入新依赖、不改变行为逻辑，只需代码层面统一规范。在 Spring Boot Controller、Feign fallback、MyBatis 查询结果处理器等高频路径中批量替换，收益显著。
