线程：一个 Java 线程就是一个内核线程，状态是 JVM 贴的标签，切换是内核做的

• 只有两个线程时，CPU 绝大部分时间在等：每 21 ms 里只算了 1 ms。一个线程一次只能等一件事。
• 线程从 2 个加到 32 个，快了 14 倍；再加到 128 个，几乎没变，因为这时 CPU 已经忙满了。
• 缺的那一块：让“等”的时候把 CPU 让给别人。多个线程各等各的，内核把 CPU 轮流分给此刻有活干的线程。代价是每个线程都要内存，换来换去也要时间。

不懂这一点时的典型误用：接口慢了就把线程池从 200 调到 2000。如果慢在等下游，确实会快一点；如果慢在 CPU 或者锁上，线程越多切换越多、排队越长，反而更慢（⑤ 实验 1、⑥ 坑 3）。

选择规则：日常 Java 后端就是平台线程加线程池；连接很多、大部分时间在等 IO 时考虑虚拟线程或事件循环。后两者都建在平台线程上，所以本页学平台线程：Java 线程、内核线程、状态和切换。虚拟线程是 J02 最后一个知识点，事件循环见 网络 IO 模型。

④-1一个 Java 线程 = 一个内核线程

④-2六种状态：JVM 只告诉你“在 Java 层面等什么”

先在下面这台状态机上走一遍：挑一个动作，看 Java 说它是什么状态、内核说它是什么状态、线程转储里那一行长什么样。

• 1RUNNABLE 不等于在跑。它包括在 CPU 上跑、排队等 CPU、阻塞在本地方法里三种。JVM 看不到本地代码在内核里干什么，只知道“它没在等 Java 的锁或通知”，所以一律标 RUNNABLE。实测 等新连接的 acceptor 线程：Java 说 RUNNABLE，内核说 S，cpu=0.57ms；死循环的 price-calc：两边都是 R，cpu=3226ms。
• 2BLOCKED 只有一个来源：进 synchronized 时锁被别人拿着（包括 wait() 被叫醒后要重新拿回锁）。ReentrantLock、阻塞队列等不到时是 WAITING，因为它们底下用的是 LockSupport.park，不是 synchronized。全景第 6 站那 47 个线程是 BLOCKED，就是因为用了 synchronized。
• 3WAITING 和 TIMED_WAITING 只差一个超时。wait()、join()、park() 不限时；sleep(ms)、wait(ms)、parkNanos 限时。线程转储括号里还会写清是 (on object monitor)、(parking) 还是 (sleeping)。
• 4状态和“持有什么”无关。实测 exec-17 拿着库存锁在里面 sleep，它是 TIMED_WAITING，转储里有一行 - locked <0x…be98>；exec-23 等同一把锁，是 BLOCKED，转储写 - waiting to lock <0x…be98>。按地址就能找到谁卡住了谁。

④-3上下文切换：内核把一个线程换下 CPU，换另一个上来

• 1主动让出多：线程大部分时间在等，看是在等锁（BLOCKED 多不多）还是在等 IO。被抢占多：可运行的线程比核多，CPU 不够分。
• 2实测 两个线程用 park / unpark 来回交接 20 万次，平均一次 3.4～3.9 微秒，几乎每次都是一次主动让出。这就是“叫醒另一个线程干活”的最低代价，也是为什么锁竞争激烈时吞吐会掉。

④-4线程开多少：看一个任务里“等”占多少

④-5线程怎么停：中断是请求，守护线程不等

• 1t.interrupt() 只是把 t 的中断位置成 true。t 正在 sleep、wait、join 时，会抛 InterruptedException 并清掉中断位；在 park 时直接返回，中断位保持 true；在等 synchronized 或者阻塞在传统 Socket 读写时，什么也不发生，接着等。NIO 的可中断通道（InterruptibleChannel）会被关掉，抛 ClosedByInterruptException。
• 2所以停一个线程靠它自己配合：循环里检查 Thread.currentThread().isInterrupted()，捕获 InterruptedException 后要么往上抛，要么调 interrupt() 把中断位补回去。Thread.stop() 会在任意一行把线程打死、锁也来不及好好释放，早就废弃，JDK 20 起直接抛 UnsupportedOperationException。
• 3守护线程（setDaemon(true)）：JVM 只剩守护线程时就退出，不等它们跑完，它们的 finally 也不执行。GC 线程、J01 全景里取消订单的 order-canceller 都是守护线程。

④-6为什么这样设计：1:1，把调度交给内核

决定胜负的约束：当年的关键是阻塞的系统调用和多核，内核线程两样都白给。代价是线程重，于是有了线程池。JDK 21 的虚拟线程又回到 M:N，是因为 JVM 终于把 JDK 里的阻塞 IO 都改造成了“等待时把虚拟线程卸下来”；没改造的地方（JDK 21 里的 synchronized、本地方法）就是 pinning 的坑。

