Java内存中幻读是多线程并发读写共享数据时，因缺乏可见性与排他性控制，导致同一条件两次查询结果集行数不一致；需满足逻辑查询条件、多次读取、其他线程增删符合该条件的数据三个条件。

Java 多线程环境下的“幻读”问题，本质是多个线程对同一组共享数据（如集合、缓存、内存中模拟的查询结果集）并发读写时，因缺乏统一的可见性与排他性控制，导致某线程两次读取相同条件的数据，结果集行数不一致（比如第一次查到 3 条，第二次查到 4 条）。这和数据库中的幻读现象逻辑相似，但发生场景在 JVM 内存中 —— 不涉及 SQL 或事务隔离级别，而是由代码逻辑和同步机制缺失引发。

明确幻读发生的典型场景

不是所有读写都会引发幻读。它需要同时满足三个条件：

• 存在一个“逻辑查询条件”，例如 “余额大于 100 的账户列表”
• 有线程基于该条件做多次读取（比如校验+后续处理）
• 其他线程在此期间插入或删除了符合该条件的新对象，且未被读线程感知

例如：线程 A 查询余额 >100 的账户共 5 个，准备批量扣费；线程 B 此时新增一个余额为 150 的账户并加入集合；线程 A 第二次遍历时发现变成 6 个——这就是内存级幻读。

用读写锁（ReadWriteLock）保护查询逻辑

ReentrantReadWriteLock 是解决这类问题最直接的锁策略。它的核心价值在于：允许多个线程并发读，但只要有一个线程写，所有读和写都必须等待。这样能确保“条件查询 + 后续操作”这一逻辑块的原子性视图。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 所有读操作（如 findAccountsByBalance(100)）使用 readLock().lock()
• 所有写操作（如 addAccount(new Account(150))）必须用 writeLock().lock()
• 关键点：读操作之间不互斥，但读与写、写与写之间严格互斥
• 避免只对单个对象加锁（如 synchronized(account)），那无法控制“符合条件的集合范围”

用 synchronized 块锁定整个查询-操作临界区

如果业务逻辑简单、并发量不高，用对象级 synchronized 也能奏效，前提是锁对象唯一且覆盖全部相关操作。

• 定义一个专用锁对象：private final Object queryLock = new Object();
• 所有涉及“按条件查询 + 使用结果”的代码，都包裹在 synchronized(queryLock) 中
• 同样，所有增删改操作也必须进入同一把锁，否则写操作会绕过保护
• 注意：不能用 this 或易变对象作锁，否则不同实例或状态变化会导致锁失效

避免幻读不只是加锁，还要统一数据结构视角

锁只是手段，根本在于让所有线程看到同一份“快照”或受控视图。

• 读操作尽量基于不可变副本（如返回 new ArrayList(accounts)），防止外部修改影响内部逻辑
• 写操作完成后，可考虑触发通知（如 notifyAll()）或更新版本号，让等待读线程感知变化
• 慎用延迟加载或懒查询：如果查询过程本身依赖外部状态（如远程调用），锁无法覆盖该延迟段，幻读风险仍在
• 若底层是 ConcurrentHashMap 等并发容器，注意它只保证单个操作线程安全，不保证复合操作（如“先查再 put”）的原子性

不复杂但容易忽略：幻读不是锁得不够多，而是锁得不对——要锁住“条件语义”，而不是单个对象。选读写锁或统一临界区锁，配合数据访问契约，就能稳住多线程下的查询一致性。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南