一个下单请求在线程池里

1Tomcat Acceptor 和 Poller：接住 1000 个连接

Tomcat 有两个专职线程。Acceptor 只做一件事：在 accept() 上等新连接，来了就交给 Poller。Poller 用一个 epoll 盯住所有连接，哪个连接的请求字节到齐了，就把它交给第 2 站的线程池。

实测 线程转储里："http-nio-18080-Acceptor" RUNNABLE at sun.nio.ch.Net.accept(Native Method)，"http-nio-18080-Poller" RUNNABLE at sun.nio.ch.EPoll.wait(Native Method)

为什么要它连接可能几千个，大多数时间在等数据。让两个线程盯住全部连接，只有真正有活的才占用干活的线程。

往下一层线程、线程状态与上下文切换 · 上一圈：网络 IO 模型、IO 与 NIO 基础

常出的事看线程转储时把 RUNNABLE 当成“在干活”：这两个线程一直是 RUNNABLE，其实正阻塞在本地方法里。Java 的线程状态只看 JVM 这一层，不知道操作系统里它在睡。

2Tomcat 线程池：派给 exec-17

请求被包成一个任务交给 exec 线程池，某个空闲线程（这里叫 exec-17）接下它，从这里一直干到第 11 站。Spring Boot 默认最少 10 个、最多 200 个。Tomcat 的池和 JDK 的 ThreadPoolExecutor 顺序相反：先把线程加到 200，满了才排队。

