Java 中 AtomicInteger 计数失效问题的根源与正确实践-java教程-PHP中文网

Java 中 AtomicInteger 计数失效问题的根源与正确实践

本文深入剖析多线程环境下 atomicinteger 计数异常（如卡在 1、7 等非零值）的根本原因，指出未在 finally 块中执行原子减量是核心缺陷，并给出线程安全、可落地的修复方案。

本文深入剖析多线程环境下 atomicinteger 计数异常（如卡在 1、7 等非零值）的根本原因，指出未在 finally 块中执行原子减量是核心缺陷，并给出线程安全、可落地的修复方案。

在使用 AtomicInteger 实现任务计数协调时，一个常见但极易被忽视的陷阱是：原子操作本身是线程安全的，但其执行时机和上下文却未必可靠。你当前代码中 decreaseUrlInActionAndVerifyStatus() 仅在 run() 方法末尾调用，一旦工作线程在处理过程中抛出未捕获的异常（如 NullPointerException、网络超时异常、解析异常等），该方法将被跳过，导致 AtomicInteger 永远无法递减到 0，DONE 状态也就永远无法触发——这正是你观察到“计数随机卡住”的根本原因。

✅ 正确做法：强制在 finally 中完成原子减量

必须将 decreaseUrlInActionAndVerifyStatus() 移入 try-finally 结构的 finally 块中，确保无论正常结束还是异常中断，计数器都能被准确释放：

@Override
public void run() {
    log.info("thread doing scrapper for url {} keyword {}", url, entity.getKeyword());
    try {
        // ✅ 主业务逻辑：抓取、解析、条件分发等
        doScrapingLogic(); // 你的实际处理逻辑

        // ✅ 条件性递归调度（注意：此处仍需保证线程安全）
        if (shouldContinueProcessing()) {
            doScrapper.sendToProccess(
                entity, nextUrl, rootUrl,
                urlVisited, requestService,
                doScrapper, database
            );
        }

    } catch (Exception e) {
        log.error("unexpected error in ScrapperWorker for URL: {}", url, e);
        // 可选：记录错误、告警或重试策略，但绝不吞没异常
    } finally {
        // ⚠️ 关键修复：无论成功/失败，都必须执行状态检查
        decreaseUrlInActionAndVerifyStatus();
    }
}

? 其他潜在风险与加固建议

Vector<string></string> 并非完全线程安全的“万能解”
虽然 Vector 方法是同步的，但 isNotVisitedUrl(url, vector) 中的 vector.contains(url) 是原子操作，而 urlVisited.add(urlToProccess) 在 DoScrapper.sendToProccess() 中被调用——多个 Worker 实例共享同一 Vector 实例，且 add() 和 contains() 之间存在竞态窗口（即 A 判断未访问 → B 同时添加 → A 再次添加）。推荐升级为 ConcurrentHashMap<string boolean></string> 或 CopyOnWriteArrayList<string></string>，并统一用 putIfAbsent() / addIfAbsent() 语义：
```
// 替代 Vector<string> urlVisited
private final ConcurrentHashMap<string boolean> visitedUrls = new ConcurrentHashMap();

private boolean isNotVisitedUrl(String url) {
    return url != null && visitedUrls.putIfAbsent(url, true) == null;
}</string></string>
```
ScrapperEntity 的状态变更需内存可见性保障
entity.setStatus(StatusScrapper.DONE) 应配合 volatile 字段或 AtomicReference<statusscrapper></statusscrapper>，避免因 CPU 缓存不一致导致其他线程读取到旧状态。若 setStatus() 是普通 setter，建议改为：
```
private final AtomicReference<statusscrapper> status = new AtomicReference(StatusScrapper.PENDING);
public void setStatus(StatusScrapper s) { status.set(s); }
public StatusScrapper getStatus() { return status.get(); }</statusscrapper>
```
避免共享可变状态传递
Vector<string> urlVisited</string> 被多个 Worker 共享且直接修改，易引发一致性问题。更健壮的设计是：每个 Worker 持有独立的 visitedUrls 快照（如 new ConcurrentHashMap(parentVisited)），并在完成时合并回全局视图，或由 DoScrapper 统一管理访问状态。

JavaStoryDevelop
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载