Java内存中幻读是多线程并发读写共享数据时，因缺乏可见性与排他性控制，导致同一条件两次查询结果集行数不一致；需满足逻辑查询条件、多次读取、其他线程增删符合该条件的数据三个条件。
Java 多线程环境下的“幻读”问题，本质是多个线程对同一组共享数据（如集合、缓存、内存中模拟的查询结果集）并发读写时，因缺乏统一的可见性与排他性控制，导致某线程两次读取相同条件的数据，结果集行数不一致（比如第一次查到 3 条，第二次查到 4 条）。这和数据库中的幻读现象逻辑相似，但发生场景在 JVM 内存中 —— 不涉及 SQL 或事务隔离级别，而是由代码逻辑和同步机制缺失引发。
明确幻读发生的典型场景
不是所有读写都会引发幻读。它需要同时满足三个条件：
- 存在一个“逻辑查询条件”，例如 “余额大于 100 的账户列表”
- 有线程基于该条件做多次读取（比如校验+后续处理）
- 其他线程在此期间插入或删除了符合该条件的新对象，且未被读线程感知
例如：线程 A 查询余额 >100 的账户共 5 个，准备批量扣费；线程 B 此时新增一个余额为 150 的账户并加入集合；线程 A 第二次遍历时发现变成 6 个——这就是内存级幻读。
用读写锁（ReadWriteLock）保护查询逻辑
ReentrantReadWriteLock 是解决这类问题最直接的锁策略。它的核心价值在于：允许多个线程并发读，但只要有一个线程写，所有读和写都必须等待。这样能确保“条件查询 + 后续操作”这一逻辑块的原子性视图。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 所有读操作（如
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”）的原子性
不复杂但容易忽略：幻读不是锁得不够多，而是锁得不对——要锁住“条件语义”，而不是单个对象。选读写锁或统一临界区锁，配合数据访问契约，就能稳住多线程下的查询一致性。
