违反自反性最直接的代码现象是x.equals(x)返回false，导致list.contains、set.remove、map.containskey等集合操作失效，根本原因是equals契约崩塌使集合底层将对象自身误判为不同对象。
违反自反性最直接的代码现象是：对象自己和自己比较返回 false，也就是 x.equals(x) 得到 false。这看似微小，却会立刻破坏集合类的核心行为。
集合操作当场失效
几乎所有基于 equals 的集合方法都依赖自反性。例如：
-
list.contains(x)返回false，哪怕x就在 list 里； -
set.remove(x)返回false，实际没删掉任何元素； -
map.containsKey(key)返回false，即使该 key 明明已存入。
典型错误写法触发的现象
比如在 equals 中对参数做了预处理，却忘了对当前对象做同样操作：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
if (!this.name.trim().equals(other.name.trim())) return false;
当 this.name 是 "Alice "（带尾空格），other 就是 this 时，other.name.trim() 变成 "Alice"，但 this.name.trim() 也应参与比较——可这里实际执行的是 "Alice ".trim().equals("Alice ".trim())，看起来没问题？等等，问题出在：如果代码写成 !this.name.toLowerCase().equals(other.name.toLowerCase())，而 this.name 是 null，就会抛 NullPointerException；更隐蔽的是，若只对 other.name 调用 trim()，却没对 this.name 也 trim，就直接导致 x.equals(x) == false。
调试时容易被忽略的表现
你可能看到这样的日志或断点结果：
- 刚把对象
p加进HashSet，紧接着调set.contains(p)却返回false； - 用
ArrayList.indexOf(p)查找自己，结果是-1； - 单元测试里
assertTrue(p.equals(p))直接失败。
根本原因不是逻辑错，而是契约崩塌
Java 集合不验证你的业务逻辑，只信任 equals 的数学性质。一旦自反性不成立，集合底层（比如 HashMap.getNode() 或 AbstractList.indexOf()）在遍历、比对、定位时，会把“自己”当成“别人”，从而跳过匹配、拒绝识别、重复插入——所有异常都源于这个基础假设的瓦解。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
