返回多值的最佳实践：自定义对象与Object数组的性能对比

针对你提出的两种返回多类型数据的方案，结合大规模系统的性能放大效应，我从CPU开销、内存占用、序列化适配三个维度逐一分析：

1. CPU开销对比 #

方案二（返回Object[]）的CPU开销会显著更高，核心原因有两点：

• 每次从数组中取值都需要执行强制类型转换（比如(Integer) arr[0]），这个操作会触发JVM的类型检查逻辑，在高频访问场景下会累积大量额外CPU消耗；
• 基本类型存入Object[]时会自动装箱（比如int转Integer），取出时自动拆箱，这两个过程会产生额外的对象创建与销毁开销，进一步加重CPU负担。

而方案一的自定义Stock对象，直接通过字段访问数据，不需要类型转换和拆装箱操作，JVM还能对字段访问做针对性优化（比如缓存字段偏移量），CPU效率会高很多，在大规模调用场景下差异会被显著放大。

2. 内存占用对比 #

方案二的内存占用远大于方案一，根源是装箱带来的额外开销：

• 自定义Stock对象中，所有基本类型字段直接存储在对象内存中，一个Stock实例的内存占用大概是：对象头（12字节，64位JVM） + 4(int price) + 4(int profitability) + 8(double currentTrend) + 4(int mostRecentSpike) + 8(long timeOfRecentSpike)，加上内存对齐字节，总共约40字节左右（具体取决于JVM对齐规则）；
• 而Object[]方案中，每个基本类型都要被装箱成对应的包装类（Integer、Double、Long），每个包装类实例至少占用16字节（对象头12字节+基本值，对齐到16），再加上数组本身的开销（对象头+5个引用，64位JVM下数组本身约52字节），总内存占用是52 + 16*3（三个Integer） + 16（Double） +16（Long）= 132字节，是方案一的3倍以上。在大规模实例场景下，这种内存差异会直接导致更高的GC频率，进一步拖慢系统性能。

3. 序列化场景适配 #

方案一（自定义Stock对象）完全碾压方案二，理由如下：

• 主流序列化框架（如Jackson、Kryo、Java Serializable）对自定义POJO的支持更完善，序列化时可以直接遍历字段写入，不需要额外存储类型信息，序列化后的体积更小、效率更高；
• 反序列化时，自定义对象可以直接映射到对应字段，不需要手动做类型转换，避免了类型转换错误的风险，同时反序列化效率也更高；
• 自定义对象还支持灵活的序列化优化（比如用transient修饰不需要序列化的字段、使用更高效的序列化注解），而Object[]的序列化需要存储每个元素的类型信息，不仅体积大，还容易出现兼容性问题（比如数组元素顺序变动导致反序列化失败）。

额外补充 #

虽然你更关注性能，但还是要提一句：方案一的代码可读性、可维护性远高于方案二，在大规模系统中，代码的可维护性会间接影响迭代效率和bug率，这也是一个不可忽视的长期收益。

内容的提问来源于stack exchange，提问作者Kael Eppcohen