Thread t = new Thread(task, "order-canceller");  // 起名字，转储里才认得出
t.setDaemon(true);                               // 守护线程：JVM 退出不等它
t.start();                                       // 这时才建出内核线程；run() 只是普通方法调用
t.getState();                                    // NEW / RUNNABLE / BLOCKED / WAITING / TIMED_WAITING / TERMINATED
t.interrupt();                                   // 只是请求，见 ④-5
t.join();                                        // 等它结束

# 命令行
jcmd <pid> Thread.print                          # 线程转储（jstack 同样）
grep ctxt /proc/<pid>/task/*/status              # 每个线程的两种切换次数
vmstat 1                                         # cs 列：全机每秒切换次数；r 列：可运行线程数
top -H -p <pid>                                  # 每个线程占多少 CPU

线程栈大小（-Xss）、线程转储在各版本里的格式、调度器的时间片，这些细节放到第⑥步。

// exec-17 拿着库存锁在里面睡；exec-23 也要这把锁
start("exec-17", () -> { synchronized (stockLock) { sleep(60_000); } });
start("exec-23", () -> { synchronized (stockLock) { sink++; } });
// 像 Tomcat 的 Acceptor：等新连接
start("acceptor", () -> server.accept());
// 等支付回调；取消队列 take()
start("pay-waiter", () -> { synchronized (payResult) { payResult.wait(); } });
start("order-canceller", () -> cancelQueue.take());

// 线程名 → 内核线程号：/proc/self/task/*/comm
// 内核状态：/proc/self/task/<tid>/stat 里右括号后面那个字母
for (Thread t : ts)
  System.out.printf("%-18s %-16s %s%n", t.getName(), t.getState(), kernelState(tid));

$ java -cp … States
线程名            Java 状态       内核
order-new         NEW             -（内核里没有）
order-done        TERMINATED      -（内核里没有）
price-calc        RUNNABLE        R
acceptor          RUNNABLE        S
exec-17           TIMED_WAITING   S
exec-23           BLOCKED         S
pay-waiter        WAITING         S
order-canceller   WAITING         S
这个进程在内核里一共有 25 个线程

$ jcmd <pid> Thread.print   （节选）
"acceptor" … cpu=0.57ms … runnable
   java.lang.Thread.State: RUNNABLE
	at sun.nio.ch.Net.accept(Native Method)
"exec-17" … waiting on condition
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	- locked <0x000000075121be98>
"exec-23" … waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
	- waiting to lock <0x000000075121be98>
"pay-waiter" … in Object.wait()
   java.lang.Thread.State: WAITING (on object monitor)
"order-canceller" … waiting on condition
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(Native Method)
"price-calc" … cpu=3226.63ms … runnable

CtxSwitch：四个实验

$ java -cp … CtxSwitch                     （两次运行，取第一次；第二次见 README）
CPU 核数 2，JDK 17.0.20.1
== 1. 纯计算：总量相同（约 2 核 × 1 秒），分给不同个数的线程 ==
线程数   耗时ms   主动让出   被抢占
     2     1025          0       333
     8     1028          9      1180
    64     1160         47      1455
   512     1393         21      1842
== 2. 200 个任务，每个算 1 ms、等 20 ms ==
线程数   耗时ms   理论下限ms
     2     2113       2100
     8      532        525
    32      153        147
   128      150        120
== 3. 两个线程来回交接（park / unpark）==
交接 200000 次，共 773 ms，平均一次 3.9 微秒
两个线程合计：主动让出 179770 次，被抢占 2161 次
== 4. 新建线程 vs 线程池 ==
新建、启动、等它结束一个线程：平均 82.0 微秒
同样的活交给已有线程（提交并等结果）：平均 8.8 微秒

• 1实验 1：纯计算的活，2 个线程（等于核数）最快。512 个线程慢了 36%，被抢占次数涨到 5 倍多：总活不变，多出来的是切换和缓存失效。第二次运行同样是 512 个线程最慢（1399 ms）。
• 2实验 2：等待占大头的活，线程数接近公式给的 42 时最好；128 个线程的下限受 CPU 限制（200 ms 计算 ÷ 2 核 + 20 ms），已经压不下去了。
• 3实验 3 的 3.4～3.9 微秒包含 unpark 的系统调用、唤醒和一次切换；两次运行都是这个量级。实验 4：新建线程比复用贵 9～10 倍，这还没算线程栈占的内存。

• HotSpot 源码里线程状态怎么来的：JavaThreadState 和 java_lang_Thread::threadStatus 的对应
• 用 perf sched、pidstat -w -t 看谁在切、为什么切；async-profiler 的 wall 模式看等待时间（J03、J13）
• CPU 亲和性、taskset 和容器里的 CPU 限额：JVM 以为有 8 个核，其实只能用 2 个
• synchronized 怎么加锁、锁升级，为什么 BLOCKED（J02 下一个知识点之后）
• 虚拟线程：同样的状态和切换，换成 JVM 在用户态做（J02 第 9 个知识点）

自测