Collections.emptyList()和
Collections.emptyMap()是 Java 中用来获取不可变空列表和空映射的便捷方法，它们的核心价值在于提供一个始终为空且不可修改的集合实例，避免返回
null，从而显著提升代码的健壮性、可读性，并优化资源使用。
解决方案
在Java中使用
Collections.emptyList()和
Collections.emptyMap()非常直接。它们是
java.util.Collections类提供的静态工厂方法，用于返回预先定义好的、不可变的空集合单例。
当你需要一个空列表，并且不希望它被修改时，可以直接调用：
List<String> emptyStringList = Collections.emptyList();
// 尝试修改会抛出 UnsupportedOperationException
// emptyStringList.add("item"); // 运行时错误同样地，对于空映射：
立即学习“Java免费学习笔记（深入）”；
Map<String, Integer> emptyStringIntegerMap = Collections.emptyMap();
// 尝试修改会抛出 UnsupportedOperationException
// emptyStringIntegerMap.put("key", 1); // 运行时错误这些方法返回的实际上是同一个
EmptyList或
EmptyMap实例，这意味着它们非常节省内存，因为无论你调用多少次，都只会得到一个共享的、不可变的对象。这对于API设计尤其有用，比如一个方法在某些情况下可能没有结果，但你又不希望返回
null，因为那会强制调用者进行
null检查，增加代码的复杂度。
public List<User> 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<User> users = userService.findUsersByCriteria();
// 不管 users 是空的还是有内容的，下面的代码都不会抛出 NPE
for (User user : users) {
System.out.println(user.getName());
}
// 或者
if (users.isEmpty()) {
System.out.println("没有找到用户。");
}相比之下，如果方法返回
null，调用方就必须写成这样：
List<User> 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<String> buildMessageList(boolean includeHeader, boolean includeFooter) {
// 假设这里需要一个可变的列表，后续会添加内容
// List<String> messages = Collections.emptyList(); // 错误！后续无法添加
List<String> 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<String> emptyListModern = List.of();
// 尝试修改会抛出 UnsupportedOperationException
// emptyListModern.add("item");
// 创建一个空的不可变映射
Map<String, Integer> emptyMapModern = Map.of();
// 尝试修改会抛出 UnsupportedOperationException
// emptyMapModern.put("key", 1);这些方法与
Collections.emptyList()和
Collections.emptyMap()有着相似的核心特性：
-
不可变性：它们返回的集合也是不可修改的。任何修改操作都会抛出
UnsupportedOperationException
。 -
非空性：它们同样不会返回
null
，而是返回一个真实存在的空集合实例。 -
内存效率：对于空集合，
List.of()
和Map.of()
通常也会返回内部的单例实例，类似于Collections
类的方法，从而节省内存。
那么，它们之间有什么区别，或者说，我该如何选择呢？
从功能上讲，对于创建空集合，
List.of()和
Collections.emptyList()几乎是等效的，
Map.of()和
Collections.emptyMap()也是如此。主要的区别在于：
-
简洁性：
List.of()
和Map.of()
在语法上可能更简洁，因为它们是接口方法，直接与你正在使用的集合类型关联。你不需要通过Collections
这个工具类来访问它们。 -
多功能性：
List.of()
和Map.of()
不仅仅能创建空集合，它们还可以方便地创建包含少量元素的不可变集合。例如：List<String> names = List.of("Alice", "Bob", "Charlie"); Map<String, Integer> ages = Map.of("Alice", 30, "Bob", 25);这使得它们在创建小规模固定集合时非常方便，避免了手动
add()
或put()
的繁琐。而Collections.emptyList()
只能创建空集合。 -
语义：
Collections.emptyList()
更强调“空”这一特定状态的单例。而List.of()
则是更通用的不可变集合工厂，空只是其一个特例。
在实际项目中，如果你使用的是 Java 9 或更高版本，并且你的代码风格偏好现代 Java 的简洁性，那么使用
List.of()和
Map.of()来创建空集合是非常自然且推荐的做法。它们与创建非空不可变集合的方法保持了一致性，使得代码更加统一。当然，继续使用
Collections.emptyList()也没有任何问题，它依然是完全有效且广泛使用的。选择哪一个，更多时候是个人偏好和团队代码规范的体现。
