Java可变参数使用陷阱与最佳实践

1. 可变参数的设计初衷与潜在风险

Java从1.5版本开始引入可变参数(varargs)特性，允许方法接受数量不定的同类型参数。这个语法糖的本质是编译器自动将参数包装为数组，例如void foo(String... args)实际会被编译为void foo(String[] args)。看似便利的特性背后，却隐藏着几个容易被忽视的陷阱。

我在实际项目中最深刻的教训来自一个日志工具类的设计。最初为了灵活性，将所有日志方法都设计为可变参数形式，比如logDebug(String format, Object... args)。上线初期运行良好，直到某天监控系统报警显示某个服务CPU使用率飙升。通过JProfiler定位发现，大量日志调用产生了不必要的临时数组对象，在热点路径上累计产生了显著的GC压力。

关键教训：可变参数方法每次调用都会隐式创建数组对象，高频调用场景下会产生对象分配开销

另一个典型案例是参数校验问题。考虑下面这个方法签名：

java复制void processItems(String operation, Item... items) {
    if (items == null) {
        throw new NullPointerException("items cannot be null");
    }
    // 处理逻辑
}

当开发者调用processItems("update")时，items参数实际上是一个空数组而非null。但如果调用processItems("update", null)，items参数将变成包含一个null元素的数组。这种不一致性往往导致NPE出现在意料之外的位置。

2. Effective Java第53条的核心主张

Joshua Bloch在《Effective Java》第53条中明确指出："慎用可变参数"。这条建议基于以下几个关键考量：

2.1 性能敏感场景的代价

可变参数方法在每次调用时都会执行数组创建和初始化操作。对于性能关键路径上的方法，这种开销可能成为瓶颈。Bloch建议在这种情况下使用固定参数重载模式：

java复制// 不推荐的写法
public void foo(int... args) { /*..