求一路向西种子背后的并发坑：3道高频面试题详解

面试被问“为什么线程池要固定核心线程数”，你卡壳了？这是典型的原理盲区，也是Java后端高频面试题的重灾区。别慌，今天用真实踩坑案例，把求一路向西种子相关的并发陷阱一次讲透。

坑的现象：生产环境CPU飙到100%

上周接手一个订单系统，上线第三天凌晨报警，CPU持续99%。查日志发现大量Thread.dump()输出，全是BLOCKED状态，栈顶都卡在synchronized块。更诡异的是，业务量没涨，QPS和平时一样，但响应时间从50ms飙升到5s。这种场景在求一路向西种子类高并发场景特别常见，表面看是线程阻塞，实际根源往往藏在资源竞争里。

我第一反应是加线程，结果越加越卡，最后只能回滚。复盘时发现，问题出在一个看似无害的工具类：RedisLockUtil.tryLock()。这个方法在finally块里释放锁，但获取锁时没设置超时，导致线程无限等待。

// 错误写法：无限等待的分布式锁
public boolean tryLock(String key) {while (!redisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS)) {// 这里没有sleep，也没有超时机制// 线程会一直自旋，占满CPU}return true;
}

这段代码在测试环境跑了几小时都没问题，因为并发量低，锁冲突概率小。但到了生产环境，高峰期每秒上千请求同时抢同一把锁，线程全部卡在while循环里。这就是典型的“测试环境不复现，生产环境炸翻天”。

根本原因：锁竞争与线程池配置的连锁反应

很多新人觉得“加锁就是加个synchronized”，这是最致命的误解。真正的坑在于：锁的粒度、持有时间、释放机制，任何一个环节出问题，都会放大线程池的负载。

以这个案例为例，RedisLockUtil的锁持有时间取决于业务逻辑执行时长。如果业务逻辑里有慢SQL、外部HTTP调用，锁就会被长时间持有。其他线程获取不到锁，只能自旋等待，线程池的核心线程全被占满，新任务只能排队。线程池的队列堆积后，拒绝策略触发，请求开始超时，用户看到的就是“系统卡死”。

更隐蔽的是，很多人用Executors.newFixedThreadPool()创建线程池，以为“固定线程数”就安全了。但JDK文档明确警告：这种方式创建的线程池，队列是LinkedBlockingQueue，无界队列。一旦任务生产速度超过消费速度，队列会无限增长，最终OOM。

// 错误写法：无界队列的线程池
ExecutorService pool = Executors.newFixedThreadPool(10);
// 等价于 new ThreadPoolExecutor(10, 10, 0, MILLISECONDS, new LinkedBlockingQueue<Runnable>())

求一路向西种子类场景，比如秒杀、抢购，瞬时流量是平峰的10-100倍。无界队列会在流量尖峰时疯狂堆积任务，内存瞬间打满。我在掘金技术社区看到过一篇复盘文章，某电商大促时就是因为用了无界队列，导致GC频繁，最后整个集群雪崩。

正确写法对比：有界队列+超时锁+监控

修复方案分三步：换线程池、改锁机制、加监控。

第一步，用ThreadPoolExecutor显式创建线程池，指定有界队列。核心线程数根据CPU核数和业务类型调整：CPU密集型用N+1，IO密集型用2N。队列容量要压测后确定，不能拍脑袋。

// 正确写法：显式配置线程池
private static final ExecutorService ORDER_POOL = new ThreadPoolExecutor(10,                    // 核心线程数20,                    // 最大线程数60,                    // 空闲线程存活时间TimeUnit.SECONDS,new ArrayBlockingQueue<>(100),  // 有界队列，容量100new ThreadFactory() {private final AtomicInteger counter = new AtomicInteger(0);@Overridepublic Thread newThread(Runnable r) {return new Thread(r, "order-pool-" + counter.incrementAndGet());}},new ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略：调用者线程执行
);

第二步，改造分布式锁，加上超时和退避策略。用Redisson或RedisTemplate的setIfAbsent带过期时间，失败后sleep随机毫秒再重试，最多重试3次。

// 正确写法：带超时的分布式锁
public boolean tryLock(String key, long timeoutMs) {long deadline = System.currentTimeMillis() + timeoutMs;int retries = 0;while (System.currentTimeMillis() < deadline && retries < 3) {if (redisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS)) {return true;}// 随机退避，避免惊群try {Thread.sleep(ThreadLocalRandom.current().nextInt(50, 200));} catch (InterruptedException e) {Thread.currentThread().interrupt();return false;}retries++;}return false;
}

