1. 先搞清楚Java高并发到底考的是什么1.1 高并发的本质不是人海战术是分流、排队、提速带过不少同事也被很多读者问过同一个问题“我Java基础还行怎么快速上手高并发” 每次我都先反问一句你说的“高并发”是指面试能背出八股文还是线上系统真扛得住大流量这两个目标完全不一样。面试八股文要求你把synchronized和Lock的区别、线程池参数、volatile语义背得滚瓜烂熟但真实的高并发场景是从你代码里的一个锁、一条SQL、一次缓存查询开始一层一层堆出来的。说白了高并发不是某个单独的知识点而是一整张技术地图。这张地图可以画成三层第一层是语言层Java并发编程的基础——线程、锁、内存模型、线程池第二层是组件层缓存、消息队列、连接池、分库分表这些外部设施第三层是架构层负载均衡、服务拆分、限流降级、集群部署。很多新手一上来就冲进第一层背synchronized源码背了一个月问他“你系统QPS多少、RT多少、线程池怎么配的”答不上来。这就是典型的只见树木不见森林。我自己理解的高并发本质就三件事分流、排队、提速。分流是把本来压在一台机器上的流量拆到多台机器排队是当请求量超过系统处理能力时用消息队列、限流把流量先接住避免系统直接被打垮提速是让每一个请求的处理时间更短——更快的算法、更短的SQL、更合理的缓存。Java程序员学高并发学的就是在这三件事里你的代码和组件分别扮演什么角色。1.2 高并发Java程序员必须建立的两个核心指标如果你去问一个资深后端怎么衡量系统高并发能力绕不开两个指标QPS每秒查询数和RT平均响应时间。还有一个隐藏指标是成功率——系统挂了一半请求都超时了QPS再高也没有意义。很多人对QPS没有概念。一个普通的单机Java应用什么都不优化裸跑Spring Boot接口乐观估计也就几百到一千多的QPS加上合理的线程池、缓存、连接池配置单机可以到几千再往上走就得靠集群横向扩展了。但关键是你在面试时说“我做过单机8000 QPS的系统”面试官一定会追问RT是多少线程池多大数据库撑得住吗用的是同步还是异步所以高并发能力的本质其实是在有限资源下通过合理的并发模型和系统设计把QPS、RT、成功率三个指标同时维持在一个可接受的范围。这句话听起来简单做起来难。原因在于这三个指标是互相牵连的RT一旦升高同步模型下线程被占满QPS就会下降成功率就会受影响。学Java高并发学的就是怎么在这三个指标之间做平衡。2. 第一层硬功底并发三大问题与Java内存模型2.1 从一段真实事故说起一个boolean变量引发的逻辑混乱先讲一个我早年间处理过的线上问题。一个订单状态通知服务有个布尔类型的开关变量一个线程负责从消息队列拉数据后重置开关另一个线程负责检查开关来决定要不要发送通知。代码逻辑看着很简单但上线后频繁出现“重置了开关对吧但另一个线程读到的一直是旧值”的情况。这就是典型的可见性问题——一个线程修改了共享变量的值另一个线程看不到。为什么看不到因为Java内存模型JMM规定线程操作变量时不是直接操作主内存而是在自己的工作内存CPU缓存里拷贝一份。线程A改了缓存里的值还没来得及写回主内存线程B读的还是自己缓存里那份旧值。这里我拿生活场景打个比方你和同事合用一个文件柜主内存你们各自办公桌上有一份复印件CPU缓存。同事在他自己的复印件上改了内容没把原件更新你永远看不到他的修改。高并发场景下这种“看不到修改”的问题比“数据算错”更隐蔽——程序不报错但逻辑就是不对。JMM为了解决这个问题定义了 happens-before 规则一个操作“先行发生”于另一个操作那么前者的结果对后者可见。volatile关键字、synchronized、Lock这些工具本质上都是在帮你建立这种“先行发生”的关系。2.2 volatile、synchronized、Lock到底怎么选别再死记硬背了Java并发编程的三个核心工具volatile、synchronized、Lock是面试八股文的重灾区。我见过太多人能把三者区别背得一字不差但实际写代码的时候不知道该用哪个。先说结论吧这是我用了很多年之后的经验只需要保证可见性并且是单次读写的场景——用volatile。典型场景是状态标志位、开关、双检锁里的单例实例引用。需要保证原子性一段代码不能多个线程同时执行——优先用synchronized。它是JVM层面实现的不需要手动释放锁出了异常自动释放不容易出死锁。需要超时控制、可中断、公平锁、多个条件变量这些高级能力——用LockReentrantLock。这三个东西解决的是不同层次的问题。volatile解决的是“看不看得见”synchronized和Lock解决的是“能不能同时执行”。volatile不保证原子性比如count这种“读-改-写”操作用volatile修饰照样并发出错。举个实际场景一个简单的计数器多个线程并发count你用volatile修饰count最后结果还是错的。因为count在字节码层面是三步读取count、加1、写回count。两个线程可能同时读到旧值5都加1都写回6最终结果是6而不是7。这时候必须用synchronized或AtomicInteger。我自己平时的选型逻辑很简单能用synchronized就用synchronized。它简单、可靠、不会忘释放锁。只有明确需要Lock的独有能力时才用Lock。很多人写代码一上来就上ReentrantLock完全没必要还容易埋坑。3. 第二层硬功底线程池最常用也最容易被用错的组件3.1 线程池配置错误线上订单系统是怎么被拖垮的线程池是Java高并发里使用频率最高、也最容易踩坑的组件。有一次帮一个朋友排查问题他们的订单处理服务一到高峰期就疯狂报警CPU不高、内存不高但请求大面积超时。我打开代码一看线程池是这么写的核心线程数200最大线程数200阻塞队列用的是无界的LinkedBlockingQueue。这是线程池最经典的错误用法之一——队列无界。当请求量超过200个线程的处理能力时新任务全部堆积在队列里队列越来越大内存逐渐吃紧更重要的是任务的RT越来越长因为任务在队列里排队等了几十秒才被执行。这时候线程池已经失去了“削峰填谷”的意义——它变成了一个蓄水池把请求全接住但底下的出口太窄水流不出去。用户等了30秒、60秒最后超时体验极差。正确的做法是什么队列一定要有界而且要配合拒绝策略一起考虑。当队列满了、线程也满了新任务怎么办是丢弃、抛异常、还是调用方自己处理这要根据业务场景来定。3.2 五步教你把线程池参数配得明明白白现在聊聊线程池参数到底怎么定。这是面试官最爱问的“线程池参数怎么设计”也是实际开发中最容易糊弄过去的问题。先说结论公式。对于IO密集型任务大部分业务系统的接口都是IO密集型查Redis、查MySQL、调远程接口线程数可以这么估算最小线程数 CPU核心数 1最佳线程数 CPU核心数 × 2 1或者更精确一点线程数 CPU核心数 × (1 平均等待时间 / 平均计算时间)这个公式里的“等待时间/计算时间”很难精确拿到所以我更推荐用另一个思路来推导用QPS和RT推算。假设系统目标QPS是1000平均RT是200ms0.2秒。一个线程在200ms内可以处理一个请求那么一个线程1秒钟可以处理5个请求1000ms / 200ms。要支撑1000 QPS需要多少线程1000 / 5 200个线程。这就是线程池大小的第一版估算值但注意这只是理论下限。实际情况中线程切换有开销、有锁竞争、有GC停顿所以建议在这个基础上乘以1.5到2的冗余系数并且一定要通过压测验证。还有一个参数容易被忽略队列容量。我自己习惯的配法是队列容量 maxQPS × RT × 容忍排队时间系数。比如高峰期瞬时流量到2000 QPSRT 200ms我不希望请求排队超过1秒那么队列里最多积压 2000 × 1 2000个任务。超过这个数直接走拒绝策略。拒绝策略也要选择CallerRunsPolicy让提交任务的线程自己执行适合对数据不能丢且能接受RT短暂升高的场景DiscardOldestPolicy丢弃最旧任务适合实时性要求高、旧任务没意义的数据推送场景。具体用哪个一定要结合业务损失来评估。4. 第三层硬功底缓存和数据库高并发的决胜场4.1 缓存穿透、击穿、雪崩三个名字像原因和处理方式完全不一样很多Java开发者学了并发基础、线程池之后觉得高并发已经学得差不多了。但你真去做一个高并发的业务系统很快会碰到另一个层面的问题——缓存。缓存用得好系统可以轻松扛住大流量用得不好Redis一挂数据库直接被压垮。这三个经典问题缓存穿透、缓存击穿、缓存雪崩是每个做高并发系统的人必须滚瓜烂熟的缓存穿透查询一个根本不存在的数据。比如查商品ID为-1的商品缓存里没有数据库里也没有每次请求都一路打到数据库。如果黑客用这种方式发起攻击数据库分分钟被打爆。解决思路有两个一是缓存空值把null也缓存起来设置较短的过期时间二是用布隆过滤器在缓存前面拦一道判断这个key是不是一定不存在。缓存击穿某一个热点key在缓存的过期瞬间大量请求同时打到数据库。比如某个爆款商品的详情页缓存正好在高峰期过期了瞬间上万个请求全部穿到数据库。解决思路一是用互斥锁让同一个key只有第一个请求去查数据库其他请求等待二是用逻辑过期key不设置物理过期时间而是在value里存一个逻辑过期时间后台异步刷新。缓存雪崩大量key同时在某个时间点过期或者Redis实例宕机导致所有请求全部打到数据库。解决思路一是过期时间加随机值避免同一时刻大规模过期二是多级缓存本地缓存 分布式缓存即使Redis挂了本地缓存还能扛一阵三是Redis高可用部署从单点变集群。这三个问题的核心思路其实都是别让流量直接打到数据库。数据库是系统里最脆弱的环节高并发设计的本质就是层层设防把流量挡在数据库外面。4.2 MySQL连接池大小和慢SQL数据库是怎么在高并发下崩溃的说一个很多Java程序员容易忽略的点数据库连接池的大小不是越大越好。连接池太小请求排队等连接RT飙升连接池太大数据库本身处理不过来反而因为大量连接切换导致性能下降。PostgreSQL官方文档里有一句经典的话连接池大小设为CPU核心数的2到4倍左右即可不需要几百个连接。我自己在项目里踩过这个坑——把HikariCP的最大连接数设成200结果MySQL CPU飙升连接数一多单次查询反而变慢。更关键的一个坑是慢SQL在高并发下的放大器效应。平时QPS低的时候一条SQL查500ms系统没什么感觉最多请求慢一点。但在高并发下这条SQL会让线程池里所有线程都被占住——每个线程都在等这条500ms的SQL返回线程被占满新请求全部排队系统就挂了。所以做高并发的Java程序员必须练就一项基本功看SQL执行计划能判断一条SQL会不会在大流量下变成灾难。explain看type是不是ALL全表扫描、看rows扫描行数是不是几十万上百万、看有没有走索引。我经常说一句话代码里的每个慢查询在高并发下都是一颗定时炸弹。至于分库分表我的建议是不要一开始就做。分库分表引入了分布式事务、跨库join、主键生成、数据迁移等一堆复杂度不是高并发的第一解决方案。优先走缓存、走读写分离、走索引优化等单库确实撑不住了再考虑分库分表。很多团队是“没学会走就开始跑”最后系统复杂到没人能维护。5. JVM与线上排查高并发场景的保命技能5.1 从“java: outofmemoryerror”说起OOM不是只有一种死法高并发系统跑起来之后你一定会遇到内存问题。Java里最常见的报错之一就是java.lang.OutOfMemoryError但OOM不是一种原因至少分好几种Java heap space堆内存不够。最常见一般是大对象、集合存储数据量太大、或者内存泄漏。GC overhead limit exceededGC一直在回收但回收不掉多少内存系统98%的时间在GC、2%的时间在干活。Metaspace元空间溢出。动态生成类太多比如大量使用CGLIB、反射生成代理类或加载了过多的类。Unable to create new native thread创建新线程失败。线程数超了操作系统的限制或者内存被线程栈占满。我见过一个典型的案例高并发下有一个服务频繁OOM堆dump分析之后发现是某个接口在并发高时创建了大量中间对象且存入了一个静态Map里没有清理Map体积爆炸。这就是典型的内存泄漏——不是一次性把内存用完而是每一个请求泄漏一点点日积月累系统挂掉。排查方式就是堆dump 分析直方图看哪个对象实例数量异常多。5.2 jstack、jmap、jstat三个命令组成线上排查三板斧高并发场景下线上问题一刻都不能等所以我特别建议每个Java程序员把这三个JDK自带的命令练熟它们随时可以救命jstack打印线程栈。用于排查死锁、线程卡住、线程池状态异常。用法是jstack pid thread_dump.txt然后看线程状态——大量线程处于WAITING状态可能是线程池队列没任务大量线程处于BLOCKED可能是锁竞争太剧烈。jmap打印堆内存信息。用于排查内存泄漏、确认对象分布。jmap -histo pid可以看每个类的实例数量和占用空间jmap -dump:formatb,fileheap.hprof pid是导出堆dump。注意jmap在堆特别大的时候会卡顿高并发业务高峰期慎用。jstat看GC情况。jstat -gcutil pid 1000每秒刷新一次看Young GC和Full GC的频率和耗时。如果Full GC非常频繁说明堆可能要炸了或者堆分配不合理。我自己的实战排查节奏一般是这样的先jstack看线程有没有大量阻塞如果有找到锁的代码位置再jstat看GC状态如果GC频繁用jmap导堆dump分析内存占用。这三个命令配合使用多数线上问题都能以最快速度定位到可疑区域。另外Java高并发排查还有一个重要的前提思维先止损再定位。线上系统出了问题第一反应不是查日志而是先把流量摘掉、扩容、重启或降级让系统先恢复然后再慢慢分析。很多新手一上来就急着找问题原因系统一直在报错用户一直在投诉这是大忌。6. 系统级拼图从单机到分布式Java高并发的演进路线6.1 当单机扛不住时流量是怎么一层层被分散掉的学到这里你已经掌握了语言层的并发基础和组件层的缓存、数据库优化。但单机的天花板是有限的。当你把单机优化到极致比如一个Java应用单机跑到几千QPS再往上加流量就必须走向系统层面。高并发系统最经典的分流方式就是分层架构。我画个实际的链路你感受一下用户请求进来首先到Nginx做第一层负载均衡——它把流量按权重分发到后面的多个Java应用实例Java应用实例内部有线程池在并发处理请求每个请求进来先查本地缓存没命中再查RedisRedis还没命中才查数据库数据库层面做了读写分离主库写、从库读一些突发的流量峰值比如双11秒杀系统会引入消息队列——订单请求先进MQ后端服务按照自己的处理能力慢慢消费实现削峰填谷。这套链路里Java程序员的角色从“写业务代码”变成了“设计系统里每个环节的容量和容错”。Nginx配多少个worker进程、Java应用部署几个实例、每个实例线程池多大、Redis集群几个分片、MQ消费者几个、数据库连接池多大——这些参数的配合决定系统扛得住多大的并发。这就是为什么我说高并发不是单一知识点而是一整套系统设计能力。6.2 一个真实的演进路径从“单机扛所有”到“排队 分流”给大家一个具体的演进案例是我曾经参与过的一个电商促销活动系统的改造路径。第一版系统很简单一个Spring Boot应用连一个MySQL所有请求直连。上线后日均QPS也就一两百没出过什么大问题。第一次大促预热时流量突然飙到1500 QPS系统直接撑不住了——数据库连接池被打满接口RT从50ms飙升到5秒大量请求超时。第一轮改造先上了Redis缓存。商品详情、库存信息这些热点数据全部缓存化数据库的读压力大幅下降。同时加了线程池调优接口里能并行调用的逻辑全部改异步并行。改造后单机QPS从1500提升到了3000多。第二轮改造当时预估大促峰值会到8000 QPS单机已经撑不住了。于是加了Nginx负载均衡 两台应用服务器水平扩展到了6000多QPS。但数据库又成了瓶颈——大量写请求全部打到主库。这时候引入了MQ把下单请求先写入消息队列后端Order服务异步消费落库数据库的瞬时压力被削平了。这个演进路径非常典型单机优化 → 加缓存 → 水平扩容 → 削峰填谷。每一步都是在解决当前系统最明显的瓶颈而不是一上来就上全套微服务。这也是我最想跟Java程序员说的高并发架构是一步步“被逼”出来的不是照着什么终极架构图堆出来的。6.3 给Java程序员的实操学习路线按顺序走少走半年弯路最后分享一下我带人的学习路线完全按实操顺序排你可以直接照着走。第一步先把Java并发基础打牢。重点不是背八股文而是动手写代码验证。自己写一个多线程累加的程序跑一遍观察结果为什么不对再用synchronized、Lock、AtomicInteger分别修看结果差异。再写一个生产者消费者模型手写实现阻塞队列理解wait/notify和Condition。第二步把线程池彻底吃透。不要只看参数含义要自己写测试代码用不同参数组合跑任务观察队列积压、拒绝策略触发、线程池状态变化。最有效的方式是写一个压测脚本用JMeter或自己写个多线程客户端打一个固定QPS的接口看系统在什么参数下表现最优。第三步实际项目中把缓存和连接池用起来。找自己负责的系统给热点接口加Redis缓存看执行计划优化慢SQL把连接池参数调小观察系统行为变化。这个过程会让你真正理解“高并发代码不是写出来的是压测压出来的”。第四步学线上排查。把jstack、jmap、jstat三个命令用熟练。找一个测试环境人为制造一个死锁或内存泄漏用命令定位问题练到能快速找到问题代码为止。最后说一句关于面试的。现在很多Java面试都会问“你做过什么高并发项目”面试官真正想听的不是你会背多少并发概念而是你如何发现瓶颈、如何量化指标、如何验证方案。面对这类问题你最好能讲一个真实的故事系统当时QPS多少遇到什么问题通过什么手段解决了前后数据对比是什么。这才是高并发能力的真正证明。我个人在实际带项目时体会最深的一点是高并发能力不是背出来的是压测和故障压出来的。Java并发编程的理论就那么多但每一个线上事故教给你的经验都比看十篇文档更深刻。所以如果你真想快速上手高并发别光看书找一个自己负责的系统给它增加QPS把它压垮然后把它救回来——这个过程走一遍你就真的入门了。
Java高并发实战：从并发原理到线程池与缓存优化
1. 先搞清楚Java高并发到底考的是什么1.1 高并发的本质不是人海战术是分流、排队、提速带过不少同事也被很多读者问过同一个问题“我Java基础还行怎么快速上手高并发” 每次我都先反问一句你说的“高并发”是指面试能背出八股文还是线上系统真扛得住大流量这两个目标完全不一样。面试八股文要求你把synchronized和Lock的区别、线程池参数、volatile语义背得滚瓜烂熟但真实的高并发场景是从你代码里的一个锁、一条SQL、一次缓存查询开始一层一层堆出来的。说白了高并发不是某个单独的知识点而是一整张技术地图。这张地图可以画成三层第一层是语言层Java并发编程的基础——线程、锁、内存模型、线程池第二层是组件层缓存、消息队列、连接池、分库分表这些外部设施第三层是架构层负载均衡、服务拆分、限流降级、集群部署。很多新手一上来就冲进第一层背synchronized源码背了一个月问他“你系统QPS多少、RT多少、线程池怎么配的”答不上来。这就是典型的只见树木不见森林。我自己理解的高并发本质就三件事分流、排队、提速。分流是把本来压在一台机器上的流量拆到多台机器排队是当请求量超过系统处理能力时用消息队列、限流把流量先接住避免系统直接被打垮提速是让每一个请求的处理时间更短——更快的算法、更短的SQL、更合理的缓存。Java程序员学高并发学的就是在这三件事里你的代码和组件分别扮演什么角色。1.2 高并发Java程序员必须建立的两个核心指标如果你去问一个资深后端怎么衡量系统高并发能力绕不开两个指标QPS每秒查询数和RT平均响应时间。还有一个隐藏指标是成功率——系统挂了一半请求都超时了QPS再高也没有意义。很多人对QPS没有概念。一个普通的单机Java应用什么都不优化裸跑Spring Boot接口乐观估计也就几百到一千多的QPS加上合理的线程池、缓存、连接池配置单机可以到几千再往上走就得靠集群横向扩展了。但关键是你在面试时说“我做过单机8000 QPS的系统”面试官一定会追问RT是多少线程池多大数据库撑得住吗用的是同步还是异步所以高并发能力的本质其实是在有限资源下通过合理的并发模型和系统设计把QPS、RT、成功率三个指标同时维持在一个可接受的范围。这句话听起来简单做起来难。原因在于这三个指标是互相牵连的RT一旦升高同步模型下线程被占满QPS就会下降成功率就会受影响。学Java高并发学的就是怎么在这三个指标之间做平衡。2. 第一层硬功底并发三大问题与Java内存模型2.1 从一段真实事故说起一个boolean变量引发的逻辑混乱先讲一个我早年间处理过的线上问题。一个订单状态通知服务有个布尔类型的开关变量一个线程负责从消息队列拉数据后重置开关另一个线程负责检查开关来决定要不要发送通知。代码逻辑看着很简单但上线后频繁出现“重置了开关对吧但另一个线程读到的一直是旧值”的情况。这就是典型的可见性问题——一个线程修改了共享变量的值另一个线程看不到。为什么看不到因为Java内存模型JMM规定线程操作变量时不是直接操作主内存而是在自己的工作内存CPU缓存里拷贝一份。线程A改了缓存里的值还没来得及写回主内存线程B读的还是自己缓存里那份旧值。这里我拿生活场景打个比方你和同事合用一个文件柜主内存你们各自办公桌上有一份复印件CPU缓存。同事在他自己的复印件上改了内容没把原件更新你永远看不到他的修改。高并发场景下这种“看不到修改”的问题比“数据算错”更隐蔽——程序不报错但逻辑就是不对。JMM为了解决这个问题定义了 happens-before 规则一个操作“先行发生”于另一个操作那么前者的结果对后者可见。volatile关键字、synchronized、Lock这些工具本质上都是在帮你建立这种“先行发生”的关系。2.2 volatile、synchronized、Lock到底怎么选别再死记硬背了Java并发编程的三个核心工具volatile、synchronized、Lock是面试八股文的重灾区。我见过太多人能把三者区别背得一字不差但实际写代码的时候不知道该用哪个。先说结论吧这是我用了很多年之后的经验只需要保证可见性并且是单次读写的场景——用volatile。典型场景是状态标志位、开关、双检锁里的单例实例引用。需要保证原子性一段代码不能多个线程同时执行——优先用synchronized。它是JVM层面实现的不需要手动释放锁出了异常自动释放不容易出死锁。需要超时控制、可中断、公平锁、多个条件变量这些高级能力——用LockReentrantLock。这三个东西解决的是不同层次的问题。volatile解决的是“看不看得见”synchronized和Lock解决的是“能不能同时执行”。volatile不保证原子性比如count这种“读-改-写”操作用volatile修饰照样并发出错。举个实际场景一个简单的计数器多个线程并发count你用volatile修饰count最后结果还是错的。因为count在字节码层面是三步读取count、加1、写回count。两个线程可能同时读到旧值5都加1都写回6最终结果是6而不是7。这时候必须用synchronized或AtomicInteger。我自己平时的选型逻辑很简单能用synchronized就用synchronized。它简单、可靠、不会忘释放锁。只有明确需要Lock的独有能力时才用Lock。很多人写代码一上来就上ReentrantLock完全没必要还容易埋坑。3. 第二层硬功底线程池最常用也最容易被用错的组件3.1 线程池配置错误线上订单系统是怎么被拖垮的线程池是Java高并发里使用频率最高、也最容易踩坑的组件。有一次帮一个朋友排查问题他们的订单处理服务一到高峰期就疯狂报警CPU不高、内存不高但请求大面积超时。我打开代码一看线程池是这么写的核心线程数200最大线程数200阻塞队列用的是无界的LinkedBlockingQueue。这是线程池最经典的错误用法之一——队列无界。当请求量超过200个线程的处理能力时新任务全部堆积在队列里队列越来越大内存逐渐吃紧更重要的是任务的RT越来越长因为任务在队列里排队等了几十秒才被执行。这时候线程池已经失去了“削峰填谷”的意义——它变成了一个蓄水池把请求全接住但底下的出口太窄水流不出去。用户等了30秒、60秒最后超时体验极差。正确的做法是什么队列一定要有界而且要配合拒绝策略一起考虑。当队列满了、线程也满了新任务怎么办是丢弃、抛异常、还是调用方自己处理这要根据业务场景来定。3.2 五步教你把线程池参数配得明明白白现在聊聊线程池参数到底怎么定。这是面试官最爱问的“线程池参数怎么设计”也是实际开发中最容易糊弄过去的问题。先说结论公式。对于IO密集型任务大部分业务系统的接口都是IO密集型查Redis、查MySQL、调远程接口线程数可以这么估算最小线程数 CPU核心数 1最佳线程数 CPU核心数 × 2 1或者更精确一点线程数 CPU核心数 × (1 平均等待时间 / 平均计算时间)这个公式里的“等待时间/计算时间”很难精确拿到所以我更推荐用另一个思路来推导用QPS和RT推算。假设系统目标QPS是1000平均RT是200ms0.2秒。一个线程在200ms内可以处理一个请求那么一个线程1秒钟可以处理5个请求1000ms / 200ms。要支撑1000 QPS需要多少线程1000 / 5 200个线程。这就是线程池大小的第一版估算值但注意这只是理论下限。实际情况中线程切换有开销、有锁竞争、有GC停顿所以建议在这个基础上乘以1.5到2的冗余系数并且一定要通过压测验证。还有一个参数容易被忽略队列容量。我自己习惯的配法是队列容量 maxQPS × RT × 容忍排队时间系数。比如高峰期瞬时流量到2000 QPSRT 200ms我不希望请求排队超过1秒那么队列里最多积压 2000 × 1 2000个任务。超过这个数直接走拒绝策略。拒绝策略也要选择CallerRunsPolicy让提交任务的线程自己执行适合对数据不能丢且能接受RT短暂升高的场景DiscardOldestPolicy丢弃最旧任务适合实时性要求高、旧任务没意义的数据推送场景。具体用哪个一定要结合业务损失来评估。4. 第三层硬功底缓存和数据库高并发的决胜场4.1 缓存穿透、击穿、雪崩三个名字像原因和处理方式完全不一样很多Java开发者学了并发基础、线程池之后觉得高并发已经学得差不多了。但你真去做一个高并发的业务系统很快会碰到另一个层面的问题——缓存。缓存用得好系统可以轻松扛住大流量用得不好Redis一挂数据库直接被压垮。这三个经典问题缓存穿透、缓存击穿、缓存雪崩是每个做高并发系统的人必须滚瓜烂熟的缓存穿透查询一个根本不存在的数据。比如查商品ID为-1的商品缓存里没有数据库里也没有每次请求都一路打到数据库。如果黑客用这种方式发起攻击数据库分分钟被打爆。解决思路有两个一是缓存空值把null也缓存起来设置较短的过期时间二是用布隆过滤器在缓存前面拦一道判断这个key是不是一定不存在。缓存击穿某一个热点key在缓存的过期瞬间大量请求同时打到数据库。比如某个爆款商品的详情页缓存正好在高峰期过期了瞬间上万个请求全部穿到数据库。解决思路一是用互斥锁让同一个key只有第一个请求去查数据库其他请求等待二是用逻辑过期key不设置物理过期时间而是在value里存一个逻辑过期时间后台异步刷新。缓存雪崩大量key同时在某个时间点过期或者Redis实例宕机导致所有请求全部打到数据库。解决思路一是过期时间加随机值避免同一时刻大规模过期二是多级缓存本地缓存 分布式缓存即使Redis挂了本地缓存还能扛一阵三是Redis高可用部署从单点变集群。这三个问题的核心思路其实都是别让流量直接打到数据库。数据库是系统里最脆弱的环节高并发设计的本质就是层层设防把流量挡在数据库外面。4.2 MySQL连接池大小和慢SQL数据库是怎么在高并发下崩溃的说一个很多Java程序员容易忽略的点数据库连接池的大小不是越大越好。连接池太小请求排队等连接RT飙升连接池太大数据库本身处理不过来反而因为大量连接切换导致性能下降。PostgreSQL官方文档里有一句经典的话连接池大小设为CPU核心数的2到4倍左右即可不需要几百个连接。我自己在项目里踩过这个坑——把HikariCP的最大连接数设成200结果MySQL CPU飙升连接数一多单次查询反而变慢。更关键的一个坑是慢SQL在高并发下的放大器效应。平时QPS低的时候一条SQL查500ms系统没什么感觉最多请求慢一点。但在高并发下这条SQL会让线程池里所有线程都被占住——每个线程都在等这条500ms的SQL返回线程被占满新请求全部排队系统就挂了。所以做高并发的Java程序员必须练就一项基本功看SQL执行计划能判断一条SQL会不会在大流量下变成灾难。explain看type是不是ALL全表扫描、看rows扫描行数是不是几十万上百万、看有没有走索引。我经常说一句话代码里的每个慢查询在高并发下都是一颗定时炸弹。至于分库分表我的建议是不要一开始就做。分库分表引入了分布式事务、跨库join、主键生成、数据迁移等一堆复杂度不是高并发的第一解决方案。优先走缓存、走读写分离、走索引优化等单库确实撑不住了再考虑分库分表。很多团队是“没学会走就开始跑”最后系统复杂到没人能维护。5. JVM与线上排查高并发场景的保命技能5.1 从“java: outofmemoryerror”说起OOM不是只有一种死法高并发系统跑起来之后你一定会遇到内存问题。Java里最常见的报错之一就是java.lang.OutOfMemoryError但OOM不是一种原因至少分好几种Java heap space堆内存不够。最常见一般是大对象、集合存储数据量太大、或者内存泄漏。GC overhead limit exceededGC一直在回收但回收不掉多少内存系统98%的时间在GC、2%的时间在干活。Metaspace元空间溢出。动态生成类太多比如大量使用CGLIB、反射生成代理类或加载了过多的类。Unable to create new native thread创建新线程失败。线程数超了操作系统的限制或者内存被线程栈占满。我见过一个典型的案例高并发下有一个服务频繁OOM堆dump分析之后发现是某个接口在并发高时创建了大量中间对象且存入了一个静态Map里没有清理Map体积爆炸。这就是典型的内存泄漏——不是一次性把内存用完而是每一个请求泄漏一点点日积月累系统挂掉。排查方式就是堆dump 分析直方图看哪个对象实例数量异常多。5.2 jstack、jmap、jstat三个命令组成线上排查三板斧高并发场景下线上问题一刻都不能等所以我特别建议每个Java程序员把这三个JDK自带的命令练熟它们随时可以救命jstack打印线程栈。用于排查死锁、线程卡住、线程池状态异常。用法是jstack pid thread_dump.txt然后看线程状态——大量线程处于WAITING状态可能是线程池队列没任务大量线程处于BLOCKED可能是锁竞争太剧烈。jmap打印堆内存信息。用于排查内存泄漏、确认对象分布。jmap -histo pid可以看每个类的实例数量和占用空间jmap -dump:formatb,fileheap.hprof pid是导出堆dump。注意jmap在堆特别大的时候会卡顿高并发业务高峰期慎用。jstat看GC情况。jstat -gcutil pid 1000每秒刷新一次看Young GC和Full GC的频率和耗时。如果Full GC非常频繁说明堆可能要炸了或者堆分配不合理。我自己的实战排查节奏一般是这样的先jstack看线程有没有大量阻塞如果有找到锁的代码位置再jstat看GC状态如果GC频繁用jmap导堆dump分析内存占用。这三个命令配合使用多数线上问题都能以最快速度定位到可疑区域。另外Java高并发排查还有一个重要的前提思维先止损再定位。线上系统出了问题第一反应不是查日志而是先把流量摘掉、扩容、重启或降级让系统先恢复然后再慢慢分析。很多新手一上来就急着找问题原因系统一直在报错用户一直在投诉这是大忌。6. 系统级拼图从单机到分布式Java高并发的演进路线6.1 当单机扛不住时流量是怎么一层层被分散掉的学到这里你已经掌握了语言层的并发基础和组件层的缓存、数据库优化。但单机的天花板是有限的。当你把单机优化到极致比如一个Java应用单机跑到几千QPS再往上加流量就必须走向系统层面。高并发系统最经典的分流方式就是分层架构。我画个实际的链路你感受一下用户请求进来首先到Nginx做第一层负载均衡——它把流量按权重分发到后面的多个Java应用实例Java应用实例内部有线程池在并发处理请求每个请求进来先查本地缓存没命中再查RedisRedis还没命中才查数据库数据库层面做了读写分离主库写、从库读一些突发的流量峰值比如双11秒杀系统会引入消息队列——订单请求先进MQ后端服务按照自己的处理能力慢慢消费实现削峰填谷。这套链路里Java程序员的角色从“写业务代码”变成了“设计系统里每个环节的容量和容错”。Nginx配多少个worker进程、Java应用部署几个实例、每个实例线程池多大、Redis集群几个分片、MQ消费者几个、数据库连接池多大——这些参数的配合决定系统扛得住多大的并发。这就是为什么我说高并发不是单一知识点而是一整套系统设计能力。6.2 一个真实的演进路径从“单机扛所有”到“排队 分流”给大家一个具体的演进案例是我曾经参与过的一个电商促销活动系统的改造路径。第一版系统很简单一个Spring Boot应用连一个MySQL所有请求直连。上线后日均QPS也就一两百没出过什么大问题。第一次大促预热时流量突然飙到1500 QPS系统直接撑不住了——数据库连接池被打满接口RT从50ms飙升到5秒大量请求超时。第一轮改造先上了Redis缓存。商品详情、库存信息这些热点数据全部缓存化数据库的读压力大幅下降。同时加了线程池调优接口里能并行调用的逻辑全部改异步并行。改造后单机QPS从1500提升到了3000多。第二轮改造当时预估大促峰值会到8000 QPS单机已经撑不住了。于是加了Nginx负载均衡 两台应用服务器水平扩展到了6000多QPS。但数据库又成了瓶颈——大量写请求全部打到主库。这时候引入了MQ把下单请求先写入消息队列后端Order服务异步消费落库数据库的瞬时压力被削平了。这个演进路径非常典型单机优化 → 加缓存 → 水平扩容 → 削峰填谷。每一步都是在解决当前系统最明显的瓶颈而不是一上来就上全套微服务。这也是我最想跟Java程序员说的高并发架构是一步步“被逼”出来的不是照着什么终极架构图堆出来的。6.3 给Java程序员的实操学习路线按顺序走少走半年弯路最后分享一下我带人的学习路线完全按实操顺序排你可以直接照着走。第一步先把Java并发基础打牢。重点不是背八股文而是动手写代码验证。自己写一个多线程累加的程序跑一遍观察结果为什么不对再用synchronized、Lock、AtomicInteger分别修看结果差异。再写一个生产者消费者模型手写实现阻塞队列理解wait/notify和Condition。第二步把线程池彻底吃透。不要只看参数含义要自己写测试代码用不同参数组合跑任务观察队列积压、拒绝策略触发、线程池状态变化。最有效的方式是写一个压测脚本用JMeter或自己写个多线程客户端打一个固定QPS的接口看系统在什么参数下表现最优。第三步实际项目中把缓存和连接池用起来。找自己负责的系统给热点接口加Redis缓存看执行计划优化慢SQL把连接池参数调小观察系统行为变化。这个过程会让你真正理解“高并发代码不是写出来的是压测压出来的”。第四步学线上排查。把jstack、jmap、jstat三个命令用熟练。找一个测试环境人为制造一个死锁或内存泄漏用命令定位问题练到能快速找到问题代码为止。最后说一句关于面试的。现在很多Java面试都会问“你做过什么高并发项目”面试官真正想听的不是你会背多少并发概念而是你如何发现瓶颈、如何量化指标、如何验证方案。面对这类问题你最好能讲一个真实的故事系统当时QPS多少遇到什么问题通过什么手段解决了前后数据对比是什么。这才是高并发能力的真正证明。我个人在实际带项目时体会最深的一点是高并发能力不是背出来的是压测和故障压出来的。Java并发编程的理论就那么多但每一个线上事故教给你的经验都比看十篇文档更深刻。所以如果你真想快速上手高并发别光看书找一个自己负责的系统给它增加QPS把它压垮然后把它救回来——这个过程走一遍你就真的入门了。
