“核心共享异常”说法不成立，orelsethrow 不共享或缓存异常；内存堆积真实原因是异常被误缓存、高频创建或构造时携带大对象。
“核心共享异常”和“在 orelsethrow 中控制其范围以杜绝内存堆积”这一说法不成立，属于概念混淆，现实中不存在该技术路径。
原因很明确：
-
orElseThrow是 Java 8+Optional类的一个方法，用于在Optional为空时抛出指定异常。它本身不持有、不共享、不缓存、不传播任何异常实例，更不涉及内存生命周期管理。 - 异常对象（如
RuntimeException子类）在orElseThrow(() -> new XxxException())中是按需创建、即时抛出、进入调用栈、由 JVM 异常处理机制接管的。它不会“滞留”在Optional内，也不会被“共享”或“跨线程传递”，更不会导致内存堆积。 - 所谓“核心共享异常”并非 Java 标准术语，JVM、
Optional源码、OpenJDK 文档中均无此定义。强行赋予其“生存范围”“可达性网络”等抽象属性，会误导问题定位。
真正可能导致内存堆积的，是以下可验证、可复现、可修复的场景：
✅ 异常被意外缓存或强引用滞留
例如：
- 将异常对象存入静态
Map或队列（如日志聚合、错误统计模块）； - 在自定义
ThreadLocal中保存未清理的异常堆栈； - 使用
WeakReference不当，误将异常作为 key 导致引用链无法释放。
✅ orElseThrow 被滥用在高频循环中，频繁创建异常
虽然单次无害，但若写成：
for (String id : ids) {
Optional<user> u = userDao.findById(id);
User user = u.orElseThrow(() -> new UserNotFoundException("id=" + id)); // 每次都 new 异常！
}</user>
会导致大量短生命周期异常对象涌入老年代（尤其在高并发下），加剧 GC 压力，间接表现为“内存堆积感”。
✅ 异常构造过程中加载了大对象（如完整堆栈 + 上下文数据）
比如：
orElseThrow(() -> new ServiceException("failed", payloadJson, fullStackTrace))
其中 payloadJson 是 MB 级字符串，或 fullStackTrace 被手动捕获并保留——这会让异常对象本身成为内存大户。
实用建议：
- ✅ 用
orElseThrow(UserNotFoundException::new)替代带参数的 lambda，避免闭包捕获外部变量； - ✅ 高频校验逻辑（如 ID 查询）优先用
ifPresent或直接判空，而非依赖orElseThrow触发异常流； - ✅ 禁止将异常实例放入任何长期存活容器（静态集合、缓存、队列）；
- ✅ 若需记录上下文，用
log.error("msg", exception)让日志框架处理，不要把原始异常塞进业务对象； - ✅ 用
jcmd <pid> VM.native_memory summary</pid>或jstat -gc观察是否真有老年代持续增长，再结合jmap -histo看异常类是否排进前 10。
不复杂但容易忽略。
