哪些Java案例适合做并发控制？

wen java案例 2026-06-17 3

哪些Java案例适合做并发控制？从实战场景到最佳实践

目录导读

为什么Java开发者必须掌握并发控制？
电商库存扣减 – synchronized与乐观锁的取舍
高并发日志收集 – 阻塞队列与线程池的协作
分布式ID生成 – Atomic类的正确用法
多线程数据聚合 – ReentrantLock与Condition的进阶应用
缓存热点更新 – ReadWriteLock与StampedLock的选择
常见问题问答

为什么Java开发者必须掌握并发控制？

在多核处理器和云原生架构普及的今天，Java应用几乎无法避免并发场景，从简单的Web请求处理到复杂的异步任务调度，线程安全是保证数据一致性和系统稳定性的基石。

哪些Java案例适合做并发控制？

许多开发者对volatile、synchronized、Lock、Atomic等工具的理解停留在理论层面，要真正掌握并发控制，最好的方式是通过真实案例理解它们的适用场景，本文精选5个高频Java并发案例，从企业级实战出发,帮你构建清晰的选型思路。

电商库存扣减 – synchronized与乐观锁的取舍

场景描述

一个热门商品库存剩余10件，1000个用户同时下单，如果直接使用int stock，在if (stock > 0) { stock--; }这段代码中会发生超卖。

错误示例

public void reduceStock() {
    if (stock > 0) {
        stock--; // 非原子操作
    }
}

在高并发下，多个线程同时读到stock=1，都执行减一,导致库存变为负数。

正确方案对比

方案	适用性	性能
synchronized 方法/块	单机、低并发	中等
ReentrantLock	需超时、可中断	中等
数据库乐观锁（版本号）	分布式、中小并发	高
Redis分布式锁	分布式、高并发	极高

核心选型原则：单机小并发用synchronized，分布式大并发用乐观锁或Redis原子递减。

问答 Q：为什么不用volatile控制库存？
A：volatile仅保证可见性，不保证stock--的原子性,无法解决超卖。

高并发日志收集 – 阻塞队列与线程池的协作

场景描述

业务系统每秒产生5000条日志，需要异步写入文件，如果每来一条日志就创建一个线程写入,会导致系统崩溃。

解决方案：生产者-消费者模式

// 使用BlockingQueue作为缓冲
BlockingQueue<LogRecord> queue = new LinkedBlockingQueue<>(10000);
// 单消费者线程
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.submit(() -> {
    while (true) {
        LogRecord log = queue.take(); // 阻塞等待
        writeToFile(log);
    }
});

关键点：

LinkedBlockingQueue无界易内存溢出，必须设置固定容量。
使用offer方法带超时，避免生产者无限等待。
线程池使用有界队列+拒绝策略（如CallerRunsPolicy）。

问答 Q：为什么不用synchronized做队列同步？
A：BlockingQueue内部已经用ReentrantLock和Condition实现了高效的等待-通知机制，比手动synchronized+wait/notify更安全、更简洁。

分布式ID生成 – Atomic类的正确用法

场景描述

一个订单系统需要生成全局唯一ID，要求：趋势递增、高吞吐、跨节点不重复。

建议方案：雪花算法 + `AtomicLong`

public class SnowflakeIdWorker {
    private long lastTimestamp = -1L;
    private final AtomicLong sequence = new AtomicLong(0);
    public synchronized long nextId() {
        // 时间戳 + 机器ID + 序列号
        return ...;
    }
}

虽然使用了AtomicLong，但关键同步逻辑仍需要synchronized包裹整个方法，因为AtomicLong仅保证单个变量的原子性，无法保证多字段组合的复合操作（如时间戳判断+序列号重置）的原子性。

正确认知：Atomic类是轻量级无锁工具，适合计数器、累加器等场景；复杂状态机仍需配合锁使用。

问答 Q：能否用ThreadLocal实现ID生成？
A：可以，但会导致同一JVM内生成ID不唯一。ThreadLocal适合线程隔离的场景,如请求追踪ID。

多线程数据聚合 – ReentrantLock与Condition的进阶应用

场景描述

一个报表引擎需要同时从3个接口拉取数据，待所有数据就绪后再合并结果，避免空指针。

最佳实践：`CountDownLatch`

CountDownLatch latch = new CountDownLatch(3);
ExecutorService executor = Executors.newFixedThreadPool(3);
executor.submit(() -> {
    data1 = fetchA();
    latch.countDown();
});
// ... 类似方式处理B、C
latch.await(5, TimeUnit.SECONDS); // 等待最多5秒
merge(data1, data2, data3);

更复杂的场景：当需要可中断、可超时、可条件等待时，选择ReentrantLock+Condition，如实现一个限流器。

问答 Q：CountDownLatch和CyclicBarrier有什么区别？
A：CountDownLatch一次性使用，主线程等待子任务完成；CyclicBarrier可循环使用,所有线程相互等待后同时执行下一步。

缓存热点更新 – ReadWriteLock与StampedLock的选择

场景描述

一个配置中心每分钟更新一次配置，但每秒被读取上万次，如果使用synchronized，读操作会被写操作阻塞,严重降低性能。

解决方案：`ReadWriteLock`

private final ReadWriteLock rw = new ReentrantReadWriteLock();
private Map<String, Object> cache;
public Object get(String key) {
    rw.readLock().lock();
    try {
        return cache.get(key);
    } finally {
        rw.readLock().unlock();
    }
}
public void update(Map<String, Object> newCache) {
    rw.writeLock().lock();
    try {
        cache = newCache;
    } finally {
        rw.writeLock().unlock();
    }
}

优化升级：如果读远多于写，可使用Java 8的StampedLock，提供乐观读（tryOptimisticRead），无锁情况下直接读取,失败后降级为悲观读。