TreeSet/TreeMap内容被覆盖？根因藏在可变对象和比较器里

做Java开发这些年，TreeSet和TreeMap我用得不算少。排序去重、排行榜维护、区间查询这些场景，它们都是非常趁手的工具。但我得坦白说，前阵子在一套内部排行榜模块里，我竟然被这两个容器搞得焦头烂额——业务方反馈榜单上的人变少了，排名错乱，还有玩家的积分数据被顶掉。第一反应是并发问题，查了一圈锁也没什么收获。后来写了个最小复现用例跑了一遍，才发现真正的问题是TreeSet内容被覆盖，而且根因不是集合本身，是我把对象放进去之后又改了它。

这篇文章就把这次排查的完整过程记录下来，包括底层原理、导致覆盖的几种典型写法，以及怎么改才能避开这些坑。如果你也习惯把可变对象丢进TreeSet或者塞进TreeMap当key，那这篇文章大概率能帮你省下半天排查时间。

1. 问题现场：排行榜数据莫名“缩水”

当时的需求很简单：某个内部活动排行榜，玩家实时得分，需要维护一个按分数排序的榜单，支持快速插入、更新、查询名次。第一版代码用的是TreeSet，玩家对象实现Comparable，比较器按分数从高到低排列。看起来人畜无害，上线后就开始出幺蛾子。

1.1 第一版代码长这样

Player对象和排行榜逻辑大致如下：

