如何让Java中Function.identity()的函数组合更高效？

Java的java.util.function.Function.identity()返回一个等效于t -> t的函数，仅原样返回输入参数。当它和其他函数通过andThen()组合时，示例代码如下：

Function<String, String> fn = Function.identity();
Function<String, String> composedFn = fn.andThen(String::toUpperCase);
String foo = composedFn("foo");  // 结果为"FOO"

这段代码等效于Function.identity().apply("foo").toUpperCase()，编译器不会在字节码层面优化lambda调用，JRE运行时的优化情况需要具体分析。

一、重写andThen()直接返回后续函数的优化是否可行？ #

从语义和逻辑上看，这种优化是可行的。因为Function.identity()的apply()方法仅返回输入参数，将它和后续函数组合时，完全等价于直接调用后续函数。重写Function.identity()对应实现类的andThen()方法，直接返回传入的后续函数，不会改变最终执行结果。

二、需要考虑的潜在问题 #

• 兼容性风险：现有代码可能依赖组合后函数的内部结构，比如通过反射判断组合链中是否包含Function.identity()，或者依赖JDK内部的CompositeFunction类型。这类优化会打破此类代码的预期行为。
• API设计一致性：Function接口的默认andThen()实现是通用逻辑，专门为identity开特例，会增加接口实现的复杂度，不符合JDK一贯的通用化设计原则。
• 调试与监控影响：一些调试工具或性能监控工具可能会追踪函数调用链，优化后会丢失identity的调用节点，影响这类工具的输出。

三、JRE是否已经优化掉Function.identity()的调用？ #

OpenJDK的JIT编译器（如C2）在热点代码路径中，会对Function.identity()的调用进行消除优化。当代码被频繁执行时，JIT会内联apply()方法，发现其仅返回输入后，会直接跳过该调用，直接执行后续函数逻辑。但这种优化仅针对热点代码，冷代码或未被JIT编译的代码仍会保留额外的调用开销。

四、是否应该提交JDK改进提案？ #

如果要提交提案，需要先明确几点：

1. 性能收益的显著性：需通过基准测试证明，这类优化在实际场景中能带来可感知的性能提升——毕竟JIT已经能处理热点场景，冷场景的开销通常可以忽略。
2. 兼容性风险的可控性：需要调研现有生态中是否存在依赖组合函数结构的代码，确保优化不会引发大规模兼容问题。
3. 符合JDK优化方向：JDK更倾向于通用底层优化，而非单个API的特例优化，除非该特例的收益极大且无副作用。

五、可选转换场景的性能影响 #

在可选转换场景中用Function.identity()替代null以避免空检查，如果实现上述优化，确实能完全消除额外调用开销；若未实现，JIT在热点场景也能自动优化，但冷场景会有微小的调用成本。不过这种成本在绝大多数应用中可以忽略，仅极端性能敏感场景需要关注。

内容的提问来源于stack exchange，提问作者Garret Wilson