Java 多线程中安全移除自身元素的陷阱与解决方案-java教程-PHP中文网

Java 多线程中安全移除自身元素的陷阱与解决方案

本文深入剖析多线程环境下线程尝试从共享 ArrayList 中移除自身导致死锁或数据不一致的根本原因，指出并发修改未加锁是核心问题，并提供基于显式锁保护的正确实践。

本文深入剖析多线程环境下线程尝试从共享 `arraylist` 中移除自身导致死锁或数据不一致的根本原因，指出并发修改未加锁是核心问题，并提供基于显式锁保护的正确实践。

在 Java 并发编程中，一个看似直观的操作——“当前线程从某个共享列表中移除自己”——往往隐藏着严重的线程安全陷阱。您提供的代码中，Passenger.disembark() 方法调用 boatKeeper.getBoat().removePassenger(this) 试图将当前 Passenger 实例从 boat.passengersOnBoard（一个非线程安全的 ArrayList）中移除，但该操作未受任何同步保护，正是引发“幽灵乘客”（ghost passenger）、null 元素残留及 BoatKeeper 无限等待的根本原因。

? 问题根源：非线程安全集合的竞态条件

ArrayList 是典型的非线程安全集合。其 remove(Object o) 方法内部依赖于 indexOf() 和 remove(int index)，二者均非原子操作，且在遍历过程中直接修改底层数组结构。当多个线程（如多个 Passenger）并发调用 removePassenger()，或一个线程在 remove() 执行中途被另一个线程（如 BoatKeeper 的 isBoardingComplete() 或 hasFerryingToDo() 中的 boat.hasPassengers()）读取 passengersOnBoard 状态时，极易发生以下情况：

迭代器失效：若某线程正在遍历列表（如 BoatKeeper 检查 hasPassengers()），另一线程同时 remove()，可能导致 ConcurrentModificationException（虽未显式抛出，但内部状态已不一致）；
元素覆盖/跳过：ArrayList 的 remove() 会将后续元素前移。若两个线程几乎同时移除不同元素，可能因索引错位导致一个元素未被真正清除，或被错误地覆盖为 null；
可见性问题：即使移除成功，由于缺乏内存屏障（如 synchronized 或 Lock 的 happens-before 关系），BoatKeeper 线程可能永远看不到 passengersOnBoard 的最新大小，从而卡在 while (boat.hasPassengers()) { condition.await(); } 循环中。

您观察到“调试时正常、运行时冻结”的现象，正是因为调试器引入的额外延迟和线程调度变化，偶然掩盖了竞态窗口——这恰恰是典型并发 Bug 的特征。

✅ 正确解法：用统一锁保护所有共享状态访问

修复的关键在于：对 passengersOnBoard 的所有读写操作（包括 addPassenger、removePassenger、hasPassengers、isFull）必须由同一把可重入锁（ReentrantLock）保护，确保互斥与内存可见性。

原 disembark() 方法的问题代码：

sc-java-to-ts-interface

将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。

下载

// ❌ 危险：removePassenger() 在锁外执行，无同步保障
boatKeeper.getBoat().removePassenger(this);
lock.lock();
condition.signalAll();
lock.unlock();

修正后（需同步整个操作链）：

// ✅ 正确：在锁内完成移除 + 通知，保证原子性与可见性
lock.lock();
try {
    boatKeeper.getBoat().removePassenger(this);
    condition.signalAll(); // 通知 BoatKeeper 等待线程检查状态
} finally {
    lock.unlock();
}

同时，必须同步 Boat 类中所有访问 passengersOnBoard 的方法。例如，hasPassengers() 和 isFull() 应改为：

boolean hasPassengers() {
    lock.lock();
    try {
        return !passengersOnBoard.isEmpty();
    } finally {
        lock.unlock();
    }
}

boolean isFull() {
    lock.lock();
    try {
        return passengersOnBoard.size() == capacity;
    } finally {
        lock.unlock();
    }
}

⚠️ 注意：Boat 类当前未持有 lock 字段。您需要将其注入（如通过构造函数传入 SharedSynchronizers.FAIR_LOCK），或让 Boat 直接使用 SharedSynchronizers.FAIR_LOCK（推荐，保持锁统一）。

?️ 进阶建议：更健壮的设计模式

避免“线程自删”反模式：理想情况下，应由协调者（如 BoatKeeper）统一管理乘客生命周期。Passenger 可通过回调或事件通知 BoatKeeper “我已下船”，由后者在锁内执行移除。
考虑线程安全集合：若场景允许，可用 CopyOnWriteArrayList 替代 ArrayList（适用于读多写少）。但注意其高内存开销与弱一致性（remove() 后其他线程可能短暂看到旧快照）。
使用 synchronized 替代显式锁：若锁粒度合适，synchronized(SharedSynchronizers.FAIR_LOCK) 更简洁，但 ReentrantLock 提供了 Condition 等高级功能，当前设计中已合理利用。

✅ 总结

问题现象	根本原因	解决方案
“幽灵乘客”、`null` 元素、无限等待	`ArrayList` 并发修改未同步	所有 `passengersOnBoard` 访问必须由同一把 `Lock` 保护
调试时行为不一致	竞态条件受调度时机影响	消除竞态，而非依赖调试器延迟