treemap在多线程未同步访问时可能引发内部红黑树结构损坏，进而触发无限循环，造成线程持续占用cpu而不阻塞，表现为“卡死”假象。根本原因并非简单数据不一致，而是并发修改破坏了树的平衡 invariant，使遍历逻辑陷入死循环。
treemap在多线程未同步访问时可能引发内部红黑树结构损坏，进而触发无限循环，造成线程持续占用cpu而不阻塞，表现为“卡死”假象。根本原因并非简单数据不一致，而是并发修改破坏了树的平衡 invariant，使遍历逻辑陷入死循环。
TreeMap 是基于红黑树实现的有序映射（SortedMap），其 put()、get() 等操作依赖严格的树结构平衡性与节点链接关系。虽然 TreeMap 本身是线程不安全的（Javadoc 明确声明），但许多开发者误以为“不安全=仅结果不准”，忽视了更严重的底层危害：并发写入可破坏红黑树的内部指针结构（如 left/right/parent 引用），导致后续任意读操作（包括 get()、containsKey()，甚至 size() 或迭代器遍历）进入无限循环。
这种无限循环并非 Java 层面的显式 while(true)，而是因节点链表成环（例如 node.left == node 或 node.parent == node.right）或高度失衡引发的递归/迭代无法终止。线程持续执行空转，CPU 使用率飙升至 100%，而线程状态在 dump 中仍显示为 RUNNABLE（而非 BLOCKED 或 WAITING），极具迷惑性。
✅ 正确解决方案（按优先级推荐）
-
首选：使用线程安全的替代实现
ConcurrentSkipListMap 是最直接的替换方案——它提供与 TreeMap 相近的 O(log n) 平均时间复杂度、自然排序语义，且完全线程安全，无需额外同步：// 替换前（危险） Map<String, Integer> map = new TreeMap<>(); // 替换后（安全） Map<String, Integer> map = new ConcurrentSkipListMap<>();
⚠️ 注意：ConcurrentSkipListMap 不保证强一致性（如 size() 是近似值），但满足绝大多数高并发场景的排序与查找需求。
立即学习“Java免费学习笔记（深入）”；
-
次选：显式同步（仅适用于低并发或已存在锁粒度控制的场景）
若必须保留 TreeMap（如依赖其 subMap() 等特有 API），需确保所有访问（读+写）均受同一锁保护：private final TreeMap<String, Integer> treeMap = new TreeMap<>(); private final Object lock = new Object(); public Integer get(String key) { synchronized (lock) { return treeMap.get(key); } } public void put(String key, Integer value) { synchronized (lock) { treeMap.put(key, value); } }❗ 避免仅对 put() 加锁而忽略 get() —— 读操作同样可能触发无限循环。
-
禁止方案
- 使用 Collections.synchronizedSortedMap(new TreeMap<>())：该包装仅同步单个方法调用，无法防止复合操作（如 if (!map.containsKey(k)) map.put(k, v)）的竞态，且不解决底层结构破坏问题；
- 在 put() 内部加锁但放任其他线程调用 get()：无效，因 get() 的无限循环独立发生。
? 快速诊断技巧
- 查看线程堆栈：若多个线程长期停留在 TreeMap.getEntry()、TreeMap.get() 或 TreeMap$EntryIterator.next() 等方法中，且状态为 RUNNABLE，高度可疑；
- 检查是否所有 TreeMap 实例均被严格隔离于单线程上下文（如 Spring 的 @Scope("prototype") Bean 且不跨线程共享）。
总之，TreeMap 的线程不安全性是“破坏性”的，而非“容忍性”的。在并发环境中，永远不要寄希望于“运气好不崩溃”，而应通过 ConcurrentSkipListMap 或严谨的同步机制从根源杜绝风险。
