Java并发编程中高并发场景如何设计_架构思路解析_网络技术

高并发下应避免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：让调用线程自己执行任务，自然降速
队列类型选 LinkedBlo ckingQueue（有界）而非 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）。

# java # redis # app # 工具 # 热点 # 并发编程 # 异步任务 # 一加 # 并发请求 # 无锁 # 为什么 # red

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】