故小里做后端十年，真正给我上课的不是架构设计，不是性能调优，而是一堆不起眼的并发bug。最惨的时候，团队线上每月能稳定冒出12个并发相关缺陷，库存超卖、订单重复、数据对不上……每次排查都像刑侦破案，日志打了一堆也还原不出案发现场。后来我花了半年时间，把自己踩过的坑系统性收拢成6条可落地的硬招，硬生生把这个数字压到了0，并且连续18个月没有再反弹。
这篇东西不是面试八股，也不是源码解析，就是我这10年跟Java并发bug死磕下来的实战打法。它不挑框架，不挑业务，适合所有用Java写后端、不想在凌晨三点被线上告警喊起来的人。我会把每一招背后的原理、常见误用方式、以及实际落地时的取舍讲透，你可以直接照着抄。
1. 曾经的“月均12个bug”究竟把我们坑在哪：一次典型事故还原
1.1 一次线上库存超卖事故的完整回溯
那是一个电商中台项目，库存扣减逻辑写得很直白：
java复制public class InventoryService {
private Map<String, Integer> stockMap = new HashMap<>();
public boolean deduct(String skuId, int count) {
Integer stock = stockMap.get(skuId);
if (stock != null && stock >= count) {
stock -= count;
stockMap.put(skuId, stock);
return true;
}
return false;
}
}
单看代码几乎找不到毛病，甚至本地单测都能稳定通过。但压测环境流量一上来，库存就被扣成了负数。问题出在HashMap的get和put不是原子操作：线程A和线程B同时读到库存还剩10件，各自扣掉2件后都写回8件，实际卖出去4件但库存只减了2件。
这个案例其实暴露了并发bug最典型的三个特征：多线程共享可变状态、关键操作不是原子、错误结果可能被后续计算覆盖。最坑的是，这类bug在低并发下完全隐身，测试环境很难复现，一旦流量峰值到了，瞬间炸穿。
1.2 为什么并发bug总是查不到根因
我后来把团队遇到过的并发问题做了个归类，发现它们都有共通点：
- 数据竞争型：多线程同时读写同一个变量，出现脏读、覆盖、丢更新。这类最隐蔽，因为有时结果碰巧是对的。
- 死锁与活锁型：多个线程互相持锁等待，或者一直竞争同一资源导致饥饿和超时。
- 线程管理失控型：线程池满了、任务堆积、线程泄漏，最后把整个应用拖垮。
这类bug难查，是因为它们由“时间窗口”触发，而不是由“固定输入”触发。单次请求看什么都正常，高并发下就有一瞬间多个线程同时执行同一段代码。等到线上出问题时，堆栈只能展示当前状态，根本解释不了是谁先改了数据、谁在等谁释放锁。这也是为什么“并发问题靠事后排查”这条路基本走不通，必须把防线前移到写代码那一刻。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一到第三招：从“写法”上堵死并发bug的源头
2.1 第一招：数据默认不可变，能局部绝不共享
很多并发bug的根源，是我们太习惯把变量定义成成员变量，动不动就让一堆线程去读写同一个字段。我给自己定的规矩是：先问一句“这个数据真的需要被多个线程共享吗”，大部分情况下答案都是“不需要”。
能放进方法内部的变量，不要提出来当成员变量。能用局部变量传参的，就不要用实例字段中转。如果某个配置类数据初始化后就不再变化，直接声明成final并构建成不可变对象。
java复制public class OrderProcessor {
// 只读配置，构造后不修改，天然线程安全
private final RiskConfig riskConfig;
public OrderProcessor(RiskConfig config) {
this.riskConfig = config;
}
public void process(Order order) {
// 订单上下文只在本方法使用，不会泄漏到其他线程
OrderContext ctx = buildContext(order);
riskConfig.evaluate(ctx);
}
}
当你把大部分数据限制在线程私有范围内，并发问题基本就消失了一半。有些场景确实需要线程之间传递数据，这时候优先用ThreadLocal或者方法返回值传递，而不是直接写在共享字段里。比如一次请求中的traceId、userId这些上下文数据，放在ThreadLocal里是常见做法，但要注意在finally里主动清理，否则线程池复用线程会串数据。
2.2 第二招：锁的范围能多小就多小，别一把大锁锁到底
很多人一提到并发就喜欢在方法签名上直接Synchronized，方便是方便，但把整个方法都锁住之后，吞吐量经常断崖式下跌。而且锁范围越大，持有锁时间越长，其他线程等待越久，死锁和超时概率也跟着上来。
正确的思路是：把锁的范围精确压在共享资源的读改写那一小段代码上。比如库存扣减的核心临界区，只需要保护stockMap的检查再更新这一段，完全没有必要把整个接口都锁住。
java复制private final ReentrantLock lock = new ReentrantLock();
public boolean deduct(String skuId, int count) {
lock.lock();
try {
Integer stock = stockMap.get(skuId);
if (stock != null && stock >= count) {
stockMap.put(skuId, stock - count);
return true;
}
return false;
} finally {
lock.unlock();
}
}
像这种读多写少的场景，还可以用ReadWriteLock优化：多个读线程可以并行，只有写线程才需要独占。注意一个坑，很多人图省事只加读锁不加写锁，或者反过来，这等于没锁。用到ReadWriteLock时，所有读路径和写路径必须都走锁，缺一条就前功尽弃。
2.3 第三招：并发容器精确匹配业务语义，别让裸集合裸奔
HashMap和ArrayList本身不是线程安全的，但在业务代码里却经常被当成线程安全的来用。我见过太多团队把“偶发数据错乱”归咎于缓存框架，结果查到最后是那个裸的HashMap。
改用并发容器的时候，也别无脑全换成ConcurrentHashMap。要根据业务访问模式选容器：
- 读多写少、遍历频繁：用
CopyOnWriteArrayList，读操作无锁，写操作复制副本。 - 高频写入、分段更新：用
ConcurrentHashMap，分段锁降低竞争。 - 生产消费场景：用
ConcurrentLinkedQueue或LinkedBlockingQueue，前者无界非阻塞，后者有界可阻塞。
java复制// 正确姿势：购物车缓存
private final ConcurrentHashMap<String, ShoppingCart> cartCache = new ConcurrentHashMap<>();
// 错误姿势：多线程写HashMap，偶发丢数据
private final HashMap<String, ShoppingCart> cartCache = new HashMap<>();
这里要特别提醒：即使换成了ConcurrentHashMap，如果是“先读后写”这种复合操作（比如get之后再put），依然不是原子的。比如“如果不存在就放入”，需要用到putIfAbsent或者compute这类原子方法，否则依然会踩并发坑：
java复制cartCache.computeIfAbsent(userId, uid -> new ShoppingCart(uid));
容器只是工具，工具的语义必须跟你的业务操作对齐，不然工具再好也白搭。
3. 第四到第六招：在机制和工具层面建立并发防线
3.1 第四招：统一线程池治理，禁止裸奔的new Thread
我早期犯过一个特别典型的错：业务里需要异步处理，就直接new Thread(() -> doSomething()).start()。表面上简单，实际埋了三颗雷：
- 没有线程复用，高并发时频繁创建销毁线程，性能极差甚至OOM。
- 线程数无上限，流量突刺时能把机器CPU打满。
- 无法统一监控线程状态和任务队列，出问题只能翻机器日志碰运气。
后来我们项目里做了统一线程池管理，禁止裸用new Thread，所有异步任务必须走项目统一封装的线程池。
java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, // 核心线程数
16, // 最大线程数
60L, TimeUnit.SECONDS, // 空闲线程存活时间
new ArrayBlockingQueue<>(1000), // 有界队列
new NamedThreadFactory("order-async"),
new ThreadPoolExecutor.CallerRunsPolicy()
);
这里有几个参数值得反复推敲。核心线程数和最大线程数不是越大越好，得算过任务类型：IO密集型可以设大一些，CPU密集型的核心线程数建议控制在CPU核心数附近。队列一定要用有界队列，防止任务无限堆积把内存打爆。拒绝策略里，我更偏向CallerRunsPolicy，因为它在队列满时让提交任务的线程自己执行，相当于天然限流，不会直接把任务丢弃。
还有个容易忽略的点：线程池的线程命名。用有意义的线程名（比如order-async-1）能在排查问题时空前节省时间，不然Jstack出来全是pool-3-thread-1，鬼知道是哪个业务线的线程。
3.2 第五招：JUC工具包对准语义，别自己手搓等待唤醒
很多并发bug源于开发者不用现成的并发工具，而是喜欢用wait/notify手搓复杂的等待唤醒逻辑。wait/notify本身很容易出错：notify时机不对、对象锁不一致、wait被异常打断未处理……这些坑一个个踩过来，最稳妥的路子是直接使用JUC包里的工具。它们就是专门为各种并发语义设计的，好好用就行。
- CountDownLatch：一个线程等N个线程完成，典型场景是并行查询多个外部服务后聚合结果。
- CyclicBarrier：N个线程互相等待，全部到达后再继续，典型场景是分批并发处理完数据后汇总。
- Semaphore：控制同时访问某个资源的线程数，典型场景是限流。
- CompletableFuture：编排异步任务链，代替手工
Future+CountDownLatch的复杂组合。
比如一个需要并行查用户信息、订单列表、优惠券、然后汇总返回的接口，用CompletableFuture可以写得很清晰：
java复制CompletableFuture<UserInfo> userFuture = CompletableFuture.supplyAsync(() -> userService.getUser(uid), executor);
CompletableFuture<List<Order>> orderFuture = CompletableFuture.supplyAsync(() -> orderService.listOrders(uid), executor);
CompletableFuture<List<Coupon>> couponFuture = CompletableFuture.supplyAsync(() -> couponService.listCoupons(uid), executor);
CompletableFuture.allOf(userFuture, orderFuture, couponFuture).join();
UserInfo user = userFuture.get();
List<Order> orders = orderFuture.get();
List<Coupon> coupons = couponFuture.get();
这类代码读起来比手写线程同步清晰得多，也几乎没有自己手搓同步逻辑的空间。我的经验是：能把并发协调交给JUC工具解决的，绝不自己动手实现。这是减少等待唤醒类bug的最有效做法。
3.3 第六招：用测试和静态检查在发布前“诱捕”并发问题
写完代码不意味着结束，还要用工具把bug提前炸出来。我在团队里推进了两件事：
第一，静态分析工具接入CI。我们用的是SpotBugs配合spotbugs-concurrency插件，它能扫出一大批明显并发风险，比如在非线程安全集合上做共享读写、在锁内调用可阻塞方法、对象发布溢出这些。虽然扫出来的不一定全是真的bug，但至少能逼着提交代码的人正视风险点。
第二，并发专项回归测试。写一个专门压竞争逻辑的用例，用循环创建几十个线程同时调目标方法，断言最终结果和顺序执行的结果完全一致。
java复制@Test
void testConcurrentDeduct() throws Exception {
int threadCount = 50;
ExecutorService pool = Executors.newFixedThreadPool(threadCount);
CountDownLatch start = new CountDownLatch(1);
CountDownLatch done = new CountDownLatch(threadCount);
for (int i = 0; i < threadCount; i++) {
int finalI = i;
pool.submit(() -> {
try {
start.await();
inventoryService.deduct("sku001", 1);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
done.countDown();
}
});
}
start.countDown();
done.await(10, TimeUnit.SECONDS);
assertEquals(1000 - threadCount, inventoryService.getStock("sku001"));
}
这类测试可能偶尔过、偶尔挂，为了稳定复现竞争问题，可以配合线程调度干预。我常用的手段是在临界区里临时加一点点睡眠或者引入一个线程屏障，把竞争窗口人为放大，这样能大概率稳定复现以前偶发的bug。
4. 真正让“月均12降到0”的关键：把6招变成团队级流程
4.1 Review清单：并发相关代码必须过四道关卡
工具再多，也代替不了人的判断。我在code review里给并发代码定了一套只有四道关卡的检查清单：
- 共享状态边界：这个变量被哪些线程访问？写操作有没有锁？读操作有没有可见性保证？会不会被提前发布到别的线程。如果答案含糊，这代码就不过。
- 锁的粒度和顺序：锁范围是否最小？多个锁之间有没有固定顺序？会不会存在ABBA死锁风险。同时持多个锁的场景，必须按全局统一顺序去拿锁。
- 线程数量和池化：是不是用了
new Thread？线程池参数有没有依据？队列会不会无限增长。 - 超时和失败处理：所有获取锁、等待异步结果的地方有没有超时？超时之后是继续等待还是快速失败？线程中断有没有被正确响应。
这个清单看起来简单，但对降低并发bug非常关键。Review不是为了挑刺，而是强迫写代码的人把并发边界想清楚。很多次我们在Review阶段就拦下了潜在的竞争问题，而不是等上线以后被用户发现。
4.2 压测环境下如何稳定复现并发bug
很多并发bug在普通测试环境就是不出来，必须靠压测场景去逼它出来。我们当时定了两个原则：
一是压测场景必须覆盖真实业务流量模型，不只是简单GET/POST打爆接口，要模拟真实用户在不同分支上的并发操作。比如库存接口，要同时模拟多用户抢同一商品、不同商品、撤销订单回补库存、多仓库存并发扣减这些混合场景。
二是压测过程中必须有实时监控配合。监控线程池活跃度、队列堆积、锁等待时间、GC频率和停顿。一旦看到锁等待时间异常飙高或者线程池队列大量堆积，往往是并发瓶颈或者潜在死锁的前兆。把监控数据和业务数据一起分析，定位效率会提升很多。
4.3 线上监控辅助：用指标提前发现可疑迹象
即使前面做了这么多，线上仍然不能裸奔。我保留了四组并发健康指标，任何一组异常都意味着需要立刻介入：
- 线程池指标：活跃线程数、队列大小、拒绝任务数。
- JVM指标：线程总数、锁竞争次数、GC次数和停顿时间。
- 业务指标：关键操作的RT分位数变化、失败率、数据一致性校验失败数。
- 日志指标：超时日志、锁等待日志、分布式锁获取失败日志的出现频率。
这些指标不需要每次都人工盯，可以用Prometheus+Grafana做基础监控，配合告警规则在指标环比超过阈值时自动通知。指标异常不一定就是bug，但至少能把潜在风险暴露在用户感知之前。
5. 从12到0之后的一点反思：这套打法的边界在哪里
先说清楚，这套打法在单JVM内、单体应用或模块边界清晰的微服务里效果最明显。如果涉及到分布式系统之间的数据一致性，比如多个服务各自操作数据库、Redis缓存和MQ消息，那问题性质就变了，单靠Java内存模型、synchronized、并发容器解决不了，必须引入分布式锁、消息事务、幂等设计这些更外层的机制。
而且“降到0”不是指并发相关的bug从此绝迹，而是指从代码层面进入生产环境的并发正确性问题大幅减少。性能类问题（比如某把锁竞争激烈导致RT上涨）不属于这个口径，那是另一个话题，需要靠压测和性能调优去解决。
踩过无数坑之后，我的体会是：并发bug的根子往往不在“代码写错了”，而在“从一开始就没想清楚并发模型”。写每一行共享数据操作前，先问自己一句：这个数据有几个线程在碰，它们之间是什么关系，我靠什么机制保证安全。这比再多工具和Review清单都更重要。工具和流程是帮你逼出这个思考过程的。当你习惯了这种思考方式，并发bug确实可以趋近于零。