17370845950

Collections.emptyList()

和

Collections.emptyMap()

是 Java 中用来获取不可变空列表和空映射的便捷方法，它们的核心价值在于提供一个始终为空且不可修改的集合实例，避免返回

null

，从而显著提升代码的健壮性、可读性，并优化资源使用。

解决方案

在Java中使用

Collections.emptyList()

和

Collections.emptyMap()

非常直接。它们是

java.util.Collections

类提供的静态工厂方法，用于返回预先定义好的、不可变的空集合单例。

当你需要一个空列表，并且不希望它被修改时，可以直接调用：

List emptyStringList = Collections.emptyList();
// 尝试修改会抛出 UnsupportedOperationException
// emptyStringList.add("item"); // 运行时错误

同样地，对于空映射：

Map emptyStringIntegerMap = Collections.emptyMap();
// 尝试修改会抛出 UnsupportedOperationException
// emptyStringIntegerMap.put("key", 1); // 运行时错误

这些方法返回的实际上是同一个

EmptyList

或

EmptyMap

实例，这意味着它们非常节省内存，因为无论你调用多少次，都只会得到一个共享的、不可变的对象。这对于API设计尤其有用，比如一个方法在某些情况下可能没有结果，但你又不希望返回

null

，因为那会强制调用者进行

null

检查，增加代码的复杂度。

public List findActiveUsers() {
    // 假设查询数据库，如果没有任何活跃用户
    // return null; // 这样做很糟糕
    // return new ArrayList<>(); // 每次都创建新对象，浪费资源
    return Collections.emptyList(); // 最优雅和高效的方式
}

使用它们，你的代码会变得更安全，因为你明确地传递了一个空但合法的集合，调用方可以放心地遍历或调用集合方法，而无需担心

NullPointerException

。

为什么在Java中推荐使用Collections.emptyList而不是返回null或创建新实例？

这其实是一个关于代码健壮性、可读性和资源效率的权衡。我个人在编写代码时，总是倾向于避免

null

返回值，因为它就像一个隐藏的定时炸弹，随时可能在不经意间引爆

NullPointerException

。想象一下，一个方法返回

null

，而调用方忘记了检查，然后尝试对这个

null

调用

size()

或

iterator()

，结果就是程序崩溃。这不仅让调试变得痛苦，也让API的使用变得小心翼翼。

Collections.emptyList()

或

Collections.emptyMap()

的出现，完美地解决了这个问题。它们返回的是一个真实存在的、但内容为空的集合对象。这意味着调用方可以安全地对其进行操作，比如：

List users = userService.findUsersByCriteria();
// 不管 users 是空的还是有内容的，下面的代码都不会抛出 NPE
for (User user : users) {
    System.out.println(user.getName());
}
// 或者
if (users.isEmpty()) {
    System.out.println("没有找到用户。");
}

相比之下，如果方法返回

null

，调用方就必须写成这样：

List users = userService.findUsersByCriteria();
if (users != null) { // 额外的 null 检查
    for (User user : users) {
        System.out.println(user.getName());
    }
} else {
    System.out.println("没有找到用户。");
}

这不仅增加了样板代码，也使得业务逻辑的表达变得不那么流畅。

再来说说为什么不应该频繁地

return new ArrayList<>()

或

new HashMap<>()

。虽然这样做也能提供一个空的、非

null

的集合，但每次调用都会在堆上分配新的内存空间来创建一个新的集合对象。对于那些可能频繁被调用且大部分时间返回空结果的方法来说，这会造成不必要的内存开销和垃圾回收压力。而

Collections.emptyList()

和

Collections.emptyMap()

返回的是单例，它们在整个应用程序生命周期中只会被创建一次。这在内存效率上是无可比拟的优势，尤其是在高并发或资源受限的环境下，这种优化是很有价值的。

所以，从我的经验来看，使用

Collections.emptyList()

是一种更优雅、更安全、更高效的编程实践。它体现了“空对象模式”的思想，让你的代码更具弹性。

Collections.emptyList和emptyMap有哪些潜在的局限性或不适用场景？

尽管

Collections.emptyList()

和

Collections.emptyMap()

带来了诸多便利，但它们并非万能药，在某些特定场景下，使用它们反而可能带来不便或不适用。理解这些局限性，能帮助我们做出更明智的选择。

首先，最核心的限制就是不可变性。这两个方法返回的集合是完全不可修改的。任何尝试添加、删除或修改元素的操作都会导致

UnsupportedOperationException

。这在大多数情况下是其优点，因为它强制了空集合的“空”状态，避免了意外的修改。但如果你的业务逻辑要求，即使在最初是空的情况下，后续也可能需要向这个集合中添加元素，那么

Collections.emptyList()

就不是一个合适的选择。

例如，你可能有一个方法，它初始化一个列表，然后根据某些条件往里面添加元素：

