Optional不应被重构为基本类型包装类以节省堆内存，它只是API边界上表达空值语义的轻量容器，滥用（如循环创建、作状态变量、作集合元素）才导致性能问题；应让基本类型承担计算与存储职责，Optional仅用于返回值契约。
不能也不应该把 Optional 重构为“基本类型专属包装类”来压榨堆内存空间。
Optional 本身不是性能瓶颈，滥用才是问题源头
Optional 是一个轻量级容器，实例本身只持有一个引用字段（+少量标记），创建开销极小。它不参与高频计算、不进循环热路径、不替代数值变量——它的定位是API 边界上的空值语义表达，而非运行时数据载体。
试图把它“替换成自定义 int/long 包装类”，不仅无法节省堆内存，反而会引入额外对象、破坏语义一致性、增加维护成本。
真正该优化的，是 Optional 的误用场景
以下操作看似“用了 Optional”，实则制造了不必要的堆压力：
-
在循环内反复构造 Optional：比如
for (int i : list) { Optional.of(i); ... }—— 每次都新建对象，毫无必要 -
用 Optional 包裹基本类型作状态变量：如
private Optional，而实际只需retryCount = Optional.empty(); private int retryCount = 0;+ 明确初始语义 -
将 Optional 作为集合元素或缓存 value：如
Map，导致每个 entry 都多一层对象封装> -
过度链式调用未短路的 map/flatMap：比如
opt.map(...).map(...).map(...).orElse(0)，中间可能生成多个临时 Optional 实例
正确做法：用基本类型收口，Optional 只守边界
把 Optional 当作“门卫”，而不是“搬运工”：
- 方法返回值用
Optional表达“可能无结果”，但内部实现全程用int运算，最后一步才封装：return resultKnown ? Optional.of(result) : Optional.empty(); - 参数接收端优先用基本类型或非空契约：如
void process(int id)而非void process(Optional；null 由调用方校验，不推给方法体id) - 状态字段、计数器、配置值等一律使用
int/long/boolean，配合哨兵值（如-1表示未初始化）或独立布尔标志位，彻底避开对象分配 - 需要空值语义的配置项（如
Integer port表示“未设置”），可保留包装类型，但不参与任何计算逻辑——读取后立即转为基本类型再进入业务流
如果真想减少堆对象，盯准这些地方更有效
相比折腾 Optional，以下优化能真实降低 GC 压力：
- 把
List换成IntArrayList（Eclipse Collections）或IntList（FastUtil） - 循环累加、计数、标志位全部改用
int/long局部变量，禁用Integer sum = 0这类写法 - 避免
Integer.valueOf(x)在高频路径中脱离缓存范围（如 x > 127），直接用原始值参与运算 - 检查是否误用 CGLIB/ASM 动态生成类——那才是元空间和类加载器泄漏的主因
Optional 的价值在于让空值意图可见、让 API 更安全，不是用来省几个字节堆内存的。把它留在该在的地方，把基本类型用在该用力的地方，堆空间自然就松了。
