Java Stream排序避坑指南：Comparator.comparing()的深度优化实践

当你第一次在项目中使用Stream.sorted()时，可能会觉得它简洁优雅——直到某个深夜，生产环境突然抛出NullPointerException，或者发现某个核心接口的响应时间从200ms飙升到2秒。这不是魔法失效，而是Comparator的陷阱在作祟。作为处理过数十个类似案例的技术顾问，我想分享那些文档里不会告诉你的实战经验。

1. 当排序遇上null：不是所有字段都那么可靠

我们经常假设数据是完整的，但现实往往打脸。假设我们要对一个员工列表按部门名称排序：

java复制List<Employee> sorted = employees.stream()
    .sorted(Comparator.comparing(Employee::getDepartmentName))
    .toList();

当某个员工的departmentName为null时，这段代码会立即崩溃。更棘手的是，这种问题可能在测试阶段完全不被发现，直到生产环境遇到边缘案例。

解决方案矩阵：

实际案例中，我推荐这样重构：

java复制// 安全版本：null值排在最后
Comparator<Employee> safeComparator = 
    Comparator.comparing(
        Employee::getDepartmentName,
        Comparator.nullsLast(String::compareTo)
    );

List<Employee> sorted = employees.stream()
    .sorted(safeComparator)
    .toList();

注意：nullsFirst/nullsLast在JDK8中存在一个隐蔽bug——当所有比较元素都为null时可能抛出NullPointerException，这在JDK9中已修复。如果必须使用JDK8，建议额外添加null检查。

2. 性能黑洞：自动装箱的隐藏成本

考虑这个看似无害的排序操作：

java复制List<Product> products = ... // 来自数据库
List<Product> sorted = products.stream()
    .sorted(Comparator.comparing(Product::getInventory))
    .toList();

当getInventory()返回int时，每次比较都会发生：
1