Java 9中List.of()创建三元素集合为何返回ListN而非List3？

这是个非常好的问题！其实Java团队这么设计，是在性能优化、代码维护性和JVM资源占用三者之间做的权衡决策，咱们来一步步理清楚：

1. 避免类膨胀，减少JVM负担 #

如果为每一种参数数量都单独创建对应的类（比如List3、List4...List100），那JDK的源码里会出现大量逻辑几乎完全一致的类。这不仅会让JDK本身的代码变得臃肿不堪，还会增加JVM的类加载开销——每个类都需要占用内存、加载到方法区，对于参数数量不确定的场景来说，这种做法的性价比极低。

而List2是个特例：双元素的不可变List在实际开发中使用频率很高，专门为它做一个定制化实现（比如直接用两个字段存储元素，不需要数组），能带来实实在在的性能收益，所以值得单独创建。但超过2个元素之后，再逐个定制类就不划算了。

2. 复用通用实现，降低维护成本 #

ListN是一个可以处理任意≥3个元素的通用实现类，内部用数组来存储元素，核心逻辑（比如get、size、遍历等）和List2基本一致，但不需要为不同的参数数量重复编写几乎相同的代码。

这样一来，JDK的维护者只需要维护ListN这一个类，就能覆盖所有3个及以上元素的不可变List场景，大大降低了代码维护的复杂度和出错概率。

3. 性能收益的边际效应递减 #

你可能会好奇：专门的List3会不会比ListN更快？其实对于绝大多数业务场景来说，这种性能差异微乎其微。ListN的实现已经足够高效（直接访问数组元素），而为每个参数数量定制类带来的性能提升，远抵不上类膨胀带来的代价。Java团队更倾向于把优化精力放在高频场景（比如List1、List2），而通用场景则复用统一实现。

咱们可以看看List.of的重载源码，更直观：

// 双元素场景：用专门的List2
static <E> List<E> of(E e1, E e2) {
    return new ImmutableCollections.List2<>(e1, e2);
}

// 三元素及以上：直接复用ListN
static <E> List<E> of(E e1, E e2, E e3) {
    return new ImmutableCollections.ListN<>(e1, e2, e3);
}

// 可变参数场景：同样用ListN
static <E> List<E> of(E... elements) {
    return new ImmutableCollections.ListN<>(elements);
}

总结一下：Java团队选择ListN而非逐个创建List3、List4等类，是为了在性能、代码可维护性和JVM资源占用之间找到最优平衡——只对最常见的少量元素场景做定制优化，更多元素的场景则复用通用实现，兼顾了效率和实用性。

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