你有没有遇到过这种情况写两层 for 循环时交换一下内外层顺序程序运行时间突然差了好几倍两个线程明明在改完全不同的变量性能却互相拖累面试官问“CPU 到底是怎么工作的”你能背出“程序计数器、ALU、寄存器”却解释不了为什么同样的代码在不同机器上表现差异巨大也说不清协程为什么比线程轻。这些现象背后其实都指向同一个主题CPU 底层原理。我见过很多工程师Java 或 Python 写得很熟练但一谈到 CPU 就默认这是硬件领域的事觉得离日常开发太远。事实上CPU 底层原理并没有那么玄乎。它本质上只回答一个问题一条条高级语言指令是如何在纳秒甚至皮秒级别被翻译、调度、计算并写回结果的把这个主线想清楚你收获的不只是面试素材更是一套判断代码性能、并发安全和系统瓶颈的思维方式。这篇文章会用约 10 分钟的阅读时长把 CPU 底层原理的主线完整串一遍从一条指令的执行周期开始讲到指令集与微架构的区分再落到缓存、流水线、分支预测、乱序执行、多核协作最后结合操作系统调度和应用层编程。关键机制都配了可以直接运行的 Java 或命令行示例你可以亲手复现看到 CPU 的行为如何影响程序性能。读完你会明白很多“反直觉”的性能现象也能在面试追问中给出有深度的回答。1. 一条指令的完整旅程CPU 真正在做什么很多人对 CPU 的第一印象是“密密麻麻的晶体管”但真正理解 CPU 不需要从晶体管开始。先把视角放到最高层CPU 是一个不断执行指令的引擎。它做的事情永远是一个循环这个循环在计算机组成原理里叫指令周期具体分成五个阶段。取指CPU 根据程序计数器 PC 记录的内存地址从内存中取出一条指令。译码控制单元识别这条指令的类型和操作数。比如它是一条加法还是跳转。执行ALU算术逻辑单元完成实际运算或者访存单元准备读写内存。访存如果指令需要读内存或写内存这一步会发生数据传递。写回把计算结果写回寄存器或者写入内存。最后更新 PC 指向下一条指令。注意这里的“内存”不只指内存条也包括 CPU 内部的高速缓存。CPU 访问外部内存时需要通过地址总线告诉内存“我要哪个位置”通过数据总线传数据通过控制总线确定读还是写。这也是“存储器与 CPU 的连接”这个经典问题的本质。举个例子你用代码写a b编译之后可能对应一条类似ADD R1, R2, R3的指令把寄存器 R2 和 R3 的值相加结果放到 R1。CPU 的译码器识别这是一条加法指令ALU 完成加法写回阶段更新 R1整个过程就是刚才那五个步骤的微缩版。这背后是冯诺依曼结构“存储程序”的核心思想程序和数据都在内存里CPU 同一套取指-执行循环通过 PC 的变化来驱动程序的流程。循环、函数调用、if 分支最终都翻译成“改变 PC 的取值让 CPU 去执行不同位置的指令”。所以“CPU 是如何思考问题的”这个常见面试题回答的核心就是指令周期加 PC 控制流而不是真的在讲“思考”。这一段的结论是无论 CPU 多先进它最基本的工作仍然是“取指-译码-执行-访存-写回”的循环。所有性能优化都是为了让这个循环运行得更快、更不易中断。2. 指令集架构与微架构程序员看到的 CPU 和硅片上的 CPU很多人把“CPU 架构”挂在嘴边但实际说的是两件不同的事指令集架构ISA和微架构Microarchitecture。搞混这两个概念面试时很容易被追问到细节就卡壳。指令集架构是软件与硬件之间的契约。它定义了 CPU 能识别哪些指令、有哪些寄存器、指令的二进制格式是什么。x86、ARM、RISC-V 都是指令集架构。对 Java 开发者来说同一个.class字节码在不同 ISA 的 CPU 上运行最终被解释或 JIT 编译成不同的本地机器指令但对应用程序而言只要 JVM 足够完整你基本感知不到 ISA 差异。微架构则是芯片内部具体如何实现这个 ISA。同样支持 x86 指令的 Intel 和 AMD 处理器微架构完全不同苹果 M 系列芯片是 ARM ISA但微架构是苹果自研的。微架构决定了一颗 CPU 真正跑得快不快流水线多深、乱序执行窗口多大、缓存容量多少、分支预测器强不强这些都是微架构层面的事。为什么这个区分重要因为指令集代表“兼容边界”微架构代表“性能来源”。你在 X86 平台上编译的程序理论上换一颗同样支持 x86 的 CPU 能继续运行但性能可能天差地别。这就是为什么同主频、同核心数的两颗 CPU实际跑分可能差出百分之几十。往更深处说RISC-V 之所以这几年越来越受关注正是因为 ISA 本身开放、简洁教育资源丰富。很多大学的“一生一芯”项目和计算机组成原理课程都会让学生用 Logisim 搭一个小 CPU比如经典的多周期 MIPS CPU 或简化版 RISC-V。这种教学实践本质上就是在实现一个自定义微架构但指令集可以选 MIPS、RISC-V 或教学自定义 ISA。如果你有空手搓一个小 CPU对“取指-译码-执行”的理解会比读十遍书都扎实。3. 存储层次与局部性CPU 为什么离不开缓存3.1 从寄存器到内存的延迟量级现代 CPU 的运算速度远快于内存访问速度。ALU 做一次加法只需要几个时钟周期而从主存读一个数据可能要几百个周期。如果每次取指令和数据都等内存CPU 绝大多数时间都在空转。这就是所谓的“内存墙”。为了缓解这个问题CPU 引入了多层存储结构。从快到慢、容量从小到大大致是寄存器、L1 缓存、L2 缓存、L3 缓存、主存、磁盘。用生活中能理解的类比寄存器是你手边的草稿纸L1 是办公桌抽屉L2 是旁边的文件柜L3 是整个楼层的资料室主存是外面的供应商仓库磁盘是远洋货运仓库。越靠近 CPU越快也越贵容量越小。大概延迟量级可以参考下面这张表注意不同 CPU 差异很大这里只说明数量级存储层次典型延迟大致容量寄存器约 1 个时钟周期几十到几百字节L1 缓存约 3-5 个时钟周期32KB-64KBL2 缓存约 10-20 个时钟周期256KB-1MBL3 缓存约 30-50 个时钟周期几 MB 到几十 MB主存约 100-300 个时钟周期8GB-64GB磁盘/SSD约微秒到毫秒级数百 GB 到数 TB3.2 局部性原理与缓存行缓存之所以有效靠的是程序执行的两条规律时间局部性和空间局部性。时间局部性指刚访问过的数据很快还会被访问。典型例子就是循环里的计数器变量每轮迭代都要读。空间局部性指访问了一个地址后相邻地址很可能也会被访问。典型例子是遍历数组读完data[i]下一步大概率读data[i1]。缓存不是按字节单独加载的而是按“缓存行”为单位加载常见大小为 64 字节。也就是说当 CPU 读一个int时可能把周围 64 字节一起搬进缓存。数组是连续内存区域遍历数组时 CPU 可以把一整段数据都预加载到缓存里链表节点分散在堆中每次只能等下一个节点地址算出来缓存命中率自然低。这也是“为什么遍历数组比遍历链表快”的底层答案。3.3 实验验证行遍历为什么比列遍历快下面这个 Java 实验非常直观一个4096 x 4096的 int 矩阵行遍历和列遍历的耗时差异巨大。文件CacheLineDemo.javapublic class CacheLineDemo { private static final int SIZE 4096; public static void main(String[] args) { int[][] matrix new int[SIZE][SIZE]; for (int i 0; i SIZE; i) { for (int j 0; j SIZE; j) { matrix[i][j] i j; } } // 预热让 JIT 完成即时编译优化 long warmup 0; for (int i 0; i SIZE; i) { for (int j 0; j SIZE; j) { warmup matrix[i][j]; } } System.out.println(warmup sum warmup); long start System.nanoTime(); long sum 0; // 行遍历按内存连续顺序访问 for (int i 0; i SIZE; i) { for (int j 0; j SIZE; j) { sum matrix[i][j]; } } long rowCost System.nanoTime() - start; System.out.println(row-major cost(ms): rowCost / 1_000_000.0 , sum sum); start System.nanoTime(); sum 0; // 列遍历每次跨整行访问缓存命中很差 for (int j 0; j SIZE; j) { for (int i 0; i SIZE; i) { sum matrix[i][j]; } } long colCost System.nanoTime() - start; System.out.println(column-major cost(ms): colCost / 1_000_000.0 , sum sum); } }运行命令javac CacheLineDemo.java java CacheLineDemo预期结果是行遍历明显更快。因为 Java 二维数组在内存中按行优先存储matrix[0][0]到matrix[0][SIZE-1]是连续地址行遍历时 CPU 的缓存命中率极高列遍历时每个下一次访问都跨过一整行数据缓存里刚加载的数据几乎没有被利用CPU 只能频繁等待主存。如果你机器的缓存特别大或者 SIZE 太小导致整个矩阵都塞进了 L3差异可能不明显可以把 SIZE 调大到 8192 再试。4. 流水线、分支预测与乱序执行CPU 如何偷偷加速在简单模型里CPU 一条接一条执行指令但实际上现代 CPU 会想尽办法并行。这和工厂流水线是一个思路一条汽车生产线不会等一辆车完全组装完再组装下一辆而是把组装分成多个工序前一辆车进入喷漆时后一辆车已经在焊装了。CPU 的指令执行也可以分成取指、译码、执行、访存、写回五级流水线同时有多个指令处于不同阶段。这样做最直观的收益是吞吐量提升。单个加法仍然需要多个周期走完流程但每秒能完成的加法数量大幅增加。代价是流水线中断。一旦遇到跳转指令CPU 不知道下一条该取谁如果等到知道结果再取指令流水线就会空转。于是 CPU 引入了分支预测器根据历史规律猜一猜 if 的结果先按猜的方向取指执行猜对了就赚到时间猜错了就把整条流水线清空重来。这个机制在应用层有一个著名体现排序后的数组比乱序数组遍历更快。原因就是分支预测。下面的实验可以复现这个现象文件BranchPredictionDemo.javaimport java.util.Arrays; import java.util.Random; public class BranchPredictionDemo { public static void main(String[] args) { int size 100_000; int[] data new int[size]; Random random new Random(42); for (int i 0; i size; i) { data[i] random.nextInt(100); } // 先用乱序数组统计 long start System.nanoTime(); long count 0; for (int i 0; i size; i) { if (data[i] 50) { count; } } long randomCost System.nanoTime() - start; System.out.println(random order cost(ms): randomCost / 1_000_000.0 , count count); // 再排序后统计 int[] sorted data.clone(); Arrays.sort(sorted); start System.nanoTime(); count 0; for (int i 0; i size; i) { if (sorted[i] 50) { count; } } long sortedCost System.nanoTime() - start; System.out.println(sorted order cost(ms): sortedCost / 1_000_000.0 , count count); } }运行后你可以看到两者耗时差距。这个例子在网上被称为“分支预测的经典 Demo”它不是什么玄学排序让 50 的判断结果呈现出大量连续的模式分支预测器很快就能猜中乱序数据的判断结果像抛硬币一样预测器经常猜错代价就是反复冲刷流水线。再往后CPU 甚至不满足于“顺序执行”引入了乱序执行。只要指令之间没有数据依赖CPU 可能提前计算后面的指令再在最终结果上“伪装”成按原顺序完成。这给并发编程带来了一个隐含风险你在代码里写的顺序并不一定是 CPU 实际执行的顺序。编译器可能指令重排CPU 也可能乱序执行。所以 Java 里volatile和锁的底层实现都包含内存屏障限制重排并保证多核之间的可见性。Java 内存模型JMM的作用就是把 CPU 层这种“优化造成的不确定性”约束成一个可预测的规则让 Java 程序员不必面对每一种 CPU 的细节。5. 多核协作缓存一致性、伪共享与超线程单核性能再强也有物理瓶颈于是 CPU 走向了多核。多核不是简单地把一个核复制几份它带来了一个严峻问题每个核都有自己的 L1/L2 缓存但内存只有一份。假设两个核同时读到了变量 X 的副本核 A 把 X 改了核 B 缓存里还是旧值那数据就不一致了。为了解决这个问题CPU 使用缓存一致性协议业界常见的思路是 MESI 协议。共四种状态Modified已修改、Exclusive独占、Shared共享、Invalid失效。核 A 修改数据后会在总线上广播消息让其他核把对应缓存行标记为 Invalid核 B 下次访问该数据时发现自己缓存里的副本已经失效必须重新从更上层缓存或主存加载。这套机制保证了正确性但也带来了性能陷阱伪共享。伪共享发生在两个线程操作不同变量但这两个变量恰好落在同一个缓存行里。线程 1 修改变量 a导致线程 2 缓存里的整个缓存行失效线程 2 再去修改 b又导致线程 1 的缓存行失效。两个线程明明无共享数据却因为缓存行冲突反复互相“踢下线”性能急剧下降。这是多核编程里非常隐蔽的问题。下面的实验可以直观看到伪共享的影响。传统 Java 写法里直接用两个 volatile long 字段填充版本则用 7 个无用的 long 把两个变量隔开至少 64 字节。文件FalseSharingDemo.javapublic class FalseSharingDemo { private static final long COUNT 50_000_000L; // 无填充a 和 b 大概率落在同一个缓存行 private static class NoPadding { public volatile long a 0; public volatile long b 0; } // 有填充a 和 b 之间隔开 56 字节大概率分属不同缓存行 private static class WithPadding { public volatile long a 0; public long p1, p2, p3, p4, p5, p6, p7; public volatile long b 0; } public static void main(String[] args) throws Exception { NoPadding no new NoPadding(); Thread t1 new Thread(() - { for (long i 0; i COUNT; i) no.a; }); Thread t2 new Thread(() - { for (long i 0; i COUNT; i) no.b; }); long start System.currentTimeMillis(); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(no padding cost(ms): (System.currentTimeMillis() - start)); WithPadding wp new WithPadding(); Thread t3 new Thread(() - { for (long i 0; i COUNT; i) wp.a; }); Thread t4 new Thread(() - { for (long i 0; i COUNT; i) wp.b; }); start System.currentTimeMillis(); t3.start(); t4.start(); t3.join(); t4.join(); System.out.println(with padding cost(ms): (System.currentTimeMillis() - start)); } }注意运行结果会受 JVM 对象布局和 CPU 缓存行大小影响不同机器差异可能很大但大方向上无填充版本通常更慢而且抖动更明显。你可以在本机多跑几次观察。超线程则是另一种并行手段一个物理核向操作系统暴露两个逻辑核两个线程共享核内的执行单元。当一个线程在等待内存数据时另一个线程可以占用空闲执行资源。理想情况下性能能提升但两个线程同时竞争 ALU、缓存时也会互相拖慢。所以“8 核 16 线程”不代表 16 个全速物理核它只是让资源利用率更高。工程上一个常见误区是“CPU 核数越多程序一定越快”实际要取决于任务是否可拆分、共享数据竞争是否严重、缓存是否够用。6. 操作系统与 CPU 的协作调度、上下文切换与亲和性应用程序并不直接操作 CPU而是通过操作系统把线程映射到逻辑核上。操作系统用时间片轮转的方式给线程分配 CPU一个线程运行一小段时间后操作系统保存它的现场寄存器、程序计数器、栈指针等再加载下一个线程的现场这个过程叫上下文切换。上下文切换是有成本的。切换不仅涉及寄存器保存和恢复还有可能使 TLB页表缓存失效导致下一次访存变慢。如果系统里线程数远大于核数大量时间花在切换而不是业务计算上性能就会明显下降。比如 Java 应用在大量线程阻塞、唤醒时CPU 使用率不高但响应时间很长往往就是切换开销在作祟。理解了这一点再看协程和异步编程就非常清晰。线程切换需要经过内核成本高协程切换发生在用户态把一个执行流的栈和上下文保存在内存里由用户态调度器决定何时恢复不触发内核态切换所以协程比线程轻量得多。Java 的虚拟线程、Go 的 goroutine、JavaScript 的 async await底层思路都有相似之处把一个进程内的执行单元变得更小、更可控用用户态调度替代内核态线程切换。这也是为什么很多高并发服务选择协程模型。具体到应用层你可以通过命令观察和绑定 CPU在 Linux 下# 查看 CPU 型号、物理核、逻辑核数 lscpu # 把 Java 进程绑定到 CPU 0 上运行 taskset -c 0 java CacheLineDemo在 Windows 下传统命令和现代 PowerShell 都可以# 传统命令 wmic cpu get caption, numberofcores, numberoflogicalprocessors # PowerShell 方式 Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, NumberOfLogicalProcessors对性能敏感、要求低延迟的服务通过 CPU 亲和性把线程绑在固定核上可以减少操作系统调度带来的抖动对 CPU 密集型任务设置合理进程优先级如 Linuxnice命令也能改善整体调度效果。生产环境里更常见的做法是在容器或 JVM 参数层面对 CPU 做配额限制避免多实例互相争抢。7. 面试常问 CPU 底层原理串讲与避坑网上搜“CPU 底层原理面试题”可以看到大量零散问题。这里挑几个高频的串起来讲面试问题考察点回答思路CPU 是如何思考问题的指令周期与 PC 机制CPU 按 PC 取指经历取指-译码-执行-访存-写回循环跳转指令改 PCHashMap 底层为什么用数组加链表哈希与缓存局部性数组支持随机访问连续内存对 CPU 缓存友好链表解决哈希冲突为什么 HashMap 容量是 2 的幂位运算替代取模hash (size - 1)代替hash % size一次位运算更高效线程和协程有什么区别上下文切换发生的位置线程切换走内核态协程切换在用户态保存执行栈没有内核陷入多核一定更快吗并发开销与缓存一致性不一定取决于拆分、同步、伪共享、切换开销为什么遍历数组比链表快空间局部性数组连续内存链表节点分散缓存命中率差距大CPU 天梯图怎么看微架构与综合性能不能只看核心数和主频还要看 IPC、缓存、微架构、实际功耗这里要特别解释一下 HashMap 和 CPU 的关系。很多人以为HashMap容量是 2 的幂只是为了“分布均匀”其实它还关系到 CPU 效率用hash (size - 1)代替取模底层是一条位运算指令而且当数组容量是 2 的幂时数据在数组中的映射更有利于缓存行对齐减少伪随机的内存跳跃感。当然哈希冲突概率和加载因子仍然是正确性的关键位运算只是性能层面的一层优化。CPU 天梯图也是大家爱看的热搜词。天梯图本质上是对 CPU 综合性能的粗略排序通常来自跑分汇总。但它不能只按核心数看。一个 4 核 5.0GHz 的高 IPC 处理器在单线程场景可能碾压一个 8 核低主频处理器而服务器 CPU 可能核心很多但主频较低适合并行吞吐不适合低延迟单线程任务。看天梯图时重点看同代架构内比较跨代跨平台对比意义不大。最后是 RISC-V 和多周期 MIPS CPU 设计这类问题。这类题目通常出现在计算机组成原理课程里用 Logisim 搭一个可运行的小 CPU。它考察的不是你会不会写 Verilog而是是否真正理解数据通路程序计数器、指令存储器、寄存器堆、ALU、控制信号是如何连接配合的。如果你能亲手用 Logisim 搭一个能跑简单指令的 MIPS CPU那“CPU 底层原理”的很多疑问会迎刃而解。8. 环境准备与完整实验运行说明本文的三个核心实验都是 Java 程序只要本机能编译运行 Java 就能复现。环境要求不高操作系统Windows、Linux、macOS 均可。JDK 版本建议 JDK 11 或更高版本。旧版本 JDK 8 也能运行但 JIT 行为可能略有差异。运行方式命令行或 IDE 均可。如果想排除 IDE 后台开销推荐命令行。将前面三个 Java 文件保存到同一目录然后执行javac CacheLineDemo.java BranchPredictionDemo.java FalseSharingDemo.java java CacheLineDemo java BranchPredictionDemo java FalseSharingDemo运行结果不会完全一致甚至每台机器跑两次都有波动。想要更稳定的对比可以这样处理增大数据量SIZE从 4096 调到 8192COUNT从 5000 万调到 1 亿。多跑几次JIT 需要预热第一次运行通常偏慢多执行几轮取稳定值。固定 CPU在 Linux 下用taskset -c 0 java XxxDemo避免线程在多个核之间迁移带来的噪声。注意伪共享实验的变量要独立不要用 JDK 自带的某些已经做了缓存行填充的类做基准。判断实验是否成功的标准不是某个具体数值而是趋势行遍历应快于列遍历排序后求和应快于乱序求和填充版本伪共享场景应快于无填充版本。如果你的某一项差异不明显优先加大数据量并对比多次运行不要急着得出“CPU 优化没效果”的结论。9. 常见问题与排查思路问题现象可能原因排查方式解决方案行遍历和列遍历耗时差不多数据量太小矩阵已全部进入缓存查看矩阵占用内存与 L3 容量SIZE调大将SIZE调到 8192 或 16384 后再对比分支预测实验排序后没有变快数组太小JIT 优化掩盖了差异检查循环是否被优化或数组是否进入 L1将 size 调到 10 万以上增加随机范围伪共享实验无填充版本不明显JVM 字段分配不对齐或 JIT 差异多跑几次并加大 COUNT增加循环次数换台 CPU 对比趋势线上 CPU 占用很高但程序不慢存在自旋等待、GC 频繁或空轮询用 JFR、perf 采样看热点方法优化锁、减少长循环自旋、调整 GC 参数IDE 经常卡顿且 CPU 跑满插件索引、误配堆内存、后台编译看任务管理器中的具体进程和线程清理插件索引增大或固定 JVM 内存排查 CPU 温度对性能的影响风扇散热不足导致降频使用sensorsLinux或任务管理器Windows改善散热、清理灰尘、检查降频状态排查 CPU 相关性能问题最忌讳的是只看“CPU 使用率高”就盲目加机器或限流。正确路径是先定位热点代码Java 用 JFR 或 async-profilerC/C 用 perf然后结合我们前面讲的缓存、伪共享、上下文切换、分支预测去分析热点背后的原因。很多时候性能问题的根因并不在算法复杂度而在“程序执行模型”与 CPU 的微观机制不匹配。10. 最佳实践与工程建议理解 CPU 底层原理之后能直接落到工程上的建议是有限的但非常重要。第一把“缓存友好”变成代码习惯。遍历数据时按内存中的存储顺序访问能用数组就不要用链表热点数据结构可以考虑拆分或合并字段让高频访问的字段放在同一个缓存行内减少一次读取需要多次载入的情况。不要为了“抽象”而让热路径上的对象变得支离破碎。第二谨慎设计共享数据。多线程并发修改不同变量并不总是安全的要考虑伪共享的可能性。JDK 里LongAdder就通过分段计数减少竞争Contended注解也能做缓存行填充。但填充不是银弹过度填充浪费内存反而降低缓存利用率。先用 JMH 做基准测试再决定是否使用这类技巧。第三理解并善用并发原语的代价。volatile、CAS、锁都带有内存屏障都会干预 CPU 的重排和缓存一致性。锁竞争严重时代码看起来没做多少事但 CPU 时间全耗在同步上。这时候优先减少锁粒度而不是换一种锁。无锁并发很酷但正确性验证成本高不适合大多数业务场景。第四在性能调优时先测量再优化最后验证。CPU 底层机制提供的是一些“可能性”而不是必然结论。某段代码慢可能因为缓存没命中也可能因为 GC、锁、系统调用。用火焰图或 profiler 打开热点函数对照汇编或机器码分析你会更接近真相。不要只看 CPU 天梯图就断定一台服务器性能不够。第五注意运行环境的 CPU 分配。容器化环境下JVM 默认可能按物理机核数分配线程池导致容器配额不足时线程数过大。生产环境建议确认 CPU 配额与线程池配置匹配必要时用-XX:ActiveProcessorCount限制 JVM 感知的核数。对延迟敏感的服务可以配合 CPU 亲和性减少调度抖动。11. 总结与后续学习方向这篇文章的核心主线可以概括成三个词指令周期、存储层次、并行机制。指令周期让你明白 CPU 最底层的动作是什么存储层次解释了为什么缓存对性能影响如此巨大并行机制则讲述了 CPU 如何通过流水线、分支预测、乱序执行和多核协作把速度推到极限也带来了并发编程需要小心的重排与一致性问题。顺着这条线继续深入我建议走四个方向。第一是系统阅读经典教材比如 CSAPP 的处理器体系结构章节这本书把 CPU、编译、操作系统和程序性能串在一起是性价比很高的学习材料。第二是动手实践用 Logisim 搭一个小 CPU跑通几条指令你会对控制信号和数据通路有真正的体感。第三是学习 RISC-V 指令集它精简开放非常适合作为理解编译器和 CPU 交互的桥梁。第四是回到 Java 并发读 JMM 规范和 JIT 编译相关知识把 volatile、锁、虚拟线程的底层机制和 CPU 行为一一对应起来。建议你收藏这篇文章下次遇到性能问题或面试追问时回到这里检查一遍你写的代码在 CPU 眼里到底是按什么顺序、从哪些存储层读取数据、又在哪里发生了等待和重排。理解 CPU 并不是为了手搓芯片而是为了让你在调优、面试和排查线上问题时能回到程序执行的本质去判断。