返回专用可选类型的调用函数是否以在热代码路径中使用时增加GC压力为代价,而不是返回原始值以指示缺失(Integer.MIN_VALUE例如)？
编辑
我不仅仅假设他们会像任何其他类一样执行堆分配的原因是Optional,等等,是" 基于价值的类 ",这似乎意味着他们的行为可能与幕后的传统类不同.
返回专用可选类型的调用函数是否以在热代码路径中使用时增加的GC压力为代价
这取决于™.通常,Optional类型只是常规对象,因此堆分配.但在特定情况下,JIT编译器可能会将它们分解为它们的字段(即它们保存的值)并将它们放在堆栈中.
如果转义分析可以确定对象没有全局转义到堆上,则会发生这种情况.
似乎还有一些隐藏在旗帜后面的实验性优化(-XX:+AggressiveUnboxing部分-XX:+AggressiveOpts).据我了解,他们可以打破身份保证Integer.valueOf(int),因此不完全符合规范.
切线:实验/研究Graal编译器甚至更进一步,并且具有部分转义分析,可以将分配推迟到对象确实转义的那些代码路径,而当它们不进行标量分解时.这还不是常规虚拟机的一部分,主要由运行在JVM上的非Java语言使用,例如JRuby和Nashorn.
由于所有这些都是运行时优化,因此不能保证会发生这种情况.因此,您必须使用诊断标志来衡量效果或跟踪编译器决策.
我不仅仅假设他们会像任何其他类一样执行堆分配的原因是Optional,et al,是"基于价值的类"
我认为目前这些属性只是为了确保对象是不可变的和线程安全的.我不知道EA之外的任何优化是否都使用了互换性属性.
我怀疑规范语言主要是为了在最终作为项目valhalla的一部分到达Java时提供正确的值类型的前向兼容性.
遵循这些规则还可以使转义分析/堆栈分配更容易.