17370845950

高并发下应避免synchronized全局锁，因其导致请求串行化、吞吐量骤降，并易引发线程饥饿或死锁；优先使用AtomicInteger、ReentrantLock（带超时）、ConcurrentHashMap等并发工具。

高并发场景下为什么要避免直接用 synchronized 做全局锁

它会把所有请求串行化，吞吐量直接掉到单线程水平。哪怕只是读多写少的计数器，synchronized 也会让 getCount() 这种只读操作排队等待写锁释放。

更隐蔽的问题是：锁粒度没控制好时，容易引发线程饥饿或死锁，尤其在多个共享对象交叉加锁（比如先锁 A 再锁 B，另一处先锁 B 再锁 A）的场景下。

• 优先用 java.util.concurrent 包下的无锁或细粒度锁组件，比如 AtomicInteger 替代 int count + synchronized
• 若必须用锁，用 ReentrantLock 配合 tryLock(long, TimeUnit) 设置超时，避免无限等待
• 对集合类操作，别用 Vector 或 Hashtable，改用 ConcurrentHashMap 或 CopyOnWriteArrayList（注意后者适合读远多于写的场景）

如何用 ThreadPoolExecutor 控制并发流量而不压垮系统

直接 new Thread().start() 或无限制的 Executors.newCachedThreadPool() 是高并发服务崩溃的常见原因——线程数爆炸、GC 频繁、上下文切换开

核心是把“并发请求数”和“实际执行线程数”解耦，靠队列缓冲 + 拒绝策略兜底。

• corePoolSize 设为 CPU 核心数 × (1 ~ 2)，避免 CPU 空转；maximumPoolSize 根据内存和 IO 耗时决定，一般不超过 200
• 拒绝策略别用默认的 AbortPolicy（抛 RejectedExecutionException），生产环境推荐 CallerRunsPolicy：让调用线程自己执行任务，自然降速
• 队列类型选 LinkedBlockingQueue（有界）而非 SynchronousQueue（无界），防止突发流量把队列撑爆 OOM

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    4, 16,
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

CompletableFuture 如何真正提升异步链路吞吐量

很多人以为用了 CompletableFuture.supplyAsync() 就算异步了，但默认用的是 ForkJoinPool.commonPool()，这个共享池会被所有地方共用，一个慢任务拖垮整个池子。

关键不是“是否异步”，而是“异步在哪执行”以及“是否阻塞主线程”。比如 HTTP 调用、DB 查询这类 IO 操作，必须交给专门的 IO 线程池，不能挤占 CPU 密集型任务的资源。

• 自定义线程池传入：supplyAsync(() -> db.query(), ioExecutor)，其中 ioExecutor 是独立配置的 ThreadPoolExecutor
• 慎用 join() 和 get()，它们会阻塞当前线程；优先用 thenApply()、thenCompose() 做非阻塞编排
• 组合多个异步任务时，用 allOf() + thenAccept() 替代循环 join()，减少线程等待时间

缓存穿透 / 雪崩 / 击穿问题在并发下怎么破

并发请求撞上空缓存（如恶意查不存在的订单 ID），所有线程都穿透到 DB，就是穿透；大量缓存同时过期，请求全打到 DB，就是雪崩；热点 key 失效瞬间大量请求涌进，就是击穿。三者在高并发下都会被放大。

单一加锁（比如 synchronized(this)）解决不了，因为锁范围太小或太大都不行。

• 穿透：加布隆过滤器（BloomFilter）预判 key 是否可能存在，不存在直接返回，不查缓存也不查 DB
• 雪崩：给不同 key 设置随机过期时间（比如基础 TTL + Random.nextInt(60) 秒），避免集体失效
• 击穿：用 Redis 的 SETNX 或 Caffeine 的 cache.get(key, loader) 原子加载，确保只有一个线程回源加载，其余等待

这些方案单独用效果有限，真正稳的关键是分层防御：接入层限流（如 Guava RateLimiter）→ 缓存层防穿透 → DB 层熔断（如 Hystrix 或 Resilience4j）。