public class Player implements Comparable<Player> { private String playerId; private int score; public Player(String playerId, int score) { this.playerId = playerId; this.score = score; } public void setScore(int score) { this.score = score; } public int getScore() { return score; } public String getPlayerId() { return playerId; } @Override public int compareTo(Player other) { // 分数高的排前面，分数相同按ID排 int scoreCompare = Integer.compare(other.score, this.score); if (scoreCompare != 0) { return scoreCompare; } return this.playerId.compareTo(other.playerId); } }

TreeSet<Player> rankSet = new TreeSet<>(); Player playerA = new Player("A001", 100); rankSet.add(playerA); Player playerB = new Player("B002", 200); rankSet.add(playerB); Player playerC = new Player("C003", 150); rankSet.add(playerC);

这段代码插入三个玩家后，TreeSet内部会按分数降序排列：B002(200) > C003(150) > A001(100)。这个阶段一切正常。

1.2 复现：树结构没变，排序却错了

问题出在玩家分数变化之后。玩家A又完成了一个成就，积分从100涨到180。当时的代码是直接改字段，然后重新add：

playerA.setScore(180); rankSet.add(playerA);

你觉得这段代码会有问题吗？我告诉你，线上症状是：榜单顺序开始随机漂移，有时候少人，有时候名次不对。我用最小用例复现后，看到了非常典型的现象。

我把这三个玩家按顺序插入后，修改playerA的分数为180，再遍历输出：

B002 -> 200 C003 -> 150 A001 -> 180

按分数降序，正确输出应该是：

B002 -> 200 A001 -> 180 C003 -> 150

但TreeSet输出的结果是C003排在A001前面。原因很简单：TreeSet的树结构是在playerA分数还是100的时候构建的，它内部记录的大小关系是“playerA < playerC < playerB”。我把playerA的分数改成180后，这个大小关系已经变了，但红黑树的物理结构完全没动。于是遍历结果、first()、last()、contains()等一系列操作全部开始出错。

这还算是温和的。更诡异的是，如果你这时候去remove掉C003，会发现remove返回false——明明元素还在集合里，但顺着当前比较器走搜索路径，根本找不到那个节点。这一瞬间你的第一反应一定是：见鬼了。

1.3 一开始怀疑的方向

说实话，这种问题第一次遇到，任何人的直觉都是往并发上靠。我当时排查步骤是这样的：

• 先看有没有多个线程同时读写rankSet。线上确实有并发操作，但加锁后问题依旧。
• 再看是不是使用了ArrayList之类的非线程安全结构。检查发现排行榜确实是TreeSet。
• 再怀疑是不是玩家对象里的playerId重复了，导致TreeSet去重把“同一个人”顶掉了。查了数据，ID没有重复。

折腾了大半天，才想到去检查“对象被放入TreeSet之后，是不是被外部改过字段”。一查，果然。所以真正的问题不是集合选错了，而是我在用可变对象的时候，完全没有意识到TreeSet的排序依赖的是对象在“放入那一刻”的比较结果。

2. 底层机制：TreeSet和TreeMap是怎么判定“重复”和“覆盖”的

要彻底搞懂这个坑，得先把TreeSet和TreeMap的底层机制掰开揉碎。这两个容器不像ArrayList那样“按顺序存”，也不像HashMap那样“按哈希散列”。它们的核心是一棵红黑树，每个节点的位置，都是通过比较器逐层比较算出来的。

2.1 红黑树的位置由比较器决定

TreeMap内部维护一棵红黑树，TreeSet内部其实就是一个TreeMap，只是把元素作为TreeMap的key存进去，value统一是一个固定对象。红黑树是一种自平衡二叉搜索树，插入节点时会从根节点开始，用key的比较器（Comparator或Comparable）决定往左走还是往右走。

你可以把它理解成一个按身高排队的队伍。新来一个人，从队头开始比，比他矮的往左，比他高的往右，一直走到底，找到自己的位置。队伍里每个人站在哪里，是由“当时的比较结果”决定的，而且这个位置会被固化下来。

所以当元素被插入TreeSet/TreeMap之后，这个元素在集合里的“位置”就已经定死了。如果之后这个对象的内容变了，导致它和别人之间的比较结果也变了，队伍里的位置并不会自动跟着变——它就那么错位地站在那里。

2.2 比较器返回0的两种含义

这是理解“内容被覆盖”最关键的一点。在红黑树插入过程中，如果比较器返回0，意味着“树里已经有一个和你相等的节点”。对于TreeSet，add方法会直接返回false，新元素不会被加入；对于TreeMap，put方法会用新value覆盖旧value，并返回旧value。

很多人只记得TreeMap的value覆盖，却忘了TreeSet同样有“覆盖”逻辑——新元素被判定重复后直接被丢弃。如果一个业务上完全不同的对象，因为比较器写得太宽松而被判成重复，那这个对象的信息就相当于被“覆盖”掉了。

比如你只按分数比较，两个玩家都得了100分，TreeSet会认为它们是同一个元素，后面的那个玩家的完整信息直接不存。TreeMap则会把value覆盖成后put的那个。这属于“比较器设计不当导致的覆盖”，和改字段是两条完全不同的路径。

2.3 “错位”是怎么发生的

再回到改字段的场景。你将对象放入TreeSet后修改了它的排序字段，树的物理结构没有变，但对象的内容已经变了。此时从根节点开始搜索某个元素时，每次比较的结果都基于新值，但树的分支结构却基于旧值。两者一旦对不上，搜索路径就会偏离实际节点位置。

结果就是：明明存在的元素查不到，明明不存在的元素可能被误判，size比预期小，first()和last()取错对象，删除操作指向错误的节点，极端情况下还可能破坏红黑树的平衡修正逻辑。

我自己平时喜欢用一个比喻：红黑树是一本电话簿，每个人按姓名拼音排列。查一个人的时候，你按照“新的读音”去找他，但电话簿里的位置是按照“老的读音”登记的。读音变了，你还按老位置找，当然找不到。

3. 四个根因：从代码到现象逐个拆解

排查过后，我把市面上常见的“TreeSet/TreeMap内容被覆盖”问题归纳成了四类。每一类我都写了对应的复现代码，也完整分析了背后的逻辑。你可以对照自己的代码看看属于哪一种。

3.1 根因一：可变对象改动了排序字段

这是最隐蔽、也最常见的一类。对象放进集合后，外部通过setter修改了compareTo依赖的字段。比如上面的Score排行榜。

Player playerA = new Player("A001", 100); rankSet.add(playerA); // 错误操作：直接修改对象分数 playerA.setScore(180); rankSet.add(playerA);

现象是：集合的size不会增加（因为playerA已经在树里），但树里那个节点的比较逻辑已经失效。后续任何依赖比较器的操作都会出现异常。前面我已经展示过具体输出了，这里不再重复。强调一句：size没变不代表没出问题，恰恰是因为size没变，很多人才忽略了严重性。

3.2 根因二：比较器把不同对象判成同一个

这种覆盖和对象可变性无关，纯粹是compareTo/compare写得不严谨。比如只按分数比较：

Comparator<Player> byScoreOnly = Comparator.comparingInt(Player::getScore); TreeSet<Player> set = new TreeSet<>(byScoreOnly); set.add(new Player("A001", 100)); set.add(new Player("B002", 100)); System.out.println(set.size()); // 1，B002直接被丢弃

对于TreeMap，表现方式更直白——value被覆盖：

TreeMap<Player, Integer> map = new TreeMap<>(byScoreOnly); map.put(new Player("A001", 100), 1); map.put(new Player("B002", 100), 2); System.out.println(map.size()); // 1 System.out.println(map.values()); // [2]，原来的value 1被覆盖

注意，这两个Player的playerId完全不同，业务上是两个人。但TreeMap不认equals，它只认比较器。只要比较器判定为0，就被当成同一个key。这种问题在排行榜、优惠券、库存这类场景特别致命，因为同分的元素极其常见。

3.3 根因三：compareTo和equals不一致

Java文档里明确要求：如果一个类实现了Comparable，那compareTo和equals应该保持一致的判定结果。但实际项目里很少有人真的遵守这条规范。

举个例子：

public class Item { private String sku; // 商品编码 private int price; // 价格 @Override public boolean equals(Object o) { // 按商品编码判断相同 return this.sku.equals(((Item) o).sku); } @Override public int compareTo(Item o) { // 但排序只按价格 return Integer.compare(this.price, o.price); } }

同一个商品，价格修改后，你在TreeSet里用contains判断它是否存在，走的是compareTo逻辑；在普通List里用contains判断，走的是equals逻辑。两套结果可能完全相反。更麻烦的是，TreeSet的remove操作依赖compareTo，如果一个对象的equals相同但compareTo不同，你remove的时候可能删不掉，或者删掉了别的对象。

3.4 根因四：多个集合共享同一个可变引用

还有一种情况容易被忽略：同一个对象实例同时被多个集合持有，任何一边修改都会影响其他集合。

Player shared = new Player("A001", 100); TreeSet<Player> setA = new TreeSet<>(); TreeSet<Player> setB = new TreeSet<>(); setA.add(shared); setB.add(shared); // 某个业务逻辑通过setA拿到的对象改了一下 Player p = setA.first(); p.setScore(500); // setB也“同步变化”了，因为底层是同一个对象

如果setB是另一个排行榜，或者另外一个模块的数据索引，那这个共享对象被修改后，所有集合全部错乱。这种问题往往是多个服务之间传递对象引用导致的内存共享，跟并发无关，但比并发更难查。

4. 正确修改方案：让TreeSet和TreeMap不再“丢数据”

搞清楚根因之后，解决方案其实已经很清晰了。核心思路就一句话：不要让集合里已有的对象“自己改变在比较器眼中的身份”。

4.1 首选方案：让排序字段不可变

最好的做法，是把参与compareTo/compare的字段设计成不可变。Java里可以用final字段实现：

public final class Player implements Comparable<Player> { private final String playerId; private final int score; public Player(String playerId, int score) { this.playerId = playerId; this.score = score; } public String getPlayerId() { return playerId; } public int getScore() { return score; } @Override public int compareTo(Player other) { int scoreCompare = Integer.compare(other.score, this.score); if (scoreCompare != 0) { return scoreCompare; } return this.playerId.compareTo(other.playerId); } }

去掉setter之后，分数只能在构造Player时确定。要更新分数就得new一个新对象。这个设计从根上杜绝了“修改字段导致树结构错位”的可能。代价是更新时需要多做一次对象创建，但对绝大多数业务来说，这点开销完全可以忽略。

4.2 更新分数的正确姿势

如果因为历史原因，对象确实做成可变了，那更新排序相关字段时，必须严格按这个顺序操作：先移除，再修改，再加回。

// 正确操作 rankSet.remove(playerA); playerA.setScore(180); rankSet.add(playerA);

顺序不能反，这是血泪教训。如果先改字段再remove，remove在查树的时候会拿“新值”走搜索路径，大概率找不到旧位置上的节点，remove直接返回false。等于没删掉，然后add又因为对象已经在树里而拒绝插入。最终集合里保留的还是旧结构、旧内容，问题不但没解决，反而更难排查。

如果你用的不是原对象引用，而是想根据ID找到树里的对象再改，可以这样：

Player target = rankSet.ceiling(new Player("A001", Integer.MIN_VALUE)); rankSet.remove(target); target.setScore(180); rankSet.add(target);

这里通过构造一个“比较器意义上相等”的查询对象，先定位到树中的真实节点，再执行移除操作。

4.3 比较器的兜底设计

在编写compareTo/compare时，除了核心排序字段，建议加一个唯一标识作为兜底。这个唯一标识可以是数据库主键、UUID、自增ID等，确保任何两个业务上不同的对象，比较结果永远不为0。

@Override public int compareTo(Player other) { int scoreCompare = Integer.compare(other.score, this.score); if (scoreCompare != 0) { return scoreCompare; } return this.playerId.compareTo(other.playerId); }

这样排行榜还是按分数排序，分数相同的玩家按ID排位，而且不会互相覆盖。同理，TreeMap的key也不会因为比较器过于宽松而被错误替换。

这里还要注意另一件事：compareTo返回0，equals必须返回true。如果做不到，也要保证逻辑上“比较器认为是同一个对象的对象，确实就是同一个对象”。否则后续的contains、remove、put这些操作都会出现前后矛盾。

4.4 需要频繁更新时，换一种结构

如果你的业务场景就是高频更新排序值，比如实时排行榜每秒都有分数变化，那其实不太适合用TreeSet/TreeMap硬扛。因为无论如何设计，只要频繁改动排序字段，就免不了频繁remove再add，性能和维护成本都很高。

我建议的替代方案是“双索引”：用一个TreeMap按不可变ID存对象，再用一个TreeSet按分数排序，更新时两个容器同步操作：

TreeMap<String, Player> byId = new TreeMap<>(); TreeSet<Player> byScore = new TreeSet<>(); // 更新分数 Player old = byId.remove(playerId); byScore.remove(old); Player updated = new Player(playerId, newScore); byId.put(playerId, updated); byScore.add(updated);

byId的key是String，天然不可变，不会出现任何树结构错位问题；byScore只负责排序，每次更新走一遍“移除再插入”流程，逻辑清晰。

如果对并发要求也高，可以考虑ConcurrentSkipListMap/ConcurrentSkipListSet，但要注意：跳表和红黑树一样，同样不能容忍可变key。换数据结构只解决并发和安全问题，解决不了“对象身份变化”的问题。

下面用一个表格汇总一下不同场景下的推荐做法：

5. 排查清单与踩坑经验

这个问题排查起来不难，但如果没经验，真的会绕远路。我把这次经历整理成了一套速查方法和几条实操规矩，希望对你有用。

5.1 问题定位速查表

遇到以下现象，直接对照排查方向：

5.2 三条必须守住的规矩

这条是我踩了坑之后给自己定的规矩，写代码的时候强制遵守：

第一，进TreeSet/TreeMap的对象，默认按不可变来设计。真要更新排序字段，new一个新对象，不要指望集合“智能重排”。

第二，任何更新排序字段的操作，必须走“移除-修改-插入”完整流程，而且顺序绝不能错。先remove再set再add，少一步都会出问题。

第三，写单元测试时，一定要专门覆盖三类用例：修改后重新add、同分不同对象的去重、remove一个之前已经add且后续被修改过的对象。这三个用例能防住大部分比较器相关的坑。

我再补充一个现场排查看法：如果你在代码里看到有人对TreeSet里的对象直接调用setter，不管他后面有没有跟着一个add，先停下来好好想一想。因为add并不会触发重排，它只会安静地返回false，让你误以为已经更新成功了。这种“安静”才是最可怕的。

另外，调试时可以用一个小技巧：在对象被修改前后分别打印一下TreeSet的toString或者做一次完整遍历，对比一下顺序变化。如果顺序没有按你的预期更新，那基本就是可变key问题，不需要再往并发、缓存、序列化这些方向瞎猜了。

最后再分享一个扩展思路：如果你维护的是类似排行榜这种需要实时刷新的数据，除了考虑Java集合本身，也可以考虑把排序逻辑放到数据库或者专门的排序服务里，应用层只做缓存。这样即便多个节点并发更新，也有一个统一的权威顺序来源。当然这是架构层面的取舍了，这里不展开。

总之我不是劝你放弃TreeSet和TreeMap，而是想提醒你：这两个容器很强大，但它们对被存放的对象有一种隐形要求——身份必须稳定。理解这个前提，很多莫名其妙的“内容被覆盖”问题，其实都不会发生。