实测 空闲时 10 个 exec 线程；50 路并发压上来，两次都开到 50 个左右。开 spring.threads.virtual.enabled=true 后，1000 个请求用了 941 个虚拟线程，名字像 VirtualThread[#2256,tomcat-handler-1886]/runnable@ForkJoinPool-1-worker-2。

为什么要它每来一个请求就新建一个平台线程太贵：创建要进内核，每个线程还要预留一块栈（x64 Linux 默认 1 MB，本机 ARM 是 2 MB）；池子让线程反复用。虚拟线程是另一条路：线程本身便宜到每个请求可以新建一个。

往下一层线程池：执行流程、参数、拒绝策略、怎么配 · Spring @Async 与线程池 · 下一圈：怎么配、拒绝策略、动态调参 · 虚拟线程：什么时候用、pinning 的坑（上一圈在 网络 IO 模型）

常出的事200 个线程都卡在一条慢 SQL 上，后面的请求全在队列里排着，接口整体超时，CPU 却很闲。JDK 21 的虚拟线程如果在 synchronized 里阻塞，会钉住（pin）底下的载体线程。

3过滤器：把用户 1024 绑到这个线程上

UserContext 过滤器从请求头读出 X-User: 1024，放进一个 ThreadLocal。之后这个线程上的任何代码调 UserContext.get() 都拿到 1024，不用层层传参。Spring 自己也这么干：RequestContextHolder、事务用的连接（TransactionSynchronizationManager）、日志的 MDC，全是 ThreadLocal。

为什么要它“一个请求从头到尾在同一个线程上跑”是第 2 站给的保证，ThreadLocal 就是把“属于这个请求的东西”挂在线程上。

往下一层ThreadLocal 与内存泄漏 · 结构：HashMap 的亲戚们（ThreadLocalMap 和 0x61c88647）

常出的事放进去忘了在第 11 站清掉。线程回池后去接下一个请求，下一个人没带用户号，读到的就是 1024，订单记到别人头上。

4读库存：两个线程都读到 1

exec-17 执行 SELECT qty，读到 1，够买。它还没来得及写回，就被换下了 CPU（时间片到了，或者在等数据库返回）。这时处理用户 1025 的 exec-23 也来读，读到的还是 1。

为什么会撞2 个 CPU 核上跑着 50 个 exec 线程，线程随时会被切走，切走时停在哪一行没人能保证。“先检查、再执行”这种写法，在单线程里永远对，多线程里检查完的结论随时会过期。

往下一层线程、线程状态与上下文切换 · Java 内存模型：可见性、有序性、happens-before · 下一圈：jcstress、CPU 缓存与伪共享

常出的事开发环境一个人点，永远点不出问题；压测或大促才出现，而且每次超卖的件数都不一样，很难复现。

5写回：后写的盖掉先写的

exec-23 写回 qty = 0，返回“抢到了”。exec-17 回来接着执行，也写回它算好的 qty = 0，也返回“抢到了”。库存只少了 1，卖出了 2 件。这叫丢失更新：每个线程都只看见自己那一份“读、改、写”。

实测 naive 两次卖出 142、151 件；就连全在内存里、只有几条指令的 mem 写法也卖出了 102、101 件。

为什么会撞“读、算、写”是三步，不是原子的。内存版还多一层问题：没有锁、没有 volatile，Java 内存模型不保证一个线程写的值另一个线程什么时候能看到（没有 happens-before）。

往下一层Java 内存模型 · 下一圈：用 jcstress 跑出这一站的超卖 · 修法见第 6、7、8 站

常出的事以为给字段加个 volatile 就好了。volatile 只管“看得见”，管不了“读、改、写”三步中间被插队，照样超卖。

6修法①：synchronized，一次只放一个线程进来

把第 4、5 站的读和写包进 synchronized (lock) { … }。exec-17 拿到锁，exec-23 只能在门外等，等 exec-17 写完、放了锁才进来，这时它读到的是 0。JDK 21 上没有偏向锁了（JDK 15 默认关、18 移除）：没人抢时用 CAS 改对象头就算加锁（轻量级锁），抢的人多了膨胀成重量级锁，抢不到的线程挂起，状态是 BLOCKED。

实测 卖出正好 100 件；采样到最多 47、48 个 exec 线程同时 BLOCKED 在这一把锁上。

为什么要它最直接：把“读、判断、写”变成别人插不进来的一段。ReentrantLock 能做同样的事，还多了超时、可中断、公平和多个条件队列，它建在 AQS 上，等锁的线程是 WAITING 而不是 BLOCKED。

往下一层synchronized 与锁升级、CAS 与原子类 · AQS 与 ReentrantLock、Condition、Semaphore · 下一圈：读写锁、StampedLock 与用 JFR 找锁竞争

常出的事锁只管得住一个 JVM：订单服务部署两台，每台各有一把锁，照样超卖。锁里做慢操作，200 个 exec 线程全堵在门口。

7修法②：CAS，写回时先核对

库存放在 AtomicInteger 里，扣减写成 compareAndSet(1, 0)：“如果现在还是 1，就改成 0”。这是一条 CPU 指令（ARM 上是 LSE 原子指令或 LL/SC），比较和写入之间插不进别人。两个线程都拿着 1 来改，只有一个成功；失败的重新读、再试，读到 0 就返回已抢光。

实测 卖出正好 100 件，CAS 失败重试 0 次：2 核机器上同一瞬间最多两个线程真正在跑，CAS 的窗口又只有一条指令，几乎撞不上。

为什么要它不挂起线程，没有锁的排队和唤醒，竞争不激烈时最快。秒杀里常用它（或 Redis 的原子扣减）做第一道“预扣”，把大部分抢不到的人挡在数据库之外。

往下一层synchronized 与锁升级、CAS 与原子类

常出的事内存里扣成功了，写数据库失败，库存要补回去，不补就少卖。竞争激烈时大量线程原地重试空转 CPU，计数类场景改用 LongAdder。同样只在一个 JVM 里成立。

8修法③：数据库条件更新，判断和扣减放进同一条语句

UPDATE stock SET qty = qty - 1 WHERE sku_id = 88 AND qty >= 1，返回“影响 1 行”才算抢到。InnoDB 执行这条语句时先给这一行加行锁，第二个事务要等第一个提交，再拿最新的 qty 判断条件。J01 全景第 7 站用的就是这个写法。

实测 卖出正好 100 件，第 101 个请求起都是影响 0 行。

为什么要它库存的真相在数据库里，几台应用服务器共用一份。前两种修法管的是一个 JVM 里的线程，它管的是所有连到这个库的事务。

往下一层J06：事务、MVCC 与锁 · J12：抢券的预扣、限流和异步化

常出的事热点行：1000 个请求都排队等同一行的行锁，吞吐被这一行卡死，还可能拖住连接池。量大时先用 CAS 或 Redis 预扣挡掉大部分请求，再落库。

9并发容器：订单放进 ConcurrentHashMap，超时任务进 DelayQueue

抢到的人得到订单 10017。userOrders.computeIfAbsent(1024, …).add(10017)：J01 这里是 HashMap，几十个线程同时放会丢数据，这次换成 ConcurrentHashMap，它只锁住正在改的那个桶。30 分钟不付款就取消的任务放进 DelayQueue，后台线程在 take() 上阻塞着等它到期。

实测 每一轮结束，userOrders 里正好 100 个用户。

为什么要它前面几站解决的是“一个数”的并发，这一站是“一个集合”的并发。容器自己做好线程安全，业务代码就不用自己加锁。

往下一层ConcurrentHashMap 与阻塞队列（阻塞队列的一部分：SynchronousQueue 与 LinkedTransferQueue） · HashMap：哈希、扩容、树化

常出的事以为换成并发容器就万事大吉：先 get 再 put 两次调用之间照样会被插队，要用 computeIfAbsent、merge 这类一步完成的方法。

10CompletableFuture：通知和积分交给别的线程

发短信、加积分不该让用户等，CompletableFuture.runAsync(…) 把它们交出去，exec-17 继续往下走。没传线程池时用公共的 ForkJoinPool.commonPool()，它的大小是 CPU 核数减 1；小于 2 时，CompletableFuture 干脆每个任务新建一个线程。

实测 2 核机器上异步任务跑在 Thread-552（每次新建的线程），在那里调 UserContext.get() 得到 null。

为什么要它把不影响结果的慢事挪出请求线程，exec 线程更早回池，第 2 站的 200 个线程能接更多请求。

往下一层CompletableFuture 与异步编排 · Spring @Async 与线程池

常出的事第 3 站的 ThreadLocal 不会跟着过去：用户号、traceId 到了新线程全是空的。默认池被慢 IO 占满，拖垮别的异步任务；异常没人 join 就悄悄丢了。

11写回、清掉 ThreadLocal、线程回池

exec-17 把 OK 写回连接。过滤器的 finally 里调 USER.remove()，然后线程回到池里，停在任务队列上等下一个请求（WAITING）。请求结束了，线程没有结束，它身上挂的东西也不会自己消失。

为什么要它线程池里的线程活得比请求长得多。第 3 站放进去的东西，必须在同一个请求结束前拿掉。

往下一层ThreadLocal 与内存泄漏：为什么要 remove · 线程池：执行流程 · 优雅关闭

常出的事不 remove()：一是串号，下一个请求读到 1024；二是泄漏，ThreadLocalMap 的 key 是弱引用、value 是强引用，线程不死，value 就一直在堆里。