Jonna轩姐高并发这个词，在Java圈子里几乎天天被念叨。你随便打开一份Java面试题清单，前十页里一定有“你们系统最高并发量多少”“线程池怎么配”“如何防止缓存雪崩”这类问题。网上八股文一抓一大把，但真上过生产环境的人都知道，纸上谈兵和实际扛流量完全是两码事。这篇文章我不打算给你背一遍八股文，而是从我自己做过的几个高并发项目出发，把从架构设计到编码落地、再到线上排查的完整链路拆开讲清楚。文中会涉及真实场景下的参数计算、代码示例和踩坑记录，适合正在准备Java面试的开发者，也适合刚接手高并发系统、想建立整体认知的后端工程师。看完你至少能知道：高并发到底在解决什么问题，常用的技术手段有哪些，以及遇到线上事故时该从哪儿下手。
1. 高并发的本质：先搞清楚我们在解决什么问题
1.1 并发量、QPS、RT的关系
很多人在面试时张口就是“我们系统支持百万并发”，但你再追问一句“百万是QPS还是在线用户数”，对方往往就含糊了。高并发这个概念被用滥了，真正要衡量一个系统的压力，首先得把几个指标摆正。
一句话说明白：QPS（每秒查询数）才是跟系统负载强相关的指标，在线用户数只是看起来吓人，真正同时发请求的人不多。有人用“新建连接数”当并发量，有人用“同时在线人数”当并发量，口径都不一样，很容易得出自欺欺人的结论。我见过一个电商活动，对外宣传“300万人参与”，实际压测下来系统峰值QPS只有8000，这就属于典型的用户数和请求量被混为一谈。
决定QPS承受能力的，是另外两个指标的关系：
- RT（响应时间）：一个请求从发出到收到响应的时间，单位通常用毫秒。
- 并发线程数：同一时刻正在处理的请求数量。
三者之间有一个非常经典的关系式：
并发数 = QPS × RT（秒）
举个生活化的例子。高速收费站一个窗口平均15秒过一辆车，那这个窗口一分钟能过4辆，一小时240辆。收费站就是接口，15秒就是RT，240辆/小时就是QPS。这时候如果你修了一条新路，车流量瞬间涨到480辆/小时，单窗口扛不住，怎么办？要么把窗口改成ETC，让每辆车的通行时间从15秒降到7秒（降低RT），要么多开一个窗口（增加并发通道）。高并发优化的核心思路，本质上就是在这两个方向上做文章。
这个公式在实战中还帮你反推一个很重要的东西：当RT升高时，哪怕QPS不变，系统内部的并发线程数也会飙升。比如QPS是2000，RT从50ms涨到500ms，并发线程数就从100涨到1000。线程数一涨，CPU频繁上下文切换，GC压力变大，系统就进入恶性循环。所以排查高并发问题时，永远先问一句：RT是不是变大了？这是最容易被忽略的起点。
1.2 瓶颈到底在哪一层
高并发系统的问题，从来不是“代码写得不对”这么简单。我在实际项目里排查过无数次故障，最后总结下来，流量一大，瓶颈几乎总是出现在下面几类资源上：
- 数据库：连接数上限是硬门槛，尤其是MySQL默认连接数151，随便一个几百QPS的查询就能打满。
- 网络带宽：接口返回数据量太大，比如一个列表接口返回2MB JSON，并发一高，带宽先崩。
- 磁盘IO：日志写入、文件上传、慢查询导致的大量临时表落盘，都会拖垮整个节点。
- 内存：对象创建过多导致GC频繁，甚至直接OOM，热词里那个
java.lang.OutOfMemoryError就是典型。 - CPU：不是危言耸听，很多高并发服务是CPU先烧到100%，然后线程全部排队。
这五种资源里，数据库往往是最先撑不住的那个，因为磁盘IO和连接数本身就有限。所以架构设计的核心，本质上是“如何让数据库只处理最必要的请求”。缓存、异步、削峰，都是干这件事的。
我先说结论：一个高并发系统的演进路径，通常是单体应用扛不住了，先加缓存；缓存命中率不够，再加消息队列削峰；数据库读写飙高，再做读写分离和分库分表。整个演进过程不是一步到位，而是一步一步被流量逼出来的。别指望设计阶段就做到完美，先把核心链路做对，给未来的扩展留好空间，这才是务实路线。
1.3 “最高并发量”这个面试题到底在问什么
面试时最高频的一个问题：“你们的系统最高并发量是多少？”我第一次被问到的时候，老老实实报了个数字，结果面试官立刻追问：“那这个数字怎么测出来的？当时什么配置？RT是多少？有没有降级策略？”直接把我问愣了。
后来我明白了，面试官不是真的想听一个数字，而是想考察三个维度：
- 你用的指标是否准确（是QPS、并发数，还是用户总量）。
- 你的系统瓶颈在哪（数据库、缓存、带宽，还是应用层代码）。
- 你在高并发下的运维能力（有没有压测过、监控数据、应急预案）。
所以如果你正在准备面试，想好这三个维度的回答，比单纯记一个“我们系统QPS峰值3万”要有说服力得多。反过来，也算给你提个醒：上过线、压过测、扛过事故的人，跟背八股文的人开口就不一样。后面第五部分我会用一套秒杀接口的完整代码，带着你实际压一把，你立刻就有概念了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 高并发架构的四个基本盘
2.1 缓存：把热点数据往前挪
高并发架构里性价比最高的一件事，就是加缓存。Redis也好、本地Caffeine也好，甚至进程内Map也行，本质都是把数据从慢介质挪到快介质里，让请求尽量别打到数据库。
但缓存不是“加一个就完事”，有三个经典问题必须面对，面试和实战都绕不开。
缓存穿透：查询一个不存在的key，请求直接穿过缓存打到数据库。如果有人恶意用一串不存在的ID刷接口，数据库压力瞬间拉满。解法有几种：一是对空值也做缓存，设置较短的过期时间；二是用布隆过滤器，把所有存在的key先存进去，查不到就直接返回。布隆过滤器有一个特点，它判断“不存在”是绝对准确的，判断“存在”有一定的误判率，所以适合用来拦“不在表里”的请求。
缓存击穿：某个热点key的过期时间一到，大量请求瞬间全部打到数据库上重建缓存。解决思路是“只让一个请求回源”，其他请求等结果，这就是传说中的互斥锁（Mutex Key）。另一个办法是不设置过期时间，后台异步更新，让key物理上永远不过期。我实际项目中更推荐后者，因为互斥锁在网络抖动时有可能造成线程阻塞，风险更大。
缓存雪崩：大量key在同一时间段集中过期，或者Redis节点直接挂掉，所有请求瞬间涌向数据库，数据库跟着崩，整个系统螺旋崩溃。防范手段包括：过期时间加随机抖动、用Redis集群保证高可用、做多级缓存兜底（本地缓存扛第一层，Redis扛第二层，数据库扛最后一层）。还有一条很重要的经验：任何核心链路都必须做“降级预案”，比如Redis挂了，直接返回兜底数据，而不是把请求一股脑打到数据库。
缓存还有个容易踩的坑是数据一致性。后文4.3我会专门展开讲，这里先记住一个原则：高并发场景下，优先保证最终一致性，不要为了一个缓存数据去追求强一致，那样成本太高。
2.2 异步：削峰填谷
高并发流量最典型的特征就是“忽高忽低”，可能上午只有100 QPS，凌晨活动一开直接飙到10000 QPS。如果所有请求都同步处理，系统必须按峰值去扩容，平时就是巨大浪费。异步的核心思路，简单说就是“先把活接下来，再慢慢干”。
最常用的载体是消息队列（MQ），比如RocketMQ、Kafka。请求进来后，先往MQ里丢一条消息，然后立刻给客户端返回“处理中”，真正耗时的逻辑消费者慢慢消费。这样系统面对10000 QPS的写入，实际处理的可能是2000 QPS，剩余的在队列里排队，体验上可能只是延迟了几秒，但应用层扛住了。
这方面我最有体感的场景是电商秒杀：下单请求先写消息队列，超时未支付的订单由定时任务扫描处理，订单状态异步更新。还有日志系统，应用把日志发到MQ，ELK集群慢慢消费，不会让日志写入阻塞业务接口。异步化的代价是系统链路变复杂，需要处理消息丢失、重复消费、顺序性等问题，但有经验的架构师都知道，成熟的消息队列配上可靠的重试机制，比让同步请求直接压垮MySQL要划算得多。
2.3 池化：复用一切可以复用的东西
高并发下，频繁创建和销毁对象是性能杀手。数据库连接、HTTP连接、线程，创建成本都很高，池化就是把这些资源提前创建好，放在池子里反复使用。最典型的就是线程池和数据库连接池。
为什么需要线程池？因为线程的创建、销毁是昂贵的操作，涉及操作系统内核调用。如果每次请求都new一个线程，高并发下线程数会爆炸，CPU大量消耗在线程切换上。数据库连接更是如此，MySQL每次建立连接都要经过TCP握手、权限验证，频繁创建连接等于自杀。连接池的意义在于，连接建立好后不关闭，放进池子里等下一个请求复用。
关于线程池的具体参数配置，我在3.1会给出实际计算方法。这里先记住一个方向性问题：池化是所有高并发中间件的底层共性思想，Redis客户端、HttpClient、数据库驱动，全部都在用池化技术。理解了池化，你再看tomcat、druid、jedis的配置，一眼就能明白它们是在解决什么问题。
2.4 扩容：加机器之前先想清楚
高并发另一个方向是“水平扩容”，也就是加机器。但很多人有个误区，以为只要应用是无状态的，加机器就能无限扩。实际上瓶颈往往在状态层：数据库、缓存、会话。加应用机器很容易，瓶颈却在数据库连接数上，数据库连不上了，加十台应用也没用。
所以扩容之前，先想清楚瓶颈在哪层。如果是应用层CPU吃满，加机器有效；如果是数据库连接打满，要么做读写分离，要么分库分表，要么上缓存，光加机器解决不了。这块的经验，我会在4.2展开讲。
3. 搞懂JDK并发工具箱
3.1 线程池参数到底怎么配
Java高并发绕不开线程池，面试八股文里最常问的就是ThreadPoolExecutor的七个参数。但网上背的“CPU密集用N+1，IO密集用2N”只是入门级的粗粒度经验，真实项目中我推荐用一套计算逻辑：
corePoolSize（核心线程数）：常驻存活的工作线程数。推荐设置参考公式是：
- CPU密集型任务：核心线程数 = CPU核数 + 1，因为CPU密集型任务几乎不吃等待，线程再多了只会增加上下文切换。
- IO密集型任务：核心线程数 = CPU核数 × 2，因为IO等待期间CPU是空闲的，可以多塞点线程去执行别的任务。精确一点的公式是
CPU核数 / (1 - 阻塞系数)，阻塞系数一般为0.8~0.9。
maxPoolSize（最大线程数）：线程池允许的最大线程数。一般设置为corePoolSize的2倍左右，但这里有一个很关键的原则：maxPoolSize不是越大越好，如果任务全是CPU密集型的，线程数超过CPU核数后性能不升反降。
workQueue（任务队列）：核心线程全部忙完后再进来的任务，先放队列里排队。推荐使用LinkedBlockingQueue，但要注意容量。我见过很多事故就是队列设置成无界队列，高峰期任务堆积几百万，内存炸掉OOM。生产环境一定要用有界队列，再配合拒绝策略兜底。
拒绝策略的选择：任务满了之后，默认的AbortPolicy直接抛异常，这在高并发线上环境就是事故。建议使用自定义策略：要么把任务丢到Redis里稍后重试，要么写入本地文件等恢复后再补，实在不行直接丢弃最不重要的任务。核心原则是“绝不能因为满了就不明不白地丢任务”。
我实际项目里的一个配置参考：
java复制ThreadPoolExecutor executor = new ThreadPoolExecutor(
8, // corePoolSize：8核机器
16, // maxPoolSize：IO密集型，核心数2倍
60, TimeUnit.SECONDS, // 非核心线程空闲60秒回收
new ArrayBlockingQueue<>(1000), // 有界队列，最多排队1000个任务
new ThreadPoolExecutor.CallerRunsPolicy() // 满了之后调用者线程自己执行
);
为什么用CallerRunsPolicy而不是AbortPolicy？因为前者在队列满了时不会直接抛异常，而是让提交任务的线程自己去执行这个任务，相当于“把压力返还给上游”，至少不会因为线程池拒收导致业务数据丢失。这里也能看出，线程池不是配好就完事，要结合业务的重要程度和容错能力来定制。
3.2 锁的选择：synchronized、ReentrantLock与CAS
高并发下多个线程同时修改共享变量，就会面临线程安全问题，Java里最经典的解决方案是加锁。
synchronized是JVM层面的隐式锁，用起来简单，但从JDK 6开始经过锁升级优化（偏向锁 -> 轻量级锁 -> 重量级锁），在低竞争场景下性能并不差。适合简单的临界区保护。
ReentrantLock是JDK层面的显式锁，能力更强，支持可中断、超时、公平/非公平，但需要手动加锁解锁，容易忘了解锁导致死锁。适合需要高级特性的场景。
还有一个方向是CAS（Compare And Swap），这是无锁操作。它不是用锁来阻塞线程，而是通过CPU指令做“比较并交换”，失败就重试。Java里的AtomicInteger、LongAdder都是基于CAS的，适合高并发下的计数器场景。CAS的缺点是可能出现ABA问题，但在简单计数场景下没影响。记得使用LongAdder而不是AtomicInteger做高频计数，后者在高竞争下CAS自旋开销很大，LongAdder把计数分散到多个cell里，性能能提升一个量级。
实际项目中我的选择原则是：能用原子类解决的问题不用锁；必须用锁就优先synchronized；需要尝试获取锁、超时退出等复杂控制才用ReentrantLock。这样做的好处是代码更简洁，也不容易出死锁。
3.3 ConcurrentHashMap的两个版本
HashMap在多线程下扩容时会形成环形链表，JDK 7那个著名的死循环问题，很多人都听说过。解决办法是用ConcurrentHashMap，但它不同版本实现差异很大。
JDK 7的ConcurrentHashMap用分段锁（Segment）设计，默认16个段，每个段相当于一个小HashMap，写操作只锁段，读操作不加锁，所以并发度是16。JDK 8之后抛弃了分段锁，改用CAS + synchronized，锁粒度细化到单个桶（Bucket），数组里的每个元素就是一把锁，并发度更高，性能更好。
面试经常追问的点：为什么JDK 8改用synchronized而不是ReentrantLock？官方解释是JVM团队对synchronized做了大量优化，锁竞争激烈时，synchronized并不比ReentrantLock差，而且代码更简洁、内存占用更少。这给我们的启示是：不要迷信“高级工具”，Java的synchronized已经足够快，用对位置比用什么工具更重要。
3.4 volatile和JMM：可见性的坑
高并发还有一个隐蔽问题：内存可见性。Java内存模型（JMM）规定，每个线程有自己的工作内存，共享变量会先拷贝到工作内存里操作，写完再刷回主内存。所以一个线程修改了变量，另一个线程不一定能立即看到。volatile关键字的作用就是保证可见性——每次读都强制从主内存读，每次写都强制刷回主内存。
但要注意，volatile只保证可见性，不保证原子性。经典的计数器count++在并发下用volatile修饰，依然会丢数据，因为“读-改-写”不是原子操作。这是面试里最常见的陷阱，也是项目里出现“数据好像丢了”问题的常见原因。
正确的适用场景是：一个线程写、多个线程读的标记位，比如服务开关。想保证线程安全还要靠synchronized、Lock或者原子类。这个地方我建议大家在写代码前先停下来想十秒：这个变量会不会被多个线程同时写？如果会，volatile不够用。
4. 数据库扛不住，怎么破
4.1 索引：解决95%慢查询的手段
高并发场景下，数据库层面最先爆发的问题几乎都是慢SQL。我自己调优的绝大多数案例，最后都落在索引上。索引的原理就是给数据库建目录，避免全表扫描。但索引不是越多越好，每个索引都会增加写入和存储开销，索引太多反而影响插入性能。
几个实战原则：
- 区分度高、查询频繁的列优先建索引，比如用户ID、订单号。
- 联合索引遵守最左前缀原则，查询条件要尽量命中索引的最左列。
- 尽量避免
SELECT *，只查需要的列，减少数据库和网络IO压力。 - 避免在索引列上做函数运算，比如
WHERE DATE(create_time) = '2024-01-01'，这样索引会失效。应该写成WHERE create_time >= '2024-01-01 00:00:00' AND create_time < '2024-01-02 00:00:00'。
面试里经常问的一个问题是“为什么索引能快这么多”，这就要提到B+树。MySQL的InnoDB引擎用的是B+树，它跟二叉树相比层高更矮，比如百万级数据三层就能找到，每次磁盘IO能读更多数据，所以查找效率非常高。理解了这个，你就明白为什么说“建索引是最低成本的性能提升手段”。
4.2 读写分离与分库分表
当数据库的读写压力同时变大，光靠索引已经不够了，就得考虑架构层面拆分。
读写分离：把主库负责写入，多个从库负责读取，通过主从复制同步数据。适用于读多写少的场景，比如内容系统、商品详情页。读写分离的难点在于主从延迟，刚写入的数据立刻去从库查可能查不到，解决思路是“强制路由主库”或“延迟容忍”。
分库分表：当单库数据量超过千万甚至上亿，读写分离也扛不住，就得把数据分散到多个库多张表里。分库分表常见的分片策略有：按ID取模、按时间范围分片、按业务ID哈希。每种策略都有取舍，按时间适合日志型数据，但热点数据会集中在最新表；按ID取模数据分布均匀，但跨表查询麻烦。
分库分表是我眼中高并发架构里最重的手术，一旦做了，查询、事务、分页都变复杂，能不碰就不碰。我的建议是：先做缓存、再读写分离，最后才考虑分库分表。很多团队一上来就分库分表，最后运维成本高得吓人。
4.3 缓存与数据库的一致性
缓存和数据库的双写一致性，是高并发项目里最难踩的坑之一。先说结论：目前生产环境最稳妥的方案是“先更新数据库，再删除缓存”，这个策略也叫Cache Aside Pattern。
为什么不是“先删缓存再更新数据库”？因为如果你先删缓存，此时有个线程读缓存没读到，去数据库把旧数据读了出来写进缓存，然后另一个线程才去更新数据库，那缓存里就一直是脏数据了。反过来“先更新库，再删缓存”，最坏的情况是删缓存失败导致一段时间内数据不一致，但上一次的旧缓存总会被清掉，最终能收敛到一致。
但我必须提醒你，这样还是有极小概率出现不一致：更新数据库成功，删除缓存失败。所以更可靠的方案是用“延迟双删”：更新数据库后，先删一次缓存，等几百毫秒再删一次。如果项目对一致性要求更高，可以考虑订阅数据库binlog，异步消费后删除对应缓存。我个人用的最多的还是“先更新库再删缓存 + 消息队列异步重试删除”，代价低，效果也够用。
4.4 库存扣减的三种可靠方案
高并发项目里，库存扣减是最经典也最能体现功底的功能。电商秒杀、机票预订、演唱会抢票，本质上都是“多个请求争抢同一个数据”。我见过几种方案：
方案一：数据库乐观锁
sql复制UPDATE stock SET stock = stock - 1
WHERE id = 1 AND stock > 0;
关键就在stock > 0这个条件，MySQL本身会锁行，保证并发下只有一个请求能扣减成功。优点是简单，缺点是数据库压力大，不适合超高并发。
方案二：Redis预扣库存
先通过incr/decr在Redis里预热库存，扣减走Redis，最后异步同步回数据库。性能高，但要处理Redis和数据库的最终一致性。注意原子性，用DECR命令本身就保证原子，判断返回值小于0就说明已经卖完了。
方案三：Redis + Lua脚本
在Redis里用Lua脚本把“检查库存、扣减库存”两步合并成一个原子操作。因为Redis的Lua脚本在执行期间不会被其他命令打断，所以天然防超卖。这是目前秒杀场景的主流方案，第五部分我会给出完整代码。
这三个方案是演进关系，从简单到复杂，从“够用”到“抗压”。刚起步的业务用方案一就够了，真正的大促场景才需要方案三。
5. 实战：手写一个秒杀接口
5.1 场景定义与表结构
纸上谈兵没意思，直接来点实战。我们模拟一个商品秒杀场景：1个商品，库存100件，目标是高并发下不超卖、不少卖、响应快。
MySQL表结构：
sql复制CREATE TABLE `product_stock` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`product_id` bigint(20) NOT NULL COMMENT '商品ID',
`stock` int(11) NOT NULL COMMENT '剩余库存',
`version` int(11) NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_product_id` (`product_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
订单表：
sql复制CREATE TABLE `seckill_order` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`order_no` varchar(64) NOT NULL COMMENT '订单号',
`product_id` bigint(20) NOT NULL,
`user_id` bigint(20) NOT NULL,
`status` tinyint(4) NOT NULL DEFAULT 0 COMMENT '0-待支付 1-已支付 2-已取消',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
表结构不复杂，但已经能覆盖秒杀的核心逻辑了。下面先写第一版最直接的做法。
5.2 第一版代码：直接怼数据库
java复制@Service
public class SeckillServiceImpl implements SeckillService {
@Autowired
private JdbcTemplate jdbcTemplate;
@Override
@Transactional(rollbackFor = Exception.class)
public boolean seckill(Long productId, Long userId) {
// 1. 检查库存并扣减
int update = jdbcTemplate.update(
"UPDATE product_stock SET stock = stock - 1 " +
"WHERE product_id = ? AND stock > 0",
productId);
if (update == 0) {
return false; // 库存不足
}
// 2. 生成订单号
String orderNo = "SK" + System.currentTimeMillis() + userId;
jdbcTemplate.update(
"INSERT INTO seckill_order (order_no, product_id, user_id, status) " +
"VALUES (?, ?, ?, 0)",
orderNo, productId, userId);
return true;
}
}
这段代码逻辑上是正确的，利用stock > 0防止超卖。但问题也很明显：每个请求都要操作两次数据库（扣库存 + 写订单），数据库连接数和写压力直接决定系统上限。我在本地测过，200个线程并发压1000个请求，这个接口大概只有300 QPS就撑爆了。原因是MySQL的行锁和事务提交（sync binlog、刷redo log）在高并发下是最大的瓶颈。
5.3 第二版代码：Redis预热+Lua扣减
数据库方案扛不住，优化思路是“把库存扣减这种高频操作放到Redis里做”。Redis单线程模型为什么适合做扣减？因为它天然串行，不会出现并发竞争问题，配合Lua脚本还能把多个操作合并成原子操作。
先准备Lua脚本：
lua复制-- KEYS[1]: 商品库存key
-- KEYS[2]: 已购买用户set
-- ARGV[1]: 商品ID
-- ARGV[2]: 用户ID
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock or stock <= 0 then
return -1
end
-- 判断用户是否重复下单
local existed = redis.call('SISMEMBER', KEYS[2], ARGV[2])
if existed == 1 then
return -2
end
-- 扣减库存
redis.call('DECR', KEYS[1])
-- 记录用户
redis.call('SADD', KEYS[2], ARGV[2])
return 1
Java侧调用：
java复制public boolean seckillByRedis(Long productId, Long userId) {
DefaultRedisScript<Long> script = new DefaultRedisScript<>();
script.setScriptText(SCRIPT);
script.setResultType(Long.class);
List<String> keys = Arrays.asList(
"seckill:stock:" + productId,
"seckill:users:" + productId
);
Long result = redisTemplate.execute(script, keys, productId.toString(), userId.toString());
if (result == null || result != 1) {
return false;
}
// 异步：把订单写入数据库，从数据库里扣减实际库存
sendMqMessage(productId, userId);
return true;
}
这里面的核心就是：扣减库存和判断重复秒杀在Redis里一步完成，Lua脚本保证了原子性。数据库那边的库存更新由MQ异步消费，Redis扣减成功的消息才落库。这样Redis处理2000 QPS完全没压力，数据库只用处理真正的订单数据，压力瞬间小了一个量级。
这版方案我实际压过，压到了2500 QPS才出现瓶颈，瓶颈还是在数据库异步落库环节。想要再往上顶，就得考虑把订单表也分库分表，或者用消息队列做削峰，让数据库落库的速率平缓下来。
5.4 限流与防刷：保命手段
接口能力再强，也必须考虑“直接打爆你”的请求。秒杀场景下，一般用户和脚本抢购是混在一起的，如果没有任何防护，几十万脚本请求能在几秒内打满服务。所以高并发接口一定要做限流和防刷。
限流常用的方案有：
- 计数器法：固定窗口内统计请求数，超过阈值直接拒绝。
- 滑动窗口：把时间窗口分成多个小格子，记录每个格子的请求数，比固定窗口更平缓。
- 令牌桶 / 漏桶：令牌桶允许一定的突发流量，漏桶把请求速率强制削平，适合保护下游系统。
Redis里实现一个最简单的固定窗口限流：
java复制public boolean rateLimit(String key, int maxCount, long windowSeconds) {
long now = System.currentTimeMillis();
String windowKey = key + ":" + (now / (windowSeconds * 1000));
Long count = redisTemplate.opsForValue().increment(windowKey);
if (count != null && count == 1) {
redisTemplate.expire(windowKey, windowSeconds, TimeUnit.SECONDS);
}
return count != null && count <= maxCount;
}
这段代码的缺点是固定窗口在窗口临界点可能放行双倍流量，但胜在简单实用，对大多数场景够用。限流不仅要限用户维度的，还要限IP维度的，防刷的话最好加验证码或者滑块。秒杀场景下面还有一个原则：接口尽量只返回“成功”或“失败”，不要把剩余库存都返回给前端，避免被刷接口拖垮。
6. 常见问题与排查技巧
6.1 线上问题排查套路
我自己的排查思路，从踩过的坑里总结出来的，你可以直接拿来用。
接口突然变慢。第一步不是看代码，而是看RT曲线、线程池活跃线程数、GC耗时。如果GC暂停时间变长了，多半是内存问题；如果线程池活跃线程数飙高，多半是下游IO阻塞，比如数据库慢SQL或Redis超时。
CPU飙升到100%。用top -Hp找到耗CPU的线程，再jstack导出线程栈，看是哪段代码在疯狂执行。最常见的是死循环、正则回溯回溯、或者GC线程本身在疯狂Full GC。
OOM。热词里那个java.lang.OutOfMemoryError我见到过太多次了。排查步骤一般是：先加-XX:+HeapDumpOnOutOfMemoryError参数，等下次OOM时拿到heap dump，再用MAT分析大对象。常见原因：缓存了太多对象没清理、线程池队列无界导致任务积压、大集合没清空。
几个排查工具我平时用下来最顺手的：
jstat：看GC情况，特别是-gcutil参数，可以快速定位是不是GC瓶颈。jstack：看线程状态，BLOCKED和WAITING过多的线程是性能隐患。jmap/MAT：堆内存分析，定位谁占用了大量内存。arthas：阿里开源的在线诊断工具，线上排查神器，尤其是在不能重启生产环境的时候。
6.2 压测踩过的坑
压测是验证高并发系统最直接的手段，但压测本身也有很多坑，写出来给大家避雷。
压测前要预估合理的压力模型。别一上来直接1000并发，先从50并发开始往上加，观察RT和吞吐量的拐点。那个拐点就是系统的真实极限，超过这个点，吞吐量不升反降，这就是过度并发导致的资源竞争。
单机压测不代表集群表现。我之前做过一个活动，单机压测验证通过，上线前全链路压测直接崩了，原因是单机压力被Nginx分担了，数据库连接数却没有做相应的集群级限制。所以压测一定要从入口到数据库全链路模拟，尤其是数据库连接池的上限要算准。
别忽略慢接口对整体的拖累。压测时最容易出现的情况是：核心接口很快，但某个被依赖的慢接口把线程池全部占满，导致核心接口也被阻塞。这就是为什么微服务架构要做隔离，把不同重要级的接口放到不同线程池里，避免互相影响。
最后再分享两个小建议
第一，遇到高并发问题，先复现、再分析，不要猜。我见过太多人上来就怀疑Redis慢、MySQL慢、代码慢，最后发现是网络层的问题。代码里加好指标埋点，让数据告诉你问题在哪，远比你拍脑袋猜准确得多。
第二，不要追求一步到位的架构。有个很朴素的道理：任何系统都可以用四个字来演进——够用就好。流量没到那个量级之前，分库分表、消息队列、微服务拆分这些手段只会增加维护成本。先把单机做到极致，再根据真实的流量数据决定要不要上中间件。这比盲目堆技术栈更能体现一个工程师的水平。希望这篇从指标到架构再到实战代码的梳理，能让你对Java高并发有一个完整的、可落地的认知。如果后续有精力，我还可以把秒杀接口演进到分库分表版本，把订单量级的瓶颈继续往下拆，到时候再分享出来。