PECS原则不适用于ConcurrentSkipListMap的Comparator，因其构造器中Comparator类型参数为固定泛型E，未使用通配符，不存在生产者/消费者场景下的类型安全扩展或收缩需求。
PECS（Producer Extends, Consumer Super）原则在 ConcurrentSkipListMap 的比较器使用中并不直接适用，因为它的构造器和方法签名中对 Comparator 的泛型约束是固定的，不涉及通配符类型参数的生产/消费场景。
为什么 PECS 不适用于 ConcurrentSkipListMap 的 Comparator
ConcurrentSkipListMap 的构造器声明为：
public ConcurrentSkipListMap(Comparator super K> comparator)
这里明确使用了 ? super K —— 这本身就是 PECS 中“Consumer Super”的体现，但它是 JDK 设计者早已固化好的契约，并非由调用方自由选择通配符形式。你不能传入 Comparator extends K>，否则编译失败；也不需要、也不允许你主动应用 PECS 去“推导”该写法。
立即学习“Java免费学习笔记（深入）”；
原因在于：Comparator 在跳表中纯粹作为消费者：它只接收 K 类型（或其父类）的两个键进行比较，从不返回键、也不产出 K 实例。它不“生产”任何 K，所以 extends 没有意义。
Comparator super K> 的实际含义与好处
这个上界通配符让比较器具备了更宽泛的适用性。例如：
- 若你有一个
ConcurrentSkipListMap<String>，可以安全传入Comparator<CharSequence>（因为String是CharSequence的子类） - 若你有
ConcurrentSkipListMap<LocalDateTime>，可复用Comparator<Temporal>（只要逻辑合理）
这种灵活性来自类型系统对“消费能力”的放宽——只要比较器能处理 K 及其所有子类型（实际只需处理 K），就满足契约。跳表内部只把键当作 K 传给比较器，不关心其具体子类。
跳表结构本身不引入额外泛型协变/逆变需求
不同于 Collection<? extends T>（生产者，用 extends）或 Collection<? super T>（消费者，用 super），ConcurrentSkipListMap 的键值对存储是具体类型（K, V），其迭代器、导航方法（如 subMap、headMap）返回的视图也保持原始类型参数，未暴露需手动适配的通配符边界。
也就是说：你用 ConcurrentSkipListMap<Number> 存 Integer 和 Double，比较器写成 Comparator<Number> 即可；无需、也无法用 Comparator<? super Number> 去“加强”类型安全——那反而会限制可传入的比较器范围。
真正要注意的是比较器的一致性，而非 PECS 选择
跳表依赖比较器结果维持有序性和正确查找。务必确保：
- 比较器满足自反性、对称性、传递性、一致性
- 不要混用自然排序与自定义比较器（避免
ClassCastException） - 若键为
null，比较器必须显式支持（否则抛NullPointerException）
这些约束远比纠结“是否用了 PECS”关键得多。跳表的并发安全和 O(log n) 性能，都建立在比较逻辑稳定可靠的基础上。
