collections.max 报 nosuchelementexception 是因空集合无元素可比较，须先校验非空；comparator 错误、泛型不匹配、忽略 null 及类型安全、滥用性能不佳场景均需规避。
为什么 Collections.max 报 NoSuchElementException
空集合调用 Collections.max 一定会抛这个异常，它不接受 null 或空 Collection。不是“没找到”，而是根本没东西可比。
- 检查前必须确认
collection != null && !collection.isEmpty() - 如果来源不可控（比如从 HTTP 请求解析的 JSON 列表），别直接传进去，先兜底
- 替代方案：用
Stream.max()配合orElse(null)或orElseThrow()，语义更明确
Comparator 传错导致结果反直觉
写错比较逻辑是最大雷区——比如把 a - b 写成 b - a，或者在字符串比较里漏掉 String::compareTo 的 null 安全处理。
- 数值比较慎用
(a, b) -> a - b：整数溢出时会翻转符号（Integer.MAX_VALUE - (-1)得负数） - 推荐用
Integer.compare(a, b)或Comparator.naturalOrder() - 涉及可能为
null的字段，别手写if (a == null) return -1，直接用Comparator.nullsFirst(Comparator.naturalOrder())
泛型擦除后类型不匹配的隐性错误
当你传入 Collection<string></string> 却写了 Comparator<integer></integer>，编译器可能不报错（尤其用了 raw type 或方法引用），但运行时会抛 ClassCastException。
- 错误示例：
Collections.max(list, Comparator.comparing(s -> Integer.parseInt(s)))—— 如果list里混了非数字字符串，解析阶段就崩了，不是max崩 - 真正安全的做法：确保
Comparator输入类型和集合元素类型一致，必要时先stream().filter(...).collect(...)过滤 - IDE 一般能标出泛型不匹配，但 Lambda 表达式容易绕过检查，多看一眼参数类型提示
性能敏感场景下别滥用 Collections.max
它本质是遍历一次，时间复杂度 O(n)，没问题；但如果你已经在用 TreeSet 或 PriorityQueue，再调 max 就浪费了数据结构特性。
立即学习“Java免费学习笔记（深入）”；
-
TreeSet直接用last()，O(log n) 查找变 O(1) -
PriorityQueue没有高效取最大值接口（默认小顶堆），要取最大得换Comparator.reverseOrder()初始化，否则得全倒出来 - 频繁查最大值 + 动态增删？考虑
TreeSet或维护一个变量，别每次都扫集合
实际用的时候，最常卡住人的不是语法，是没想清楚「这个集合是不是真能比」「比的依据有没有隐藏的 null 或类型风险」「我是不是在拿锤子砸螺丝」。
