Java高并发核心知识与实战调优：线程池、缓存与分布式锁

搞 Java 后端的人到了准备面试的阶段十有八九会被“高并发”这三个字卡住。卡住的原因往往不是没背过面试题而是背的答案和真实系统对不上你能默写 ConcurrentHashMap 的源码细节却说不清缓存穿透和缓存击穿的区别你能背出线程池七大参数但被问到“核心线程数到底设多少”就开始含糊。这篇文章我按照面试时的真实追问逻辑来组织从一条请求进入系统后的完整生命周期讲起覆盖线程池、JMM 与锁、并发容器、Redis 缓存设计、分布式锁与幂等最后用一次真实的 JMeter 压测和调优过程把这些知识点串起来。目标不是让你背题而是让你在面试时能把“为什么”讲清楚也能在项目里真的用得上。1. 高并发问题到底在考什么从一条请求的生命周期说起1.1 面试官问高并发其实是在问你的“系统观”很多候选人把高并发面试理解成“背诵题”听到“高并发”三个字就条件反射地吐出线程池参数表。但真正有经验的面试官通常不会直接问“线程池有哪些参数”而是让你描述一个具体场景秒杀、热点商品、签到、排行榜。因为高并发从来不是一个独立的知识点而是一整条链路上的能力检验。一条典型的请求会经过负载均衡层Nginx 或云负载均衡→ 应用层Controller → Service → DAO→ 数据层数据库、缓存、消息队列。流量上涨后每一个环节都可能成为瓶颈。面试官通过追问“你遇到过什么瓶颈、怎么定位、怎么解决”来判断你是否有真实的生产经验而不只是看过几篇源码分析文章。1.2 高频考点分布哪些内容占了 90% 的面试题根据我接触过的真实面试题和招聘反馈Java 高并发方向上考频最高的大致是这几类线程与线程池参数含义、执行顺序、拒绝策略、核心线程数设置、线程复用原理。JMM 与锁volatile、synchronized、ReentrantLock、CAS、死锁排查。并发容器ConcurrentHashMap 底层、CopyOnWriteArrayList 适用场景、阻塞队列。缓存缓存穿透、击穿、雪崩以及缓存与数据库的一致性。分布式场景分布式锁、幂等、限流、消息队列削峰。下面几节会逐一展开重点放在“面试官会怎么追问、正确回答的边界在哪里”。你会发现这五类考点并不是孤立的它们最终都指向同一个问题在资源有限的情况下如何让系统在流量冲击下保持可用和一致。1.3 基础设施层K8s 与云环境的高并发组件最近有不少人在搜“k8s用于处理高并发的组件”这说明面试已经不只停留在 Java 代码层面了。搞高并发底层基础设施同样重要。比如单节点 K8s 上跑微服务流量上来后 HPAHorizontal Pod Autoscaler可以根据 CPU 或自定义指标自动扩容Ingress Controller 负责入口流量分发Service 层做负载均衡Pod 的 requests 和 limits 配置则直接影响调度结果和稳定性。这部分内容往往在“迁移 压测”场景里被集中考察。热搜词条里就有一条很典型的场景单节点 K8s 上的微服务整套环境迁移到云上 ECS 之后由压测人员用配套的 JMeter 脚本做高并发测试验证云上环境的承载能力。这个场景我会在第 7 章结合具体流程详细展开。2. 线程与线程池核心线程数怎么定别再直接背“CPU核数1”2.1 线程池参数与执行顺序面试官爱问的反直觉细节ThreadPoolExecutor 有七个参数corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。面试官最喜欢倒着问当任务提交速度超过处理速度时线程池内部到底按什么顺序执行正确的顺序是先判断核心线程是否已满未满则直接创建线程执行核心线程满了任务先进入工作队列队列满了才创建非核心线程直到线程数达到 maximumPoolSize如果队列和最大线程数都满了才触发拒绝策略。很多人把“先入队再扩线程”这个顺序记反了这是最常见的扣分点。记反的结果就是当面试官问“核心线程 4、最大线程 8、队列容量 100同时提交 200 个任务时线程池的行为”你会答错。排错思路其实很清晰前 4 个任务创建核心线程执行第 5 到第 104 个任务进入队列第 105 到第 108 个任务创建非核心线程执行剩余 92 个任务触发拒绝策略。注意线程池的执行顺序是“先填满核心线程再丢给队列排队队列满了才创建非核心线程”不是“核心线程满了立刻新建线程”。这个顺序在面试中十有八九会被追问具体例子。2.2 核心线程数的两种计算思路公式背后的原理网上一搜全是“CPU 密集型用 N1IO 密集型用 2N”。这个口诀应付初级面试还行面试官只要追问一句“为什么”很多人就答不上来了。其实原理很简单一个线程在运行周期里要么在用 CPU要么在等 IO磁盘 IO、网络 IO、锁等待。设置核心线程数的目标是让 CPU 尽可能忙又不至于因为频繁切换线程引入额外开销。计算密集型任务线程基本不阻塞最佳线程数接近 CPU 核数多给 1 到 2 个是为了应对偶发的缺页中断、GC 停顿这类情况所以取 N1。IO 密集型任务线程大量时间在等待CPU 利用率不高需要更多线程同时等 IO。常用的推导公式是最佳线程数 CPU 核数 ×1 等待时间 / 计算时间。举个例子假设一次请求中 CPU 计算耗时 10ms等待下游接口响应 90ms那么单核需要的线程数约为 1 9 10四核机器就是 40 左右。面试时能把这个公式推导出来比直接背 2N 更有说服力。2.3 队列选型与拒绝策略设计取舍才是加分项workQueue 的选择决定了系统在突发流量下的表现。ArrayBlockingQueue 是有界队列可以起到“防洪”作用LinkedBlockingQueue 默认无界极端情况下任务无限堆积会导致 OOMSynchronousQueue 不存任务直接把任务交给线程适合“不能马上处理就拒绝”的场景。拒绝策略有四种AbortPolicy抛异常默认、CallerRunsPolicy调用者自己执行、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃队列头任务。我的建议是关键业务里自定义拒绝策略比如记录日志、写入降级队列或发送告警而不是默默丢任务也不要直接抛异常让用户看到 500。下面是一个推荐的自定义配置示例ThreadPoolExecutor executor new ThreadPoolExecutor( 20, // 核心线程数 40, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲回收时间 new ArrayBlockingQueue(1000), // 有界队列 new ThreadFactoryBuilder().setNameFormat(import-pool-%d).build(), new RejectedExecutionHandler() { Override public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { log.error(task rejected, queueSize{}, activeCount{}, e.getQueue().size(), e.getActiveCount()); // 写入降级队列后续异步补偿 } } );2.4 一个真实场景导入接口的线程池配置我之前处理过一个批量导入接口每次导入上万条数据逐条同步处理耗时太久。改造方案是把数据拆分成多个批次提交给线程池并发处理每批 100 条启动一个任务。当时任务类型是 IO 密集型因为每条数据都要查库判重、调外部接口补充信息最终按公式把核心线程数定在 20 左右最大线程数 40队列用有界 ArrayBlockingQueue容量 1000。压测后整体导入时间从原来的 8 分钟降到 2 分钟左右而且队列满时会触发自定义拒绝策略把失败的批次记录到补偿表不会丢数据。这个例子说明线程池不只是面试题它就是一个非常实用的性能优化工具。3. JMM、volatile 与锁数据一致性的底层逻辑3.1 从 JMM 看问题可见性、原子性、有序性Java 内存模型JMM定义了一套规则用来规范多线程读写共享变量的行为。主内存是所有线程共享的每个线程还有自己的工作内存对应 CPU 的高速缓存和寄存器。线程对变量的读写必须通过工作内存这就带来了一个直观的问题线程 A 改了变量线程 B 不一定立刻看得到这就是可见性问题。面试时可以把三性串成一条线可见性由 volatile 解决原子性由锁、synchronized、原子类解决有序性由 volatile 禁止重排序和 Happens-Before 规则保证。很多人只背结论不背“为什么 volatile 能保证可见性”。底层逻辑是写 volatile 变量时编译器会在生成的指令中插入内存屏障强制把当前工作内存的修改写回主内存并让其他 CPU 核的对应缓存行失效。3.2 volatile 的边界可见性不等于原子性volatile 最常见的误用场景是给计数器加 volatile。两个线程同时执行 count即使 count 声明为 volatile依然会丢更新。因为 count 不是一条原子指令而是“读 → 加 → 写”三步volatile 只保证每一步完成时对其他线程可见不能保证这三步作为一个整体不被其他线程插入。正确做法是单变量计数用 AtomicInteger复合操作加 synchronized 或 ReentrantLock。面试时主动指出这一点是一个很明显的加分动作因为说明你真的用过而不是只背过概念。我见过很多候选人说“volatile 能解决并发问题”一追问就露馅了。3.3 synchronized 的锁升级过程从偏向锁到重量级锁HotSpot 对 synchronized 做了大量优化锁的状态依次是无锁 → 偏向锁 → 轻量级锁 → 重量级锁。偏向锁是为了解决“只有一个线程访问同步块”的代价第一次获取时会把线程 ID 记录在对象头里后续同一个线程进入不需要再做同步一旦出现竞争升级为轻量级锁通过 CAS 自旋抢锁自旋超过阈值或者等待线程太多就升级为重量级锁进入操作系统管程线程阻塞唤醒开销最大。面试官喜欢追问“锁能不能降级”。准确说法是偏向锁可以批量撤销但轻量级锁不能降级回偏向锁锁只能升级不能降级。这个细节很多人答错。3.4 锁的选择ReentrantLock、CAS 与乐观锁选型要看场景。synchronized 简单、自动释放、支持锁升级ReentrantLock 支持可中断获取锁、超时获取、公平锁、多个 Condition 条件队列。比如调用外部接口时最多等 500ms就应该用 ReentrantLock 的 tryLock 方法避免无限等待。乐观锁的典型实现是 CAS 版本号。数据库层面就是经典写法UPDATE inventory SET stock stock - 1, version version 1 WHERE sku_id ? AND version ?。CAS 在低竞争时性能很好但高竞争下会大量自旋反而浪费 CPU。这也是很多库存系统最终在热点 SKU 上用“Redis 预扣 异步落库”方案的原因后面第 5 章会细讲。4. ConcurrentHashMap 与并发容器源码背后的设计取舍4.1 为什么 HashTable 和 synchronizedMap 扛不住并发HashTable 用一把全局锁锁住整张表任何读写都串行化Collections.synchronizedMap 本质也是全表锁。并发稍微一上来所有线程都在抢同一把锁吞吐量急剧下降。ConcurrentHashMap 的核心设计思想就是把锁的粒度变细让不同线程可以同时操作不同的桶位。4.2 从 JDK 1.7 到 1.8锁粒度演进是核心这是 Java 并发面试里最高频的源码题之一。JDK 1.7 的 ConcurrentHashMap 采用 Segment HashEntry 结构Segment 继承 ReentrantLock默认 16 个 Segment理论上支持 16 个线程并发写get 操作通过 entry 的 volatile 保证可见性不加锁。JDK 1.8 取消了 Segment改用 Node 数组 CAS synchronized插入时如果桶位为空用 CAS 直接放如果桶位不为空用 synchronized 锁住桶头节点。锁粒度从 Segment 级别细化到桶级别并发度更高代码也更简洁。面试时建议把这个演进过程讲清楚再补一句“1.8 的 synchronized 已经经过锁升级优化锁竞争没那么激烈时性能并不差”这能体现你对 JVM 锁机制有整体认知。4.3 size() 与 CounterCell先乐观后悲观的统计思路1.8 的 size() 实现思路很值得借鉴不再加锁遍历所有 Segment而是先乐观地无锁统计 baseCount 加上分散在 CounterCell 数组里的计数如果统计过程中发现竞争比较激烈再加锁重试。CounterCell 的作用是把计数操作分散到多个格子降低单点竞争。这种“先乐观统计冲突严重再退化到悲观策略”的思路在日常开发中同样适用。比如你做一个简单的计数接口可以先尝试无锁的原子累加遇到激烈竞争再考虑分段计数或者加锁。4.4 其他并发容器CopyOnWriteArrayList 与阻塞队列CopyOnWriteArrayList 适合读多写少的场景写操作复制一个新数组写完再替换引用读线程完全不需要加锁。代价是写成本高不适合频繁写的场景。阻塞队列 LinkedBlockingQueue、ArrayBlockingQueue 是线程池和消息中间件缓冲的核心组件take() 在队列为空时阻塞put() 在队列满时阻塞是生产者-消费者模式的基础。我在实际项目里最常用的是 ArrayBlockingQueue 自定义拒绝策略配合第 2 章的线程池配置在处理突发流量时非常稳。5. Redis 缓存设计穿透、击穿、雪崩的根治方案5.1 缓存为什么能扛高并发读写比例决定策略高并发系统里数据库能承受的 QPS 通常在千到万级Redis 单实例可以到十万级。加了缓存之后请求先在缓存里命中只有 miss 才打到数据库这是读多写少系统的第一层屏障。Redis 缓存设计的核心就是围绕“缓存和数据库之间的一致性问题”展开而面试中问得最集中的就是穿透、击穿、雪崩这三个经典问题。5.2 缓存穿透查一个本来就不存在的数据穿透是指请求的数据在缓存和数据库里都不存在导致每次请求都穿过缓存直接打到数据库。最常用的方案有两个一是缓存空值把 NULL 也缓存起来过期时间设短一些比如 60 秒二是布隆过滤器在请求进入时先判断 key 是否可能存在不存在直接返回。布隆过滤器有一定误判率只能判断“一定不存在”和“可能存在”更适合白名单、黑名单 ID 这类“不存在比例很高”的场景。如果业务里这种无效查询本来就少缓存空值更简单直接。两者也可以叠加使用。5.3 缓存击穿热点 key 失效瞬间被打爆击穿和穿透的区别一定要分清楚击穿针对一个热点 key在它过期的瞬间大量请求同时去数据库查。最经典的手段是互斥锁缓存 miss 时先尝试获取分布式锁Redis SETNX拿到锁的线程去查库并回填缓存没拿到锁的线程短暂 sleep 后重试读缓存。另一种思路是逻辑过期缓存里不设置物理过期时间而是存一个逻辑过期时间戳发现过期时先返回旧值同时异步线程去刷新缓存。这个方案牺牲一点一致性换用户体验和并发安全适合不追求强一致但流量很大的场景。5.4 缓存雪崩批量失效的连锁反应雪崩有两种层面一是大量 key 设置了相近的过期时间同一时刻集体失效请求全部打到数据库二是缓存服务本身不可用所有请求直击数据库。解决办法首先是过期时间加随机值比如 base random 300 到 600 秒把失效时间打散其次Redis 高可用架构主从 哨兵、Cluster和本地缓存兜底Caffeine能大幅降低对数据库的冲击。注意面试时要主动把穿透、击穿、雪崩三者对比着讲。穿透是查不存在的数据击穿是热点 key 过期瞬间被打爆雪崩是大面积 key 同时失效或 Redis 彻底不可用。对比着讲面试官会觉得你的知识是成体系的。5.5 ERP 库存场景一个完整的并发扣减方案热搜词里有“erp库存场景高并发的解决方案”我分享一个实际做过的方案。场景是促销期间多个门店同时在 ERP 系统上报订单核心问题就是防止超卖和保证最终一致。整体的分段思路是热点商品库存提前预热到 Redis扣减用 Lua 脚本保证原子性。下单后把扣减记录写入消息队列消费者异步更新数据库库存完成最终一致。如果 Redis 不可用降级到数据库乐观锁通过UPDATE ... WHERE stock 1避免超卖。Redis 扣减的 Lua 脚本如下local stock tonumber(redis.call(GET, KEYS[1])) if not stock or stock 0 then return -1 end redis.call(DECR, KEYS[1]) return stock - 1这套方案的核心不是某一个组件而是“Redis 快速扣减 队列异步落库 数据库兜底”的组合。单独用 Redis 扣库存存在 Redis 宕机丢数据的风险单独用数据库乐观锁又扛不住热点商品的更新压力组合起来才能在可用性和一致性之间取得平衡。6. 分布式锁与幂等设计多节点下的一致性问题6.1 分布式环境下 synchronized 为什么会失效synchronized 锁的是 JVM 内部的对象监视器。微服务部署多个实例时每个实例各锁各的互不相干。比如两台服务器同时处理同一个订单的支付回调两边的 synchronized 代码块都能同时进入因为两把锁根本就不是同一把。分布式场景需要一把“所有节点都能看到”的锁最常见的是基于 Redis 或 ZooKeeper 实现。6.2 Redis 分布式锁的正确姿势与 Redisson最基础的正确姿势是SET key value NX PX 30000。NX 保证只有 key 不存在时才能设置成功PX 设置过期时间防止持有者宕机后变成死锁。value 必须放一个唯一标识比如 UUID释放锁时用 Lua 脚本先比较 value 再删除避免误删别人的锁。Redisson 封装了这些逻辑还提供了看门狗机制如果业务没执行完会自动续期避免业务执行时间超过锁过期时间导致锁提前失效。但要注意Redis 主从切换时锁可能丢失所以对一致性要求极高的场景可以考虑 ZooKeeper 临时顺序节点实现分布式锁。RedLock 方案本身争议也很大面试时可以提一提说明你了解它的局限性。6.3 幂等设计防止重复提交的三种常见做法幂等在高并发场景里和锁一样重要。前端重复点击、MQ 重试、超时重试都会导致同一个请求被执行多次。常见做法有三种利用数据库唯一约束订单号或业务流水号做唯一索引重复插入直接报错或被忽略。利用 Redis SETNX 做请求去重第一次请求设置成功才放行后续重复请求直接返回。利用状态机流转校验比如订单状态只有从“待支付”才能流转到“已支付”重复支付回调直接丢弃。这三种做法可以组合使用。实际项目里我在写支付回调接口时通常会同时用“唯一约束 状态流转校验”双保险避免重复入账。6.4 消息队列削峰把突发流量变平滑秒杀这类场景同步处理所有请求会把下游系统打垮。常见做法是在入口做限流只把真正能处理的请求放进来写入消息队列消费者再按数据库能承受的速率消费落库。消息队列削峰的本质是把时间维度上的突发流量转化为空间维度上的缓冲存储消费者消费速率是可控的。这个思路也可以延伸应用到日志收集、异步通知等场景。7. 压测验证与调优从 JMeter 报告到一次真实迁移7.1 压测前必须明确的三个问题理论讲再多最终都要用压测来验证。压测前先确认三件事压测目标是什么TPS、RT、错误率压测环境是否和生产等规模压测数据是否真实。没有目标就压测出来的报告没有参考价值。最近热搜里有一条很典型的场景单节点 K8s 上的若依微服务整套环境要尽量不停服、不丢数据地迁移到云上 ECS迁移完成后由压测人员用配套的 JMeter 脚本做高并发测试验证云上环境的承载能力。这种迁移场景在真实工作中很常见小项目先在单节点 K8s 上跑业务量上来或需要更高稳定性时迁到云环境迁移完必须重新压测验证容量和稳定性。7.2 JMeter 报告里的关键指标怎么读JMeter 里线程数代表并发用户数Ramp-up Period 表示从第一个线程启动到全部线程启动的时间循环次数决定每个线程执行多少次请求。压测不是一把梭要从 50 并发逐步加压观察 TPS 的拐点在哪。看报告重点看四个指标ThroughputTPS、平均响应时间、90% 或 99% Line、错误率。其中 99% Line 比平均值更能反映真实体验因为平均值容易被极少数长尾请求拉低。如果一条链路在 2000 QPS 时 99% Line 已经超过 500ms说明系统已经接近瓶颈继续加压没有意义。任务类型经验配置适用说明计算密集型CPU 核数 1线程基本不阻塞多留 1 到 2 个应对偶发停顿IO 密集型CPU 核数 ×1 等待时间/计算时间线程大量等待需要更多线程并发等待 IO有界队列 拒绝策略结合实际容量突发流量下保护系统任务堆满时显式处理7.3 一次库存接口的压测与优化全过程之前帮朋友处理过库存服务压测到 300 并发时 TPS 上不去数据库 CPU 飙高。排查链路后发现问题很明显每个请求都直接查 MySQL 扣库存热点 SKU 的同一行记录被大量 UPDATE 锁竞争拖死。优化分三步走热点库存预热进 Redis用 Lua 脚本原子扣减异步消费者批量落库数据库连接池调大并开启读写分离。优化后同一套 JMeter 脚本下 TPS 从不到 800 提升到 3500 左右。这个案例其实把前面所有知识点串起来了并发容器解决线程安全问题缓存扛读流量Redis 分布式锁和 Lua 保证扣减原子性消息队列削峰保护数据库。7.4 单节点 K8s 环境迁移到云上后的容量评估回到前面提到的迁移场景。迁移到云上之后我建议先跑一次和源环境一致的基线压测记录各服务的响应时间、CPU 和内存水位再和迁移前对比确认云上实例规格是否满足。容量评估不能只看单接口 TPS还要结合 K8s 的 HPA 扩缩容策略Pod 的 requests 和 limits 配置得当压测时观察自动扩容是否及时、节点资源是否够用。压测通过后再逐步切流量不要一次性切换避免雪崩。这一步看着偏运维但面试时聊到高并发能讲清楚这种“迁移 压测 容量评估”的完整链路会让面试官觉得你不是只会写代码而是真的能对系统整体负责。最后说个我自己的体会。这些年面试别人和自己参加面试我发现能把高并发讲明白的人几乎都有过一次真实的压测或者线上故障经历。如果你现在没有这样的经历最快的补课方式就是自己搭一套简单的订单或库存服务用 JMeter 压一压把瓶颈找出来改掉。这个过程完整走一遍你会发现 90% 的面试题已经能用自己话讲清楚了。