高并发下应避免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 频繁、上下文切换开销剧增。
核心是把“并发请求数”和“实际执行线程数”解耦，靠队列缓冲 + 拒绝策略兜底。
立即学习“Java免费学习笔记（深入）”；
-
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）。
