应直接分析堆内存增长源头，通过jmap或ARMS/JProfiler生成堆dump，重点检查异常多的函数类实例、未回收lambda/MethodHandle及大对象被强引用情况，并排查柯里化中闭包捕获外部状态、构造方法引用误缓存等导致长生命周期对象的问题。
直接看堆内存增长的源头，而不是先猜“是不是柯里化的问题”。高级柯里化本身不导致内存暴涨，问题出在它和构造方法引用结合后，无意中创建了长生命周期对象、闭包捕获、或隐式循环引用。
查堆快照，定位真实占用对象
用 jmap 或 ARMS/JProfiler 生成堆 dump，重点观察：
- 哪些类实例数量异常多（比如你自定义的函数包装类、Supplier/Function 子类）
- 是否存在大量未被回收的 lambda 对象或 MethodHandle 实例
- 大对象（char[]、byte[]、ArrayList）是否被这些函数对象强引用着
检查柯里化链中是否意外持有了外部状态
例如下面这种写法很危险：
Function<String, Consumer<User>> createUserHandler = name -> user -> {
// 这里闭包捕获了 name，而 name 可能是长字符串或大对象
log.info("Handling {} for {}", name, user.getId());
db.save(user); // 如果 db 是单例且带连接池，可能间接延长引用链
};
若该函数被缓存进 static Map 或 Spring Bean 中，name 就无法释放。建议：
- 避免在柯里化返回的 lambda 中直接使用上游参数以外的变量
- 把需要的数据显式传入，而非依赖闭包捕获
- 用 Supplier<Consumer<User>> 替代 Function，延迟构造，减少提前绑定
确认构造方法引用是否触发了非预期对象创建
比如：User::new 在柯里化中被反复调用，但实际每次都需要新实例，而你又把它塞进了静态缓存：
static final Map<String, Supplier<User>> factoryMap = new ConcurrentHashMap<>();
// 错误：把 User::new 直接存进去，没做参数绑定，每次 get() 都 new，但 map 本身又不清理
factoryMap.put("default", User::new);
更隐蔽的是：
Function<String, Function<Integer, User>> curried = prefix -> age -> new User(prefix + "-" + age);
这个表达式每调用一次就生成新 lambda，如果被高频注册为监听器或回调，就会堆积。应改为：
- 预生成有限个常用组合，缓存复用
- 改用工厂方法 + 参数校验，避免字符串拼接构造
- 用 record 或 builder 模式替代动态拼接构造
验证 GC 行为是否受阻
运行 jstat -gc <pid>，关注：
- Old Gen 使用率是否持续上升且 Full GC 后不下降 → 说明对象被长期持有
- Metaspace 是否同步增长 → 可能因动态生成大量函数类（如 LambdaMetafactory）
- GC 日志中是否有 “promotion failed” 或 “concurrent mode failure” → 堆碎片或晋升失败
如果是后者，说明不是逻辑错误，而是对象图太深、GC 回收效率低，需调整 G1RegionSize 或启用 ZGC。
