用System.identityHashCode()校验单例唯一性最可靠，因其绕过重写、反映对象原始地址哈希；需在构造器、getInstance()、注入点打日志比对ID，排查多实例问题，并注意类加载器、反序列化等干扰项。
直接用 System.identityHashCode() 打印单例对象的“内存身份指纹”，是最轻量、最可靠的方式之一——它不依赖 equals() 或 hashCode() 重写，只反映 JVM 中对象的原始地址哈希（近似唯一），适合排查“本该唯一却悄悄冒出多个”的问题。
为什么不用普通 hashCode()？
普通 hashCode() 可能被重写，返回值可能重复或人为统一（比如所有单例都返回 1）；而 identityHashCode() 绕过重写，每个对象实例（哪怕内容完全一样）只要不是同一个引用，就大概率返回不同整数。这对单例校验至关重要。
在关键位置埋点打日志
在单例的获取入口（如 getInstance()）、构造器、以及每次被注入/赋值给成员变量的地方，记录 identity hash：
- 构造器里加：
log.info("Singleton created, id={}", System.identityHashCode(this)); -
getInstance()返回前加：log.debug("Returning singleton instance, id={}", System.identityHashCode(instance)); - 若通过 Spring 等容器注入，可在
@PostConstruct或 setter 中记录：log.trace("Injected singleton ref, id={}", System.identityHashCode(this.singletonField));
对比日志中出现的 id 是否一致
启动后观察日志流，重点关注：
- 构造器日志是否只出现一次？如果多次，说明被 new 了多次
- 所有
getInstance()返回的 id 是否全相同？如有不同，说明缓存失效或双重检查锁写错 - 各组件持有的引用 id 是否和源头一致？如有偏差，可能是误用了 new、反射、反序列化或容器配置成 prototype
例如：日志中看到 id=123456789 出现在构造器和 A 类注入处，但 B 类里却是 id=987654321——那 B 类拿到的根本不是同一个实例。
注意边界情况与干扰项
identityHashCode() 不是绝对地址，但冲突概率极低（尤其在单次运行中）。需排除以下假阳性：
- 测试时反复 reload 应用（如 Spring Boot DevTools），类加载器不同会导致新实例 —— 看日志时间戳是否跨重启
- 使用了反序列化（如 Redis 存取）且没实现
readResolve()，会绕过 getInstance 创建新对象 - 多模块中存在同名类、不同 jar 版本，导致“看似单例，实为两个类的各自单例”——此时连 classloader 都不同，identityHashCode 必然不同
遇到可疑差异，可补打 this.getClass().getClassLoader() 和 this.getClass().getCanonicalName() 辅助判断。
进阶：自动断言 + 启动保护
在单例类初始化完成后，主动校验当前实例是否仍为唯一活跃引用：
- 用
WeakReference缓存首次实例，在后续调用中比对identityHashCode() - 在
static {}块中记录首次 id，之后每次getInstance()都 assert 相等（测试环境启用） - Spring 用户可在
@EventListener(ContextRefreshedEvent.class)中遍历所有单例 bean，对目标类调用applicationContext.getBean(MySingleton.class)并比对 identityHashCode
一旦发现不一致，立即抛异常或发告警，避免带病运行。
