很多Java程序员会有一种错觉：觉得自己每天在写业务代码，CRUD做得滚瓜烂熟，Spring Boot用得顺手，就算一名合格的“高级开发”了。直到某天面试官问了一句“如果你的接口QPS突然从100涨到10000，系统哪里先扛不住？”，才发现自己脑子里只有“加机器”这三个字。
带项目这些年，我面过不少Java程序员，也带过各种各样的开发人员。我自己的感受是：高并发经验恰恰是筛一个人技术成熟度的试金石。它不是因为你背得下来多少面试题，而是因为它几乎牵扯到Java这门语言最核心的机制，以及一个程序员从“把功能写出来”到“把系统做好”的全部认知差距。
这篇文章不打算给你罗列面试题，也不打算做成某某框架的文档。我想站在一个实际带项目、带人、也踩过各种并发坑的从业者角度，聊聊高并发经验为什么在Java这条职业路上如此重要，以及如果你偏偏不在大厂、没有千万流量，又该怎么把这种经验系统地攒起来。
1. 面试官反复追问高并发，到底在筛选什么能力
1.1 高并发问题的本质：在“不确定”面前掌控全局
很多人把高并发理解成“流量大的时候系统不崩”，这个理解太浅了。并发一旦上来，系统面对的不只是量变大，而是不确定性的急剧放大。线程之间的执行顺序变得不可预测，共享资源上的读写变得难以捉摸，缓存和数据库之间的一致性变得脆弱，网络超时引发的重试导致请求重复堆积。
这才是高并发问题真正难的地方。面试官追着问高并发，往往不是想听你背诵“缓存穿透解决三板斧”，而是想判断一件事：当系统的行为开始失控，你有没有一套成体系的分析方法，能把它重新拉回可控区间。
我举个例子。有一次我们线上做活动，流量比平时涨了大概二十倍。最开始看到的是数据库连接池被打满，慢SQL增多。如果只盯着数据库，你会觉得加连接池大小就行。但顺着链路往上追，发现其实是Redis集群里某个热点key在固定时间点被集中访问，缓存击穿之后，大量请求同一秒涌到数据库。真正的解法不是加连接池，而是给热点key做逻辑过期加互斥重建，在缓存层就把流量挡住。
这就是高并发问题的典型特征：你看到的故障点往往不是根源点，而只是最后崩溃的那一节链条。没有从整体链路上思考问题习惯的人，接到告警的第一反应是重启、扩容、加参数；有并发经验的人会先问：流量是从哪个链路来的？哪一层应该挡却没挡住？瓶颈是计算、存储还是网络？
1.2 从“功能正确”到“并发正确”的认知跃迁
单线程下代码逻辑全对，并发下一跑就出事，这种案例我见过太多。刚工作一两年的时候，我自信满满地写了一个懒加载的单例，觉得双重检查锁都加上了还能有什么问题？结果在并发稍高一点的时候就出现了诡异的现象：有时候拿到的对象是没有初始化完成的半成品。
后来我才意识到，问题出在指令重排序。在Java内存模型里面，new操作不是原子的，分配内存、初始化、赋值这几个步骤可能被重排。我加了synchronized，也做了双重判断，但偏偏漏掉了volatile关键字，导致线程看到的是一个尚未构造完成的对象引用。
这些年带人，我发现自己习以为常的很多“常识”，对没有并发经验的同事来说是完全陌生的思维盲区：
i++不是原子操作，多线程累加一万次结果不等于一万；HashMap在多线程扩容时可能形成环形链表，一旦发生就会让CPU飙到100%；SimpleDateFormat线程不安全，你把它放在静态变量里做日期格式化，低峰期没事，高峰期必定出乱子；- 数据库的行锁只在事务提交或回滚时才释放，一个事务里塞了太多操作，并发一高就会互相等待。
这些不是冷门知识，而是实打实会在生产环境爆雷的问题。你掌握的并发经验越深，越能在写代码的时候就规避掉这些坑，而不是等线上出事故了，再花一个通宵去查是不是有人动了这段代码。
1.3 高并发问题的通用考察模型：场景、方案与权衡
面试中考察高并发，其实有一套隐蔽的通用模型。任何一道并发题都可以拆成三层：考察你对场景的分析能力、对方案的掌握程度、对技术取舍的判断力。
比如面试官问“缓存穿透怎么解决”，初级回答是“加布隆过滤器”，中级回答是“布隆过滤器加空值缓存一起用”，更成熟的回答则应该是：如果这个key是恶意攻击造成的随机Key，布隆过滤器是更稳的防线；如果只是查询不存在的数据，空值缓存反而更简单有效，但要设置合理的过期时间防止缓存堆积；同时还要考虑，这两种方案各自的误判率、内存成本、维护成本是多少，你当前业务更在乎哪个。
再比如“分布式锁用Redis还是ZooKeeper”，如果你只会说“Redis快但可能失效，ZK强一致但慢”，这还停留在知识点阶段。真正的权衡要考虑业务的容忍度：库存扣减这种损失不可接受的操作，能不能接受极端情况下锁失效？如果业务允许偶发重复执行，那么Redis的简单方案就是最优解；如果不允许，你就得接受ZK或者Redis红锁的复杂度。
高并发经验积累到一定程度，你会发现所有问题都没有标准答案，只有合适不合适。这种“方案对比背后的取舍能力”，才是面试官想透过高并发问题看到的真正有价值的东西。
2. 高并发经验背后，是一条完整的Java技术链路
2.1 从JMM说起：为什么并发bug如此难以复现
很多Java程序员对并发感到恐惧，是因为并发问题有极强的不确定性。今天压测通过，明天上线后偶发超时；十次运行九次正常，一次诡异。
要理解这种不确定性，就得回到Java内存模型（JMM）这个基础。JMM规定了主内存和工作内存的交互规则。每个线程都有自己的工作内存，里面保存着主内存变量的副本。线程对变量的所有操作，都必须先在工作内存中进行，然后写回主内存。这个“写回”的时机，是不确定的。
你可以把主内存想象成公司白板上贴的共享排期表，每个线程是自己的笔记本。线程A改了自己本子上的内容，觉得自己改完了，但没往白板上同步；线程B此时看了一眼白板，看到的还是老版本。这就是可见性问题。
Java解决这个问题的手段，主要有volatile和synchronized。volatile的核心语义是：写入时直接刷到主内存，读取时直接从主内存拿，禁止指令重排。它能保证可见性，但不能保证原子性。synchronized则是互斥加内存屏障的双重保障，进入同步块时清空工作内存，退出时把修改刷回主内存。
理解这些基本规则，不是让你去炫技，而是在你排查线上问题时，能快速判断一个现象到底是代码bug、GC停顿、还是并发可见性引起的偶发问题。我见过太多同事遇到偶发性故障就重启了事，过了两周同样的故障再犯，才意识到是并发安全的雷。
2.2 锁的演化：从synchronized到AQS
Java的并发控制，离不开锁。而Java锁机制本身的演化，就是一部浓缩的并发优化史。
早年synchronized被戏称为“重量级锁”，因为它直接依赖操作系统的互斥量，线程一旦争锁失败就要进入内核态阻塞，上下文切换成本极高。为了优化这个痛点，JDK 1.6之后对synchronized进行了一连串升级：无锁状态（偏向锁）→ 轻量级锁（自旋锁）→ 重量级锁。偏向锁假设同一个线程反复获取锁，所以只需要做一次CAS标记；一旦发生竞争，升级为轻量级锁，用自旋等待而不是立刻阻塞线程；自旋超过阈值再膨胀为重量级锁。
这就回答了一个很常见的疑问：为什么现在很多Java面试不再问synchronized和ReentrantLock谁更快，而是问它们在什么场景下适用。synchronized的锁升级机制让它在低竞争时几乎零开销，而ReentrantLock提供了可中断、可超时、公平锁和多个Condition等待队列等精细控制。高并发场景下，超时中断这种能力往往比单纯的性能更重要——总不能让一个线程在锁上永远等下去。
而理解ReentrantLock的核心，绕不开AQS（AbstractQueuedSynchronizer）。AQS用一个volatile的state变量表示同步状态，通过CLH队列管理等待线程，提供了独占和共享两种模式。你平时用的Semaphore、CountDownLatch、ReentrantReadWriteLock，本质都是基于AQS的状态机。看懂了AQS，你再看这些并发工具类，就不再是背用法，而是看它们在什么模式下、以什么方式修改state来达到目的。
2.3 并发容器与线程池：日常开发最频繁的“主战场”
如果说锁是并发编程的底层机制，那么并发容器和线程池就是你每天都在用的主战场。
以ConcurrentHashMap为例，JDK 7版本用的是分段锁，把数据分成多段，每段一把锁，锁竞争被拆分。从JDK 8开始，实现改成了CAS加synchronized锁住链表头节点，锁粒度更细，读操作基本无锁。但代价是，它牺牲了size()方法的实时准确性——在并发写入时，size()只是估算值，不是精确值。很多程序员在代码里依赖这个方法做精确判断，这就容易踩坑。
线程池更是重灾区。ThreadPoolExecutor的七大参数，看似简单，但每个参数之间的配合关系才是真正的考点。
举一个我实际做过的配置：在一个IO密集型的业务服务里，任务主要耗在等数据库查询和外部接口响应上，线程大部分时间在阻塞，CPU利用率不高。理论上核心线程数可以配置成CPU核数的两倍以上，但不能无限放大，因为数据库连接池是有限的。当时我们把核心线程设置为50，最大线程设为100，队列容量用了有界队列500。为什么用有界而不是无界？无界队列会让任务无限堆积，内存先扛不住，而且最大线程数形同虚设。业务高峰期，如果队列也满了，核心线程50个都忙不过来，线程数会扩到100，再满就只有触发拒绝策略。
还有个容易被忽略的坑：JDK自带的Executors.newFixedThreadPool用的无界队列，newCachedThreadPool最大线程数是Integer.MAX_VALUE。如果你直接用这些快捷方法，又没意识到它们的限制，高并发场景下必然踩坑。理解线程池参数之间的制约关系，才是从“会new线程池”到“会设计线程池”的分水岭。
到这里你可能发现了，Java并发这条链路是由JMM、锁、并发容器、线程池一层层堆起来的。每一层单独拿出来都能聊半小时，但它们不是孤立的，而是互相配合的一套体系。高并发经验的价值，正是把这一整套体系在脑子里串成一条线。
3. 真正的高并发经验，藏在系统级的“治理”里
3.1 缓存：99%的读请求不该打到数据库
如果只停留在Java并发API层面，你只能说掌握了“半套”高并发。真正的高并发经验，一定会延伸到系统架构设计，而缓存是第一课。
任何系统，只要读多写少，缓存就是性价比最高的一层。对Java程序员来说，本地缓存（如Caffeine）和分布式缓存（如Redis）的选型本身就很有讲究。本地缓存访问速度最快，但是多实例部署时数据不一致；Redis能统一数据源，但多一次网络IO。我见过很多小团队一上来就全上Redis，结果低频访问的数据也挂在Redis上，白白多了延迟和运维成本。合理的做法是：热点且可容忍短暂不一致的数据放本地缓存，需要全局一致的放Redis，数据量极大又不要求实时的，干脆连缓存都不加，直接走归档表。
缓存面临的三大经典难题，是判断你有没有真实高并发经验的好试金石：
- 缓存穿透：请求一个不存在的数据，每次都穿透到数据库。解法是布隆过滤器拦截明显不存在的key，或者缓存空值并设置短过期时间。
- 缓存击穿：某个热点key在过期瞬间，大量请求同时打到数据库。解法是互斥重建（只让一个线程去查库），或者逻辑过期（不给key设置物理过期时间，而是把过期时间存在value里）。
- 缓存雪崩：大量key同时过期，或者缓存实例宕机，流量直接冲垮数据库。解法是过期时间加随机值打散，以及搭建高可用缓存集群。
光记住这三板斧还不够。缓存和数据库之间的数据一致性，才是实际项目里最闹心的问题。常用的Cache Aside模式是更新数据库后删除缓存，但“先更库还是先删缓存”的顺序错了就会出脏数据。如果你更新的数据恰好是并发写入的热点数据，还需要配合延时双删或消息队列异步删除兜底。所有方案都是“最终一致”的严格与宽松之间的取舍，而高并发经验就体现在：你明知道做不到强一致，也知道业务能接受多久的不一致窗口。
3.2 削峰填谷：消息队列如何拯救被打爆的系统
另一个高并发必备的系统级组件，是消息队列。它的核心价值不是“快”，而是“削峰填谷”，它把瞬间的流量高峰变成一条平滑的曲线，让下游系统按照自己能承受的速度消费。
拿最经典的秒杀场景来说。如果100万人同时抢1000件商品，每个请求都直接去数据库扣库存，数据库一秒钟都撑不住。合理的做法是：在Redis里预先加载库存，请求进来时先走Redis的原子扣减（用Lua脚本保证扣减和判断库存的原子性），扣减成功后再把“生成订单”的消息丢进MQ，由订单服务异步处理真正的落库业务。
这种设计为什么在高并发下成立？因为“扣库存”这个操作被收敛到了Redis这样一个单线程高速处理的地方，而“创建订单”这个相对重操作被延后，通过MQ异步消化。用户看到的是“秒杀成功”，后台订单在几秒或几十秒内陆续生成完毕。
但消息队列用起来，最怕的是消息丢失和重复消费。消息丢了，订单没了，用户付了钱收不到货，这是重大事故。所以你不能只把消息丢进MQ就不管了，需要生产端的confirm机制、服务端的持久化策略、消费端的消费确认三者配合。重复消费就更麻烦，本地消息表、幂等表、业务上的唯一约束（比如订单号）都是常见手段。
我见过不少项目，引入MQ只是为了“异步解耦”这几个概念，却从来没考虑过消息积压的监控、消费失败的重试与死信队列。真正的并发经验不光会用MQ，更会为Message的每一种异常状态设计兜底方案。这就是治理思维和“会用工具”的区别。
3.3 分库分表与限流熔断：数据量和流量失控前的最后防线
缓存挡读请求，MQ削掉峰值流量，但当数据量本身大到单库单表撑不住，或者某个下游依赖已经过载时，你还需要更往后的防线。
分库分表是很多团队拖到最后才做的事，因为它太痛了。一旦做分库分表，你的查询纬度、事务范围、关联查询都会被打破。所以真正的经验判断是：要不要分，什么时候分，怎么分。通常的建议是，先做读写分离，如果还是撑不住，再考虑垂直拆分（按业务模块拆库），最后才是水平拆表。水平拆表的核心难点是路由键选择、分布式ID生成（雪花算法）、跨节点的分页和聚合怎么低成本实现。如果一个系统在日活十万的阶段就考虑分库分表，那大概率是过度设计；但如果你到了日活千万还没考虑，那就是灾难前的麻木。
限流、熔断、降级，则是流量失控前最后一道保护门。单机限流常用的有Guava RateLimiter的令牌桶，分布式限流则用Redis的Lua脚本做固定窗口或滑动窗口计数。我个人比较推荐令牌桶算法，因为它允许一定的突发流量，而固定窗口在整点瞬间容易被打穿。熔断方面，Sentinel或Resilience4j这类组件能帮你在依赖故障时快速失败，而不是让调用方无限等待拖垮自身线程池。降级则是业务层面的智慧：大促时关闭非核心功能，才能保住核心链路。
这套“缓存、削峰、分库分表、限流熔断”的组合拳，就是系统级高并发治理的地基。你对这一层的理解深度，决定了你到底是只会写并发代码的“程序员”，还是能站在全局设计系统的“架构师”。
4. 没有千万级流量，怎么攒出真正的高并发经验
4.1 自己动手搭一个能被轻松打崩的系统
很多在小公司工作的Java程序员常说：“我做的系统一天就几千请求，根本没机会接触高并发。”这句话我完全不认同。高并发经验未必只能从大厂流量里来，你完全可以靠自己在本地或者一台云服务器上，造一个“准高并发”的场景出来。
具体操作路径很简单。买一台2核4G的云服务器，或者直接用你自己的笔记本电脑，装好Nginx、两个Spring Boot实例（端口不同）、MySQL、Redis，再装一个压测工具JMeter或者wrk。然后写一个模拟商品详情页的接口：先查缓存，缓存没有则查数据库，再回填缓存。通过JMeter把线程数拉到五百，观察同一时刻会发生什么。
你大概率会看到以下现象逐步出现：最开始是Redis连接数飙升，然后是线程池活跃数涨到核心线程数上限，任务进入队列排队，紧接着数据库连接池被打满，一部分请求超时，如果你用的默认Tomcat配置，容器自身的线程数也会很快耗尽。整个过程不需要几千万流量，几百个并发线程就能把一个没有做过任何保护的Java服务打得溃不成军。
然后你就可以开始动手优化了。调大线程池合理吗？怎么配置才算合理？Redis改用连接池复用连接能不能缓解？数据库慢SQL加索引后能扛多少并发？把请求链路上每个瓶颈点记下来，做一次压测，改一处，再压测，循环往复。这套完整的“发现瓶颈—定位原因—设计优化—验证效果”的闭环，就是高并发经验本身。
4.2 主动复现经典并发Bug，把“知识点”变成“体感”
读书背下来和亲手踩一遍，感觉完全不同。我在带新人时，会刻意让他们做几类“危险实验”，而且全都是在低并发下就能复现出来的。这些实验做一遍，比看十遍八股文都管用。
- 模拟多线程累加一个int变量，任务数设大，比如一万个线程各加一万次，看看最终结果和理论值差多少。你会直观地感受到原子性问题。
- 模拟
HashMap在多线程put下的表现。JDK 8以下可能出现死循环，JDK 8以上虽然不再死循环，但可能出现数据覆盖和size不准确。亲眼看过一次CPU飙升，你以后就不会在并发代码里乱用HashMap。 - 模拟线程池队列满了之后的拒绝策略。用
AbortPolicy、CallerRunsPolicy、DiscardOldestPolicy分别跑一遍，看看哪些任务丢失了，哪些任务被谁消化了。很多人在面试时能说出四种拒绝策略的名字，但真正遇到生产环境线上任务被丢弃，第一反应不是看拒绝策略，而是一脸懵。 - 模拟消息队列重复投递场景，在消费端不处理幂等的情况下，连续投递两条相同消息，观察数据库出现重复数据的过程。
我特别推荐把这些结论写成笔记。不是抄文档，而是记录“我做了什么操作，线上发生了什么现象，我为什么判断它是由什么原因引起的”。这种记录多了，你会慢慢形成对并发问题的一种条件反射式嗅觉——扫一眼代码和现象，就能大致判断问题出在哪一层。
4.3 在业务系统里主动寻找并发场景，并把它写进简历
很多人觉得，小公司的业务根本没有并发，但其实是他们没有主动去“找”并发。定时任务批量处理用户数据时多个任务实例重复执行算不算并发？一个接口同时被多个上游系统调用，里面还有共享的静态变量算不算并发？导入上千行Excel时，逐行处理太慢，改造成线程池分批处理，算不算并发？报表导出时后台任务太多，把线程资源占满导致前端接口变慢，算不算并发？
这些都算。小公司的系统不是没有并发问题，而是并发问题一直潜伏着，只是被低峰流量掩盖了。你要做的是，主动把这些看起来很平常的场景重新设计一遍：给批处理任务加分布式锁，防止多实例重复执行；把静态的线程不安全的类改成ThreadLocal或线程安全的替代品；把耗时的同步导出改成MQ异步处理，再通过消息通知用户下载链接。
做完之后，还要学会“恰当地表达”这段经验。简历上不要只写一句“熟悉高并发”，而是写清楚这样的事例：“设计并落地了批量任务的多实例互斥方案，利用Redis分布式锁解决了定时任务重复调度问题，压测验证并发200下任务不重复执行。”一行字里包含了场景、方案、技术栈和验证结果，这样比任何空洞的“精通”都有说服力。
面试时如果在高并发方面被追问，也别含糊回避，你可以支支吾吾地说自己没做过。你做过压测、解决过具体问题、读过对应源码，就按实际经历讲。面试官要的往往不是你有多少流量，而是你有没有形成一套分析并发问题的思维框架。这套框架，完全可以靠主动折腾和复盘来建立。
5. 高并发经验在日常工作中的真实价值，远比“面试加分”重要
5.1 线上排障时的链路定位能力，直接决定事故时长
高并发经验最实际的价值，体现在线上事故的处理速度上。同样的报警：CPU使用率飙到100%。没有并发经验的人可能会先重启应用，看能不能“恢复正常”，或者盲目扩容加机器。有经验的人会第一时间拿到线程栈，用jstack看线程都在干什么，是GC线程疯狂回收，还是业务线程陷入死循环或锁等待。
我印象特别深的一次，线上服务偶发卡顿，每次持续几秒后自己恢复。刚开始大家都怀疑是数据库慢SQL，查了半天也没找到问题。后来抓线程栈，发现大量线程卡在ConcurrentHashMap.get方法里，这本身看起来是“读操作”，应该很快才对。顺着这个线索查下去，才发现是代码里把一个computeIfAbsent放在了热点路径上，这个操作带有锁竞争和高昂的重算开销，一旦多个线程同时访问同一个key，就会产生严重阻塞。
那次排查要不是对并发容器实现细节有体感，压根不会往这个方向想。你学过的每一个并发知识点，在生产事故面前都可能成为救命线索。高并发经验带给你的不是某个具体答案，而是一套科学的排查目录。
5.2 容量评估和技术方案评审，需要“预判”能力
有高并发经验的人和没有的人，在做技术方案时一个很明显的差别是：有没有预判能力。没有经验的人设计接口，只考虑功能怎么实现，不考虑这个接口会被多少QPS打、请求体多大、下游依赖的承载上限是多少、万一流量翻倍会不会拖垮数据库。
有经验的人在评审方案时，一定会习惯性地问几个问题：这个接口聚合了几个下游调用，最慢的是哪个？要不要加缓存？如果调用方重试，我们的系统扛不扛得住？数据库连接池预估够不够？这些所谓经验，本质上就是把“流量、容量、耗时、依赖”四个维度内化成了肌肉记忆。
举一个容量评估的例子：假设一个营销活动预计一小时内产生十万用户参与，每个用户平均点击五次，总共五十万次请求，峰值大约是平均值的五倍，也就是每秒约七十QPS。这时候你需要评估的点是：应用服务器的线程池够不够？数据库连接池够不够？如果逻辑里每个请求要查三次数据库，那么数据库接到的其实是每秒两百次以上的查询，单库一般还能扛住，但如果再有缓存穿透，那就悬了。
这种思考和计算，在小流量系统里完全没有必要。但如果没有高并发经验，等你服务的业务真的开始起量时，你根本不知道该从哪里开始评估，最后只能等系统被用户打崩之后再被动补救。到了那个节点，用户口碑损失和市场损失已经发生了。
5.3 高并发经验，决定了Java程序员的技术天花板
如果技术人一辈子只满足于写CRUD，那高并发经验确实看起来不重要。但如果你想往高级开发、技术专家、架构师的方向走，高并发经验很可能就是那道分水岭。
普通的Java开发只需要知道“用@Transactional包起来就能回滚”，但是并发经验会告诉你，事务里如果包含了锁、超时网络调用和消息发送，在高并发下会造成持锁时间过长、分步式事务不一致。普通的开发只需要知道“加个索引查询就快了”，并发经验会告诉你索引也可能失效，执行计划也会选错，还要结合Explain结果调整。
更重要的是，高并发经验会直接影响你在团队里的角色。一个系统要接大流量时，一般不会先讨论功能怎么做，而是先讨论架构怎么做。谁能在此时画出流量链路图，指出瓶颈点，给出缓存和MQ的接入方案，谁就能在技术决策中获得话语权。这种话语权不是靠职位给的，是靠解决问题的实力挣来的。
我在评估团队人员能力时，不会单看一个人会多少框架、背多少源码，而是会看他在一个系统真正面临压力的时候，能不能站出来把问题定位清楚、把方案讲明白、把优化落地到位。有过高并发经验的人，在那种紧张时刻往往更能稳住阵脚，因为他们经历过更糟糕的情况，知道系统崩溃时最该做的是止损，而不是慌。
落到个人成长上，我自己的体会是：高并发经验不是靠背出来的，也不是靠看几篇技术博客就能拥有的，它需要你亲手让一个系统出一次问题，再亲手把它救回来，哪怕这个系统只是你电脑上跑的一个小项目。那种“看着流量打进来、看着系统扛不住、又看着它一点点稳下来”的完整过程，才是训练成熟工程思维最好的方式。
所以如果你还年轻，还在Java这条路上起步，别只是埋头刷题库。给自己设计一个压力场景，亲手写一段并发代码，亲手把它跑崩，再亲手把它调好。这比任何面试宝典都更能拉开你与同龄开发者的差距。
