Java可变参数为何基于数组实现？历史原因探究

• 历史兼容性与实现成本优先
  Java的可变参数是JDK 1.5才加入的特性，当时核心目标是在不改动JVM底层规范的前提下，给开发者提供可变参数的语法便利。数组作为Java原生的核心类型，JVM对其内存分配、类型检查、方法调用的逻辑已经非常成熟。基于数组实现可变参数，只需要在编译阶段做语法糖转换：把func(T... args)编译成func(T[] args)，调用方传入的多个参数会自动被打包成数组。这种实现方式几乎不需要修改JVM，开发成本低，还能完美兼容旧版本的字节码和运行环境。

• 与Java类型系统的天然适配
  Java是静态类型语言，所有参数都需要明确的类型。数组作为引用类型，能很好地融入现有的类型体系——可变参数的类型可以是任意引用类型或基本类型（基本类型会自动装箱成包装类数组）。而C的参数包是模板元编程的产物，依赖编译期的模板展开生成不同的函数实例，这和Java依赖运行时类型信息的设计思路完全不同。如果Java要实现类似C的参数包，需要对类型系统、编译流程甚至JVM做大幅改造，这在当时的版本迭代中是不现实的。

• 解包限制的本质是设计取舍
  你提到的无法直接转发参数（解包）的问题，确实是数组实现的固有局限——因为可变参数在编译后就是数组，要转发给另一个可变参数方法，要么手动遍历数组逐个传参，要么借助反射。但这也是当初设计时的取舍：为了兼容现有体系、降低实现成本，牺牲了部分语法灵活性。后续Java虽然通过Stream API、工具类（比如Arrays.stream(args).forEach(...)）提供了一些间接的处理方式，但本质还是绕不开数组的底层实现。

另外你提到的EnumSet.of(...)重载规避可变参数，更多是性能优化层面的选择——数组创建会带来额外的内存开销和初始化成本，对于频繁调用的工具方法，重载固定参数的版本能避免这些损耗，但这并不是否定数组实现可变参数的设计初衷，只是特定场景下的优化手段。

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