Wong Kosheng1. 高并发编程的核心挑战与Java应对策略
当面试官抛出"Java高并发编程实战案例"这个问题时，他们真正想考察的是你对并发问题本质的理解和实战解决能力。在电商秒杀、金融交易、实时通信等场景下，每秒数万级的请求处理已成为常态，而Java作为企业级应用的主力语言，其并发处理能力直接决定了系统能否扛住流量洪峰。
高并发场景下最棘手的三大问题：
- 竞态条件：多个线程同时修改共享数据导致的不可预测结果
- 死锁/活锁：资源竞争导致的线程永久阻塞或无效重试
- 上下文切换开销：线程频繁切换消耗CPU资源
Java的并发武器库演进可分为三个阶段：
- 基础阶段（JDK1.5前）：synchronized+wait/notify
- 工具阶段（JDK1.5）：java.util.concurrent包
- 响应式阶段（现代）：Reactive Streams+协程
关键认知：高并发不等于多线程，合理的架构设计往往比代码级优化更重要。比如用Redis分流可以避免90%的线程竞争问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 秒杀系统实战：从线程安全到分布式锁
2.1 库存超卖问题重现
假设我们有如下简单的库存扣减代码：
java复制public class UnsafeInventory {
private int stock = 100;
public boolean reduceStock() {
if(stock > 0) {
stock--;
return true;
}
return false;
}
}
在多线程环境下，这段代码会导致：
- 多个线程同时通过stock>0检查
- 实际扣减后库存可能变为负数
2.2 解决方案对比
| 方案 | 实现方式 | 吞吐量 | 适用场景 |
|---|---|---|---|
| synchronized | 方法级加锁 | 低（~2000TPS） | 单机简单场景 |
| ReentrantLock | 显式锁控制 | 中（~5000TPS） | 需要公平锁/可中断 |
| CAS乐观锁 | AtomicInteger | 高（~8000TPS） | 竞争不激烈场景 |
| Redis分布式锁 | SETNX+Lua | - | 分布式环境 |
2.3 最优实践：分段锁+Redis预减
java复制// 分段锁示例
public class SegmentLockInventory {
private final List<ReentrantLock> locks =
IntStream.range(0, 16)
.mapToObj(i -> new ReentrantLock())
.collect(Collectors.toList());
private final int[] segments = new int[16];
public boolean reduceStock(Long itemId) {
int hash = itemId.hashCode() & 0x7FFFFFFF;
int index = hash % locks.size();
locks.get(index).lock();
try {
if(segments[index] > 0) {
segments[index]--;
return true;
}
return false;
} finally {
locks.get(index).unlock();
}
}
}
3. 线程池调优：参数配置与拒绝策略
3.1 线程池核心参数黄金比例
对于IO密集型应用（如微服务调用）：
code复制线程数 = CPU核心数 * (1 + 平均等待时间/平均计算时间)
例如4核服务器，平均等待时间15ms，计算时间5ms：
code复制4 * (1 + 15/5) = 16线程
3.2 四种拒绝策略对比实验
我们在10万请求压力下测试：
- AbortPolicy：直接抛出RejectedExecutionException
- 优点：快速失败
- 缺点：需要客户端处理异常
- CallerRunsPolicy：由提交线程自己执行
- 优点：保证不丢失任务
- 缺点：可能阻塞主线程
- DiscardOldestPolicy：丢弃队列最老任务
- 优点：保持处理最新请求
- 缺点：可能丢失重要任务
- 自定义策略：写入Kafka重试队列
- 最优解：实现削峰填谷
3.3 监控线程池的必备指标
java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(...);
// 注册监控
Metrics.gauge("threadpool.active.count",
() -> executor.getActiveCount());
Metrics.gauge("threadpool.queue.size",
() -> executor.getQueue().size());
4. 并发容器实战陷阱与规避
4.1 ConcurrentHashMap的size()代价
CHM的size()方法需要遍历所有段求和，在高并发下可能成为瓶颈。替代方案：
java复制// 使用AtomicLong计数器
private final AtomicLong counter = new AtomicLong();
private final ConcurrentMap<String, Object> map = new ConcurrentHashMap<>();
public void put(String key, Object value) {
Object old = map.put(key, value);
if(old == null) {
counter.incrementAndGet();
}
}
public long size() {
return counter.get();
}
4.2 CopyOnWriteArrayList的适用场景
适合读多写少（如监听器列表），但不适合频繁修改。实测对比：
| 操作 | ArrayList | CopyOnWriteArrayList |
|---|---|---|
| 读(100万次) | 12ms | 15ms |
| 写(1万次) | 8ms | 210ms |
4.3 BlockingQueue选型指南
- ArrayBlockingQueue：固定大小，内存友好
- LinkedBlockingQueue：无界队列，可能OOM
- PriorityBlockingQueue：优先级排序
- SynchronousQueue：直接传递，无缓冲
5. 并发调试与性能优化实战
5.1 死锁检测工具
-
jstack：
bash复制
jstack -l <pid> > thread_dump.txt查找"deadlock"关键词
-
Arthas实时诊断：
bash复制thread -b # 检测死锁 thread --state BLOCKED # 查看阻塞线程
5.2 JVM锁优化参数
bash复制-XX:+UseBiasedLocking # 偏向锁（JDK15已废弃）
-XX:+UseSpinning # 自旋锁
-XX:PreBlockSpin=10 # 自旋次数
5.3 并发性能测试要点
- JMeter参数：
- 线程组设置阶梯上升（100→1000→5000）
- 添加聚合报告和响应时间图
- 关键指标：
- 吞吐量（TPS/QPS）
- 95/99百分位响应时间
- 错误率
6. 现代Java并发新特性
6.1 Virtual Threads（JDK21）
java复制try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
IntStream.range(0, 10_000).forEach(i -> {
executor.submit(() -> {
Thread.sleep(Duration.ofSeconds(1));
return i;
});
});
} // 这里会等待所有线程结束
6.2 Structured Concurrency（JDK21）
java复制try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
Future<String> user = scope.fork(() -> findUser());
Future<Integer> order = scope.fork(() -> fetchOrder());
scope.join(); // 等待所有子任务
scope.throwIfFailed(); // 异常传播
return new Response(user.resultNow(), order.resultNow());
}
6.3 Reactive编程对比
java复制// WebFlux示例
public Mono<Order> getOrder(Long id) {
return Mono.fromCallable(() -> db.query(id))
.subscribeOn(Schedulers.boundedElastic())
.timeout(Duration.ofSeconds(1))
.retryWhen(Retry.backoff(3, Duration.ofMillis(100)));
}
7. 面试实战：高频问题解析
7.1 synchronized实现原理
- 对象头Mark Word：存储锁状态（无锁/偏向锁/轻量级锁/重量级锁）
- Monitor机制：依赖操作系统的mutex指令
- 锁升级过程：偏向锁→轻量级锁→重量级锁
7.2 AQS核心设计
java复制// 自定义同步器示例
class Mutex extends AbstractQueuedSynchronizer {
protected boolean tryAcquire(int acquires) {
return compareAndSetState(0, 1);
}
protected boolean tryRelease(int releases) {
setState(0);
return true;
}
}
7.3 ThreadLocal内存泄漏防范
正确使用姿势：
java复制try {
ThreadLocal<Object> threadLocal = new ThreadLocal<>();
threadLocal.set(new Object());
// 使用threadLocal
} finally {
threadLocal.remove(); // 必须清理
}
8. 真实生产案例：支付系统对账优化
某支付平台每日需处理2000万笔交易对账，原有串行处理耗时4小时。通过以下优化降至15分钟：
- 任务分片：按商户ID哈希分桶
- 并发控制：固定线程池+CountDownLatch
- 结果合并：ConcurrentHashMap合并结果
- 错误处理：失败任务入延迟队列重试
关键代码片段：
java复制List<Merchant> merchants = getAllMerchants();
int batchSize = Runtime.getRuntime().availableProcessors() * 2;
List<List<Merchant>> batches = Lists.partition(merchants, batchSize);
ExecutorService executor = Executors.newFixedThreadPool(batchSize);
ConcurrentMap<String, ReconciliationResult> resultMap = new ConcurrentHashMap<>();
batches.forEach(batch -> {
executor.execute(() -> {
batch.forEach(merchant -> {
resultMap.put(merchant.getId(), reconcile(merchant));
});
});
});
9. 并发编程的黄金法则
- 先测量后优化：用JProfiler/Arthas定位真实瓶颈
- 避免过早优化：不是所有代码都需要并发处理
- 保持简单：能用synchronized解决的问题不用Lock
- 关注可见性：volatile不能替代同步
- 防御性编程：总是考虑最坏并发场景
在最近的一个物联网平台项目中，我们通过将synchronized替换为StampedLock的乐观读模式，使设备状态查询吞吐量提升了3倍。但要注意：这种优化必须建立在充分压测的基础上，因为StampedLock的实现复杂度远高于synchronized。