核心是减少Optional实例创建以降低GC压力：将嵌套flatMap改为map或判空，DTO字段不返回Optional而由调用方统一包装，禁用Optional字段，优先使用Stream.ofNullable、Objects.requireNonNullElse等零对象分配方案。
核心思路很直接：减少每秒创建的 Optional 实例数，就能降低 GC 并发标记阶段的扫描负担。因为每个 Optional 都是普通堆对象，高频创建 → 短生命周期对象暴增 → Gen 0 回收频繁 → 标记线程争抢加剧。
识别嵌套源头：三层以上 flatMap 或 Optional> 是明确信号
这类结构不是语义表达，而是包装污染：
- 看到
Optional，说明至少有三处本该用>> map或直接判空的地方误用了ofNullable()+flatMap() - 连续调用
.flatMap(...).flatMap(...).flatMap(...)且中间无业务逻辑分隔，大概率是把“数据提取”和“空值传播”混在一起写了 - Stream 中出现
map(x -> Optional.ofNullable(x)).flatMap(Optional::stream)这类冗余桥接，本质是用 Optional 模拟 Stream，完全可由Stream.ofNullable(x)替代
重构关键动作：从返回值契约入手，砍掉中间层
不靠删代码，而靠改契约：
- 把私有方法中返回
Optional的 getter 全部改为返回原始类型T，调用方统一用Optional.ofNullable(t)包装——避免上游多包一层 - RPC 响应 DTO 的字段访问器（如
getAddress()）不返回Optional，而是在服务层聚合时才做一次Optional.ofNullable(dto).flatMap(DTO::getAddress) - 移除所有形如
private Optional的字段定义，改用config; private Config config;+ 文档约定非空，或用构造器强制注入
验证优化效果：用 JVM 工具盯紧分配热点
别只看吞吐量，要定位对象生成现场：
- 启动参数加
-XX:+PrintGCDetails -XX:+PrintAllocationFailure，观察日志中java.util.Optional是否频繁出现在 “allocation request failed” 行 - 用 JMC（Java Mission Control）开启 Allocation Profiling，筛选 “Allocation Hot Spots”，重点看
Optional.ofNullable和Optional.empty的调用栈深度 - 对比优化前后：同一压测场景下，JFR 报告中 “Object Count” 里
Optional实例数下降 60% 以上，GC pause 时间通常同步减少 15–30%
替代方案优先级：能不用 Optional 就不用
尤其在数据流密集路径上：
- 源头为 null？直接用
Stream.ofNullable(list)，别先Optional.ofNullable(list).map(List::stream).orElseGet(Stream::empty) - 需要默认值？用
Objects.requireNonNullElse(obj, DEFAULT)，比Optional.ofNullable(obj).orElse(DEFAULT)少一次对象分配 - 做存在性判断？用
CollectionUtils.isNotEmpty(list)或StringUtils.hasText(str)，不引入任何新对象
