Java并发编程中如何编写高可用代码_实践经验总结_技术教程

高并发下synchronized易致服务不可用，因其在长耗时I/O时阻塞线程引发排队雪崩；应减小锁粒度、移出临界区的阻塞操作，并优选ReentrantLock或CAS机制。

为什么直接用 `synchronized` 容易导致服务不可用

不是锁本身有问题，而是它在高并发、长耗时场景下会把线程卡死在临界区外，形成“排队雪崩”。比如一个接口里用 synchronized 包裹了远程 HTTP 调用，一旦下游响应变慢或超时，所有后续请求全堵在锁入口，TPS 断崖下跌。

锁粒度要细：优先锁对象字段，而不是整个方法或 this
避免在同步块内做 I/O、RPC、数据库查询——这些操作应移出临界区
考虑用 ReentrantLock 替代，它支持超时获取（tryLock(long, TimeUnit)），失败可快速降级或重试
若必须同步远程调用结果，改用缓存 + CAS 更新（如 AtomicReference.compareAndSet）更安全

`ConcurrentHashMap` 的常见误用与扩容陷阱

很多人以为 ConcurrentHashMap 是“万能线程安全 Map”，但它的线程安全仅限于单个操作原子性，组合操作（如“检查再插入”）仍需额外同步。

computeIfAbsent 是安全的，但注意其 lambda 内不能有阻塞逻辑，否则会拖慢整个 segment 的写入
扩容期间读操作不阻塞，但写操作可能触发帮助扩容（helpTransfer），CPU 使用率会阶段性飙升
初始化容量别设太小：new ConcurrentHashMap(16) 在写入 1000 条后大概率触发多次扩容；建议预估 size 后乘以 1.5 再向上取最近 2 的幂
不要用 keySet().iterator() 做遍历并修改，迭代器弱一致性不保证看到最新写入，且无法检测并发修改异常

线程池配置不当引发的 OOM 和拒绝风暴

线上最常踩的坑是把 Executors.newFixedThreadPool(n) 直接丢进生产环境。它的 LinkedBlockingQueue 默认无界，任务堆积时内

存持续上涨，直到 GC 失败或被 OS Kill。

永远手动构造 ThreadPoolExecutor，明确指定有界队列（如 ArrayBlockingQueue）和拒绝策略
拒绝策略别只用 AbortPolicy（抛 RejectedExecutionException），对核心链路建议用 CallerRunsPolicy 让调用方自己执行，起到自然限流作用
线程数不是越多越好：CPU 密集型任务线程数 ≈ CPU 核数；IO 密集型可按公式 cpu_count * (1 + wait_time / cpu_time) 估算，但务必压测验证
记得给线程池命名（通过 ThreadFactory），否则堆栈里全是 pool-1-thread-1，排查问题时根本分不清是谁的池子

CompletableFuture 链式调用中的隐形阻塞点

CompletableFuture 看似异步，但一不小心就写出“伪异步”代码。最典型的是在 thenApply 或 thenAccept 里调用阻塞 API，或者没指定异步执行器，导致默认用 ForkJoinPool.commonPool()，而它会被任意业务代码拖垮。

所有可能耗时的操作，必须显式指定线程池：supplyAsync(() -> heavyWork(), executor)、thenApplyAsync(..., executor)
慎用 join() 和 get()：它们会阻塞当前线程，在 Web 容器（如 Tomcat）中可能导致线程池耗尽
异常处理别漏掉：exceptionally() 只捕获上一阶段异常，handle() 才能同时处理结果和异常，推荐优先用后者
多个依赖关系建议用 allOf + thenCombine 组合，但注意 allOf 返回 CompletableFuture，需手动 collect 结果，容易写错

CompletableFuture a = CompletableFuture.supplyAsync(() -> callServiceA(), ioExecutor);
CompletableFuture b = CompletableFuture.supplyAsync(() -> callServiceB(), ioExecutor);
return CompletableFuture.allOf(a, b)
    .thenApply(v -> {
        // 错误：a.get() 和 b.get() 会阻塞！
        return a.join() + b.join(); // 正确：join 不抛检异常，且语义清晰
    });

高可用不是靠加机器堆出来的，是靠对每个并发原语的副作用足够敏感。最容易被忽略的，其实是那些“看起来很安全”的默认行为——比如 commonPool 的共享性、ConcurrentHashMap 的弱一致性边界、还有拒绝策略背后的服务降级意图。