ConcurrentSkipListMap适用于需线程安全且支持按键自然序遍历、范围查询或获取最值的场景；底层跳表实现O(log n)平均时间复杂度，无锁但吞吐低于ConcurrentHashMap；要求key可比较，不支持null key，subMap等视图实时可变但弱一致性。
ConcurrentSkipListMap 适合什么场景
它不是用来替代 ConcurrentHashMap 的通用并发 map，而是当你**既要线程安全，又要按 key 自然序遍历、范围查询（比如 subMap、headMap）或获取最小/最大 key** 时的明确选择。底层跳表结构决定了它支持 O(log n) 平均时间的查找、插入、删除，且无锁（基于 CAS），但比 ConcurrentHashMap 的平均吞吐略低。
常见误用：单纯为了“并发安全”就选它——如果不需要有序性，用 ConcurrentHashMap 更快更省内存。
初始化和基本操作要注意 key 类型
ConcurrentSkipListMap 要求 key 必须实现 Comparable，或者构造时传入 Comparator。否则运行时抛 ClassCastException 或 NullPointerException（尤其在首次插入 null key 时）。
无序插入不会报错，但后续调用 firstKey()、ceilingKey() 等方法会直接失败。
立即学习“Java免费学习笔记（深入）”；
- 推荐显式传
Comparator，避免依赖 key 自身compareTo的隐式行为 - key 为自定义类时，确保
compareTo与equals逻辑一致（虽然跳表不依赖equals判等，但业务逻辑常混用） - 不要往里塞
nullkey——构造器允许 null value，但 key 为 null 会立即触发NullPointerException
range 查询（subMap / headMap / tailMap）是强一致性视图
返回的子 map 是原 map 的**实时、可变、弱一致性视图**：写操作会反映到子 map 中，子 map 的修改也会影响原 map。但它不加锁，所以遍历时可能看到部分更新状态（如某次插入只完成一半节点链接）。
典型陷阱：
- 对
subMap调用size()可能慢（需遍历计数），别在高频路径里用 -
subMap(k1, k2)的区间是左闭右开（k1 ≤ key ），和 <code>TreeMap一致，但容易看错边界 - 若原 map 在子 map 创建后发生了大量删除，子 map 迭代器仍可能短暂访问到已逻辑删除但物理未清理的节点（跳表层级清理有延迟）
性能和内存开销比 TreeMap 高，但比 synchronized TreeMap 更稳
跳表每个节点平均持有 log n 个层级指针，内存占用比 TreeMap（红黑树）高约 20%–40%；插入/删除因多层 CAS 操作，单次耗时略长。但它完全无锁，不会像 Collections.synchronizedSortedMap(new TreeMap()) 那样在遍历时全局阻塞其他线程。
关键取舍点：
- 读多写少 + 需要范围查询 →
ConcurrentSkipListMap是合理选择 - 写非常密集（如每微秒插入千次）+ 不需要有序 → 回退到
ConcurrentHashMap+ 外部排序 - 要求强顺序一致性（如金融账本逐条严格有序）→ 它不保证操作全局顺序，得加额外同步或换日志结构
跳表的“并发友好”来自结构松散性，代价是无法提供类似数据库事务那样的顺序保证——这点很容易被忽略，尤其在做分布式状态同步时。