public List buildMessageList(boolean includeHeader, boolean includeFooter) {
    // 假设这里需要一个可变的列表，后续会添加内容
    // List messages = Collections.emptyList(); // 错误！后续无法添加
    List messages = new ArrayList<>(); // 正确做法
    if (includeHeader) {
        messages.add("--- Header ---");
    }
    // ... 添加其他消息 ...
    if (includeFooter) {
        messages.add("--- Footer ---");
    }
    return messages;
}

在这种情况下，即使初始时列表是空的，你也需要一个

ArrayList

或其他可变集合的实例。

其次，虽然

emptyList()

和

emptyMap()

是泛型的，但它们返回的实际类型是

EmptyList

和

EmptyMap

，它们是

Collections

类的私有静态内部类。在绝大多数情况下，这并不影响使用，因为它们正确实现了

List

和

Map

接口。然而，如果你有非常特殊的反射需求，或者需要对集合的具体实现类型进行判断（这通常不是一个好实践），可能会遇到一些意料之外的行为。但说实话，这种场景极少见，并且通常暗示着设计上的问题。

再者，对于 Java 9 引入的

List.of()

和

Map.of()

这样的工厂方法，它们也能创建不可变的空集合。虽然功能上类似，但

Collections.emptyList()

在语义上更强调“空”的单例特性，而

List.of()

则更侧重于创建包含零个或多个元素的不可变集合。在实际使用中，它们可以互换使用来表示空集合，但了解其细微差别有助于选择最符合意图的方法。

总的来说，当你的集合在整个生命周期中都必须保持为空，并且不接受任何修改时，

Collections.emptyList()

和

Collections.emptyMap()

是极佳的选择。一旦有任何后续修改的需求，哪怕是初始为空，也应该选择可变集合，如

ArrayList

或

HashMap

。

除了Collections.emptyList/emptyMap，Java 9+还有哪些创建不可变空集合的现代方法？

Java 9 及更高版本为创建不可变集合引入了更简洁、更直观的工厂方法，这在一定程度上提供了

Collections.emptyList()

和

Collections.emptyMap()

的现代替代方案。这些新方法主要集中在

List

、

Set

和

Map

接口本身上。

最值得一提的就是

List.of()

和

Map.of()

方法。它们是接口的静态工厂方法，用于创建不可变集合。当不传入任何参数时，它们就会创建空集合：

// 创建一个空的不可变列表
List emptyListModern = List.of();
// 尝试修改会抛出 UnsupportedOperationException
// emptyListModern.add("item");

// 创建一个空的不可变映射
Map emptyMapModern = Map.of();
// 尝试修改会抛出 UnsupportedOperationException
// emptyMapModern.put("key", 1);

这些方法与

Collections.emptyList()

和

Collections.emptyMap()

有着相似的核心特性：

1. 不可变性：它们返回的集合也是不可修改的。任何修改操作都会抛出

   UnsupportedOperationException

   。
2. 非空性：它们同样不会返回

   null

   ，而是返回一个真实存在的空集合实例。
3. 内存效率：对于空集合，

   List.of()

   和

   Map.of()

   通常也会返回内部的单例实例，类似于

   Collections

   类的方法，从而节省内存。

那么，它们之间有什么区别，或者说，我该如何选择呢？

从功能上讲，对于创建空集合，

List.of()

和

Collections.emptyList()

几乎是等效的，

Map.of()

和

Collections.emptyMap()

也是如此。主要的区别在于：

• 简洁性：

  List.of()

  和

  Map.of()

  在语法上可能更简洁，因为它们是接口方法，直接与你正在使用的集合类型关联。你不需要通过

  Collections

  这个工具类来访问它们。
• 多功能性：

  List.of()

  和

  Map.of()

  不仅仅能创建空集合，它们还可以方便地创建包含少量元素的不可变集合。例如：

  List names = List.of("Alice", "Bob", "Charlie");
  Map ages = Map.of("Alice", 30, "Bob", 25);

  这使得它们在创建小规模固定集合时非常方便，避免了手动

  add()

  或

  put()

  的繁琐。而

  Collections.emptyList()

  只能创建空集合。

• 语义：

  Collections.emptyList()

  更强调“空”这一特定状态的单例。而

  List.of()

  则是更通用的不可变集合工厂，空只是其一个特例。

在实际项目中，如果你使用的是 Java 9 或更高版本，并且你的代码风格偏好现代 Java 的简洁性，那么使用

List.of()

和

Map.of()

来创建空集合是非常自然且推荐的做法。它们与创建非空不可变集合的方法保持了一致性，使得代码更加统一。当然，继续使用

Collections.emptyList()

也没有任何问题，它依然是完全有效且广泛使用的。选择哪一个，更多时候是个人偏好和团队代码规范的体现。