高并发下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()，而它会被任意业务代码拖垮。
立即学习“Java免费学习笔记（深入）”；
- 所有可能耗时的操作，必须显式指定线程池：
supplyAsync(() -> heavyWork(), executor)、thenApplyAsync(..., executor) - 慎用
join()和get()：它们会阻塞当前线程，在 Web 容器（如 Tomcat）中可能导致线程池耗尽 - 异常处理别漏掉：
exceptionally()只捕获上一阶段异常，handle()才能同时处理结果和异常，推荐优先用后者 - 多个依赖关系建议用
allOf+thenCombine组合，但注意allOf返回CompletableFuture<void></void>，需手动 collect 结果，容易写错
CompletableFuture<String> a = CompletableFuture.supplyAsync(() -> callServiceA(), ioExecutor);
CompletableFuture<Integer> b = CompletableFuture.supplyAsync(() -> callServiceB(), ioExecutor);
return CompletableFuture.allOf(a, b)
.thenApply(v -> {
// 错误：a.get() 和 b.get() 会阻塞！
return a.join() + b.join(); // 正确：join 不抛检异常，且语义清晰
});
高可用不是靠加机器堆出来的，是靠对每个并发原语的副作用足够敏感。最容易被忽略的，其实是那些“看起来很安全”的默认行为——比如 commonPool 的共享性、ConcurrentHashMap 的弱一致性边界、还有拒绝策略背后的服务降级意图。