第三步，加监控告警。线程池的activeCount、queueSize、rejectedCount必须接入Prometheus，设置阈值告警。锁的等待时间也要埋点，超过100ms就记录慢日志。

复现与修复代码：本地模拟高并发场景

怎么在本地复现这个问题？用JMeter或wrk压测就行。我写了一段最小复现代码，模拟100个线程同时抢同一个Redis key。

// 复现代码：模拟高并发锁竞争
public class LockContentionRepro {public static void main(String[] args) throws Exception {JedisPool pool = new JedisPool();ExecutorService testPool = Executors.newFixedThreadPool(100);CountDownLatch latch = new CountDownLatch(100);long startTime = System.currentTimeMillis();for (int i = 0; i < 100; i++) {testPool.submit(() -> {try {Jedis jedis = pool.getResource();// 模拟错误写法：无限自旋while (!jedis.setnx("lock:order", "1")) {// 无sleep，无超时}Thread.sleep(100); // 模拟业务逻辑jedis.del("lock:order");jedis.close();} finally {latch.countDown();}});}latch.await();System.out.println("Total time: " + (System.currentTimeMillis() - startTime) + "ms");testPool.shutdown();pool.close();}
}

跑起来后，你会发现100个线程几乎同时启动，前几个抢到锁，后面90多个全部卡在while循环。 JVM的jstack输出里，全是RUNNABLE状态，但实际都在自旋。 CPU占用率瞬间拉到100%，但没有任何业务进展。

修复后的版本，把无限自旋改成带超时的重试，再跑一遍，总耗时从无限挂起变成2秒左右。关键差异在于：线程不会无限占用CPU，拿不到锁就快速失败，让调用方决定重试还是降级。

规避建议：从代码规范到架构设计

求一路向西种子类高并发场景，光靠改代码不够，要从三个层面规避。

代码层面：禁止使用Executors工厂方法创建线程池，所有线程池必须显式配置参数。 Code Review时，看到newFixedThreadPool、newCachedThreadPool直接打回。锁的获取必须带超时，释放必须在finally块，且要校验锁的持有者。

架构层面：热点key要拆分。比如订单锁，不要所有订单都抢同一个lock:order，改成lock:order:{orderId}。如果某个key特别热，考虑用本地锁+异步同步，或者换用ZooKeeper的临时顺序节点。

监控层面：线程池和锁的指标必须可视化。我团队现在的做法是，每个线程池都暴露/actuator/metrics端点，Grafana大盘实时展示。锁的等待时间P99超过50ms就黄色告警，超过200ms就红色告警，自动触发扩容预案。

还有一个容易忽略的点：线程池的隔离。不要所有业务共用一个线程池。订单、支付、库存，各自独立线程池。这样某个业务出现慢调用，只会拖垮自己的线程池，不会连累其他核心链路。我在掘金技术社区看过一个案例，某公司因为共用线程池，一个非核心的日志上报任务阻塞，导致支付接口全部超时。

高频面试题延伸：这三个问题必问

把求一路向西种子相关的并发问题，整理成面试必答题。

Q1：线程池的核心参数有哪些？如何设置合理值？ 答：核心参数包括corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、handler。核心线程数根据业务类型定，CPU密集型用N+1，IO密集型用2N。队列容量要压测，拒绝策略根据业务重要性选择CallerRunsPolicy或自定义降级。

Q2：分布式锁的可靠性如何保证？Redisson和ZooKeeper怎么选？ 答：Redisson用看门狗机制自动续期，避免业务未完成锁就过期。 ZooKeeper用临时顺序节点，可靠性更高但性能稍低。高并发场景选Redisson，强一致场景选ZooKeeper。

Q3：如何排查线程池阻塞问题？ 答：先用jstack抓线程快照，看BLOCKED线程的栈顶。再查线程池的queueSize和activeCount，判断是队列满还是线程忙。最后结合慢日志，定位是哪个任务持有锁太久。

这些问题的背后，都是同一个核心：并发不是加锁就行，而是资源竞争的系统性治理。面试时如果能讲出“锁粒度+线程池配置+监控告警”的组合拳，基本就稳了。