很多开发者第一次意识到CPU底层原理需要认真补一补通常不是在学校里读书的时候而是在电脑前盯着一份跑得莫名其妙的程序的时候同一份代码换个机器慢了十几倍看起来差不多的两层for循环交换一下内外层顺序性能差异肉眼可见明明开了8个线程耗时反而不如安静的2个线程。这些现象只用Java、Python、C这种语言层面的知识去解释很容易滑向玄学式的结论——什么底层太复杂编译器太神奇机器有自己的脾气。这篇文章要做的不是把教科书上的英文缩写再抄一遍而是用一台可运行的CPU模型把底层从黑盒变成白盒。我先把结论放在最前面对绝大多数应用层开发者来说CPU底层原理的核心价值不在于将来去设计一颗芯片而在于建立一套程序执行成本模型。有了这套模型你会知道哪一行代码昂贵、哪一个循环会卡、锁到底锁住了什么也会真正理解为什么性能优化要先看工具输出而不是先猜。读完这篇文章你可以回答下面这类问题一行高级语言代码变成CPU指令后到底经历了什么4核8线程为什么不是8倍性能循环访问顺序为什么会影响一个数量级Linux下lscpu、perf stat这些工具的输出究竟在向你汇报什么。1. 为什么每个开发者的知识版图里都应该有CPU底层原理先给一个反直觉的判断CPU底层原理离我们并不远它就在每一次方法调用、每一次循环累加、每一次加锁解锁的背后。如果你只写业务代码也许可以长期不看底层。但一旦进入这三个场景CPU知识就会从锦上添花变成刚需。**场景一性能排查。**线上的接口本来平均50毫秒最近变成800毫秒。代码review了三遍没有发现问题内存和数据库指标都正常。这时候真正能指路的恰恰是CPU的缓存命中率、分支预测失败率、上下文切换次数这些指标。没有底层模型看到这些数字只会觉得是乱码。**场景二并发编程与面试。**网络上的热点词一再出现hashmap底层原理generator/async await底层原理C网络编程底层原理这说明行业已经把底层原理当成衡量程序员水平的重要标尺。而所有底层原理的尽头都是一张CPU与存储器的连接图。HashMap为什么用数组加链表生成器为什么能暂停恢复线程切换为什么贵追根究底都会回到CPU的寄存器、缓存和指令调度。**场景三架构选型。**选择云主机时CPU核数、主频、缓存、是否支持超线程直接决定性能预算。看CPU天梯图不能只看跑分排序还要理解得分背后是什么架构、几代工艺、支持哪些指令集扩展。所以这篇文章不只是写给面试者的更是写给每一个已经发现语言层知识不够用的开发者的。读完你会得到一个自洽的CPU工作模型它足够支撑你日常分析问题又不至于像芯片手册那样劝退。2. CPU从宏观到微观ALU、寄存器与控制单元的三角分工要理解CPU先从三个最基础部件入手算术逻辑单元ALU、寄存器堆Register File、控制单元Control Unit。这三者加在一起构成了经典CPU的骨架。先说一个类比。CPU可以理解成一个自带监督员的流水线车间ALU是车间里真正的工人负责做加减乘除、位运算、比较判断。寄存器堆是工位旁最近的白板空间极小但工人拿取最快。程序员虽然没有直接管理它但编译器在背后一直在帮我们规划这个白板的使用。控制单元是监督员负责读取指令、解释指令、然后指挥ALU和寄存器、内存协同完成指定动作。三个部件的关系可以用一句话概括控制单元负责决定做什么ALU负责实际执行寄存器堆负责刚刚用过并且马上还要用的数据。现代CPU还会包含指令译码器、调度器、乱序执行引擎、TLB页表缓存等大量模块但骨架仍然是这三角分工。无论教科书上的CPU名字听上去多深奥一个理解指令的指挥者 一个干活的运算单元 一片极速暂存区这个框架始终成立。需要特别强调的是寄存器。寄存器是CPU内部速度最快的存储通常以字节为单位计算容量按个计数例如32个64位寄存器大约也就是256个字节。它与内存的根本区别不只是快而是它位于执行单元旁边一条指令可以直接读它、写它。程序里每个局部变量、函数参数、返回地址在某一小段时间内都会映射到寄存器上。当寄存器不够用编译器才被迫把变量溢出spill到内存栈里而这往往就是性能下降的开始。从软件角度看寄存器还是CPU架构里对程序员最可见的部分。x86-64下你能在汇编里直接看到rax、rbx、rsp等名字ARM下你会看到x0到x30。你写的int sum 0看似只是一个局部变量实际对应的是某一条mov指令把0写进某个寄存器后续累加全部在寄存器中完成。3. 一条指令的完整旅程从取指、译码到写回CPU执行一条指令本质上是一套固定节奏的交通流程。经典的五级流水线把这一流程拆成了五个清晰的阶段取指IF、译码ID、执行EX、访存MEM、写回WB。3.1 五个阶段分别干什么先用一句话概括每个阶段取指Instruction FetchCPU通过程序计数器PC拿到下一条指令的地址从这个地址读取指令。取到的原始指令只是一串0和1比如00000000 00000000 00000000。译码Instruction Decode控制单元把0/1串翻译成具体的控制信号。它需要判断这是什么指令、操作数在哪里、要送到哪个执行单元。执行ExecuteALU根据控制信号完成实际计算比如加法、减法、比较。访存Memory Access如果指令需要读写内存比如从内存加载一个值、把结果存回内存这个阶段才会真正访问存储器。写回Write Back把计算结果写回寄存器文件让后续指令可以使用。3.2 从高级语言到机器指令的真实过程为了让你直观感受这条旅程我们看一段最简单的C代码// 文件路径demo/sum.c int sum(int n) { int s 0; for (int i 0; i n; i) { s i; } return s; }在Linux下用gcc编译并导出汇编gcc -O0 -S sum.c生成的sum.s中核心循环部分大致长这样.L3: movl -8(%rbp), %eax # 把 i 读入 eax addl %eax, -4(%rbp) # s i addl $1, -8(%rbp) # i .L2: movl -8(%rbp), %eax # 读取 i cmpl -20(%rbp), %eax # 比较 i 与 n jl .L3 # 如果 i n跳回循环体这段汇编展示的是编译产物还没有经过CPU执行。当程序真正运行CPU会逐条取到这些指令每一行碰到跳转指令jl时控制单元还要判断条件是否成立从而决定下一条指令到底去哪取。3.3 为什么要记住这个流程把五级流水线装进脑子里有一个立竿见影的好处你会意识到一行高级代码背后可能对应多条机器指令一条机器指令背后又可能经历多个硬件阶段。所以当你在Python里运行一个for循环你以为的循环一次是解释器执行了若干条字节码字节码最后又翻译成一大堆机器指令机器指令还要经过CPU的取指→译码→执行→写回。这就是为什么高语言层的简单操作在底层永远不简单。4. 指令集架构与微架构先分清这对最容易被混淆的概念在谈流水线和乱序执行之前必须先分清一个关键区别指令集架构ISA与微架构Microarchitecture。**指令集架构ISA**是CPU对软件公开的接口协议。它定义了有哪些指令、有哪些寄存器、如何寻址、如何调用函数等。x86-64、ARM64、RISC-V都属于ISA。只要你写的程序编译成某种ISA那么任何实现该ISA的CPU都能运行它。微架构是CPU在内部如何实现这套接口。同样是x86-64Intel和AMD各自有不同的设计不同代之间也有巨大差异。你可以把ISA理解为法律条文微架构理解为执法机构的具体办事流程。法律条文稳定办事流程却在不断优化。这条区别直接解释了很多开发者的困惑为什么相同指令集的CPU性能差异巨大因为微架构不同。同一个add指令在A处理器上是1个时钟周期在B处理器上可能也是1个周期但A的流水线更深、缓存更大、分支预测器更聪明循环体整体快数倍。为什么CPU天梯图永远不能只看主频因为天梯图排的是综合性能而性能是微架构设计、主频、缓存、功耗散热共同作用的结果。为什么CPU好不好这个问题很难脱离应用场景回答因为微架构的设计取向不同有的善于跑单线程重负载有的善于跑多核并行负载有的在低功耗场景下表现更好。更进一步热词里反复出现的多周期MIPS CPU设计MIPS微程序CPU设计(logisim)其实就是计算机体系结构课程中让你亲手实现一个接口协议的教学版。这类实验的意义在于你直接在硬件层面看到译码器、ALU、控制信号的协同能极大加深对ISA和微架构的理解。5. 现代CPU的隐藏机制流水线、乱序执行与分支预测5.1 流水线让CPU不再干一件等一件如果用最朴素的模型理解CPU它是一条接着一条执行指令的前一条执行完再取下一条。这种模型叫做顺序执行很好懂但效率极低。现代CPU使用流水线Pipeline。五级流水线意味着不同指令的五个阶段可以重叠执行。理想情况下每条指令仍然需要经过五个阶段但一旦流水线装满每一拍就能完成一条指令而不是五拍完成一条。你想象一下寿司店流水线五个人分别负责米饭、加鱼、卷起、切块、装盘。当流水线满负荷运转时不是客人等一整套寿司做完才出下一份而是每一秒都有一份寿司完成。CPU流水线也是这个道理。5.2 数据冒险与控制冒险流水线不是总能装满看起来很美但流水线有一个致命问题指令之间存在依赖。比如前一条指令刚算出eax的值后一条指令马上要用这个eax但前一条指令还没走到写回阶段后一条已经在译码阶段了。这就是数据冒险。硬件解决这个问题的办法是前递forwarding把计算结果提前从执行阶段绕回执行阶段下游不需要等完全写回。比数据冒险更麻烦的是控制冒险。遇到条件跳转指令比如jlCPU要等判断条件算出来才知道下一步去哪。如果干等流水线就空转如果提前猜猜错了就要清空已经取进来的错误指令这就是分支预测的由来。分支预测是现代CPU中非常被低估的部件。现代分支预测器会记录这个跳转的历史规律最近几次跳不跳、跳去哪然后基于历史和复杂的精确规律预测下一次。预测对了流水线顺畅预测错了代价是流水线被冲刷可能损失十几个甚至更多的周期。这也是为什么在实际开发中分散的、无规律的分支判断往往比连续规律的分支路径更昂贵。5.3 乱序执行硬件层面的时间管理再进一步现代CPU早就不是你想象中按照代码顺序执行而是采用乱序执行Out-of-Order Execution。控制单元会先把指令按顺序取进来译码然后分析指令之间的真实依赖关系把没有依赖的指令调度到空闲的执行单元上去最后再把计算结果按原有顺序提交。一句话它执行时可以是乱序的但提交结果时必须保持程序员期望的顺序。这就是为什么多线程调试时你会觉得CPU似乎重排了代码顺序——它确实会在底层这么干但对于单线程逻辑它伪装得很像顺序执行。乱序执行是CPU微架构发生质变的核心标志。理论足够专业的同学会想起Tomasulo算法它通过保留站Reservation Station和寄存器重命名Register Renaming消除了假数据依赖是乱序执行的经典硬件实现。理解这一层你会发现代码写得越短就越快并不总是成立因为CPU已经在后台做大量重排序和并行调度了。5.4 从硬件机制回到开发者的启示为什么要花这么多笔墨讲流水线和乱序因为这两个机制直接改变了我们的优化直觉。如果在优化时假设CPU是按顺序一条一条执行指令的你会得出很多错误结论比如我少写一条if语句就一定快一点又比如这两个无关操作放在一起会互相拖累。实际上现代CPU很擅长并行调度无关指令也很擅长预测规律分支。真正拖累性能的是缓存未命中、分支预测失败、真正的数据依赖链过长。优化的优先级因此就清楚了先解决访存和预测问题再抠指令条数。6. 存储器层级与CPU的连接缓存为什么是性能的命脉热词里存储器与cpu的连接是经典考点也是日常优化中最值得花时间的地方。从CPU角度看存储设备的速度和容量是一组矛盾越靠近CPU速度越快容量越小价格也越高。现代CPU为了调和这个矛盾采用了多层存储结构。从内到外大致是层次典型容量访问速度数据特征寄存器几百字节1个周期量级正在操作的数据L1缓存几十KB数个周期最近使用过和即将使用的L2缓存几百KB到几MB几十个周期L1的缓冲L3缓存数MB到数十MB几十到上百周期多个核心共享主存数GB到数百GB上百周期全部程序与数据磁盘/SSD更大更慢持久化存储在Linux里lscpu输出能直观看到缓存规模。值得注意很多面试题考存储器与CPU的连接本质是考CPU直接访问内存太慢所以需要缓存缓存内部又分多级并且以缓存行Cache Line为单位读取。缓存行通常为64字节。CPU访问内存时不是只取你要的那一个字节而是一次取一整行。这个机制直接引出了两个黄金原则空间局部性Spatial Locality如果你访问了地址A附近的地址B这些数据很可能在同一个缓存行里第二次访问会很快。所以连续数组遍历远快于随机跳转访问。时间局部性Temporal Locality如果一个数据刚被访问过短期内它大概率留在缓存里。所以循环体内的重复变量要尽量贴近循环。来看一个经典的代码对比。// 文件路径demo/cache_test.c #define N 10000 int a[N][N]; // 写法1按行访问 void row_first(void) { for (int i 0; i N; i) { for (int j 0; j N; j) { a[i][j] i j; } } } // 写法2按列访问 void col_first(void) { for (int j 0; j N; j) { for (int i 0; i N; i) { a[i][j] i j; } } }在C语言中二维数组a[N][N]是按行优先连续存储的。写法1访问的是连续地址缓存行利用率极高写法2每换一个i就跳向另一个远离的行相当于几乎每次访问都要重新装满缓存行。当N足够大时两种写法的耗时差距可以到达一个数量级。这类测试在任何一本讲性能优化的书中都会出现因为在真实业务中改一下循环顺序这类操作成本极低、收益极高。有了缓存模型进一步还能解释**伪共享False Sharing**问题不同的线程各自修改自己的变量但因为这些变量被分配到同一个缓存行缓存一致性协议会反复同步这一行数据结果各线程互相拖累。这是多核并发优化中一个隐蔽而常见的陷阱根治办法是让关键变量按缓存行对齐padding或使用独立的存储区域。7. 多核、超线程与虚拟化为什么不是核越多越快现代CPU从单核发展为多核并且普遍支持超线程。对这些概念很多开发者只停留在核越多越快的层面这远远不够。多核是指一颗物理封装内包含多个独立的处理器核心。每个核心有自己的执行单元、寄存器和L1/L2缓存多个核心共享一个L3缓存和内存控制器。**超线程Hyper-ThreadingHT**是Intel提出的一种技术后来被广义称为同步多线程SMT。一个物理核心划分成多个逻辑处理器。超线程的理由是单个程序的一串指令往往不能填满核心内部所有执行单元比如ALU算得很快但访存经常等待。于是CPU在硬件层面同时保留两套寄存器状态和程序状态让两个线程交替使用空闲的执行单元看起来就像多了一个核。所以你在lscpu里看到的CPU(s): 8并不等于8个物理核心需要再查Thread(s) per core和Core(s) per socket。比如Thread(s) per core: 2Core(s) per socket: 4含义是4个物理核心、每核2个逻辑线程总共对操作系统实际暴露8个逻辑CPU。**为什么多线程性能不是线性增长**这里至少有四类开销同步开销多个线程访问共享数据需要加锁锁竞争会带来等待。缓存一致性开销不同核心修改共享缓存行时要同步到其他核心伪共享问题尤其明显。内存带宽瓶颈多核同时从内存读数据可能先打满内存带宽而不是打满CPU。上下文切换操作系统在逻辑处理器间切换线程需要保存和恢复寄存器状态加上缓存热数据流失。再联系热词vmware虚拟机cpu虚拟化虚拟机之所以能跑本质上也是CPU在硬件层面提供了特权指令虚拟化支持如Intel的VT-x、AMD的SVM。lscpu输出的flags中包含vmx或svm就表示支持这类硬件虚拟化。虚拟机的CPU调度也是由宿主机的逻辑处理器和调度器共同决定的所以看到虚拟机CPU已禁用一类的报错通常不是CPU坏了而是虚拟化功能未开启、BIOS设置问题或权限配置不正确。/proc/cpuinfo里的flags字段非常值得习惯性看一眼。它包含CPU支持的所有指令集扩展如sse4_2、avx2、popcnt等。日常开发中现代数学库和加密库往往会利用这些扩展指令做向量化加速如果你的部署机器不支持某些flags库只能退回通用慢速路径。8. 在Linux下观察CPUlscpu、/proc/cpuinfo与perf上手讲了这么多模型接下来落到动手环节。观察CPU的最快方式是Linux系统自带命令。8.1 使用lscpu查看拓扑与核心lscpu某台机器上的输出大致如下具体型号与数值以你自己的机器为准Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 158 Model name: Intel(R) Core(TM) i7-7700K CPU 4.20GHz Stepping: 9 CPU MHz: 800.000 CPU max MHz: 4200.0000 CPU min MHz: 800.0000 L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K重点看几个字段CPU(s)操作系统可见的逻辑CPU数量等于物理核数 × 每核线程数 × 插槽数。Thread(s) per core每核超线程数1表示无超线程2表示开启SMT。Core(s) per socket每个物理插槽内的物理核心数。Socket(s)物理CPU插槽数服务器常见2路、4路。L1d、L1i、L2、L3各级缓存大小其中L1分为数据缓存d和指令缓存i。8.2 使用/proc/cpuinfo查看细节cat /proc/cpuinfo | head -20产出与lscpu互补的信息比如每个逻辑处理器的processor编号、vendor_id、cpu family、model、model name、cpu cores、siblings以及一长串flags。当需要排查为什么同一份代码在这两台机器上表现不同时比较两边的model name和flags是第一步。8.3 使用perf stat观察程序的硬件计数器仅看CPU配置还不够关键是测量你的程序实际触达了哪些硬件事件。perf工具是Linux下最常用的性能计数器前端。perf stat ./your_program输出会包含诸如下面的指标Performance counter stats for ./your_program: 1,024.23 msec task-clock # 1.000 CPUs utilized 6 context-switches # 0.014 K/sec 0 cpu-migrations # 0.000 K/sec 424 page-faults # 0.414 K/sec 20,547,123,456 cycles # 1.231 GHz 40,123,999,999 instructions # 1.95 insn per cycle 4,892,345,678 branches 160,123,456 branch-misses # 3.27% of all branches简要解读task-clock程序占用的CPU时间。context-switches上下文切换次数过多说明线程调度频繁。cycles总时钟周期数。instructions实际执行的指令数。branch-misses分支预测失败的次数及比例。如果这个比例偏高说明程序分支不规律可能值得调整代码结构。perf还能做更细的采样比如perf record ./your_program然后perf report可以看到热点函数分布。日常调优的标准动作应该是先perf stat看宏观指标确认瓶颈方向CPU、内存、调度、I/O再perf record定位到具体函数。9. 工程开发中的CPU优化实践理解底层原理之后接下来是怎么用。这里给的优化建议都是一般工程安全做法避免陷入过早优化的误区。9.1 先测量再优化没有perf stat、lscpu、/proc/cpuinfo这些数据之前不要对着代码凭感觉优化。CPU相关优化尤其如此因为流水线、分支预测和缓存行为并不总能靠肉眼推断。建议流程是用工具确认热点在CPU执行指令本身还是在缓存未命中还是在锁竞争。针对热点做局部调整。每次只改一个变量重新测量。9.2 让数据访问符合局部性循环尽量按数组存储顺序遍历热点结构体保持紧密排列避免在循环体内做指针追逐和随机索引。这些做法本质是提高缓存行利用率。9.3 减少伪共享多线程场景下如果多个线程频繁修改私有变量但这些变量恰好位于同一缓存行性能会被拖累。可以在必要时按64字节对齐隔离但不要滥用先测量确认是伪共享再动手。9.4 编写分支预测友好的代码规律性分支比随机性分支更容易被预测。大量数据排序后遍历往往比乱序数据遍历快得多原因不只是数据组织更整齐还有分支预测准确率上升。对极热分支条件表达式的写法可能影响编译生成的分支方式但更重要的是让数据分布有规律。9.5 让编译器帮你向量化现代CPU支持SIMD指令扩展如AVX2、AVX-512不同处理器支持不同。编译器在-O2及以上往往能自动向量化简单循环。如果你的代码是为了数值计算可以考虑用显式向量化库如Eigen、OpenBLAS或OpenMP而不是手写汇编。9.6 合理评估线程数CPU(s)显示的是逻辑处理器数不是最佳线程数。对CPU密集型任务推荐开等于物理核心数的线程而不是超线程数因为超线程带来的加速通常小于物理核心。对I/O密集型任务线程数可以超过CPU数因为线程大量时间在等待I/O。9.7 注意生产环境的CPU调度与限制容器和虚拟机场景下lscpu看到的可能只是宿主机分配给它的逻辑CPU视图cpu受限并不是CPU损坏。如果遇到Docker容器CPU限制不生效虚拟机提示CPU已禁用这类问题优先检查虚拟化平台配置、BIOS的VT-x开关、容器CPU配额以及宿主机的cgroup设置而不是怀疑CPU硬件。10. 常见误区与面试高频问题学完模型之后对照容易踩的坑。我整理了一个高频误区清单常见误区正确理解主频高就一定快主频只是指标之一微架构、缓存、指令集同样关键核心数越多性能线性增长同步开销、带宽、缓存一致性会拖后腿超线程等于物理双核超线程只是利用空闲执行单元加速幅度有限CPU按代码顺序执行指令现代CPU会乱序执行但提交结果顺序符合程序语义少写一条指令就快一点缓存未命中和分支预测失败往往比指令条数更关键看CPU天梯图只选最高分要结合用途、功耗、预算和实际负载特征选虚拟机CPU禁用就是CPU坏了通常是虚拟化功能、BIOS或平台配置问题对应到面试以下题目会在CPU底层原理主题下高频出现**寄存器与内存是什么关系**寄存器是CPU内部的极速存储容量极小数据由编译器和指令系统调度内存是主存容量大而慢。CPU通过地址总线选内存单元数据经过数据总线传输。访问寄存器通常只需1个周期访问主存可能需要上百个周期所以引入了缓存。**一条指令从取到执行的过程是什么**取指、译码、执行、访存、写回多级流水线下这几个阶段对不同指令重叠进行遇到依赖和分支时通过前递、分支预测、乱序执行等手段降低停顿。**为什么循环顺序会影响性能**因为缓存以块为单位加载连续访问同一缓存行内的数据会命中缓存跳跃式访问会造成缓存频繁失效。**多线程是不是一定快**不是。缓存一致性同步、锁等待、上下文切换、内存带宽限制都会抵消并行收益。**怎么判断程序是CPU密集还是内存密集**用perf stat观察cycles与instructions的关系以及缓存未命中率再用perf record看热点采样如果热点函数大量时间在等待主存数据那么属于访存受限。这些面试问题表面在考知识点实际在考你有没有一套可解释现象的CPU运行模型。如果你看到一道题先想到寄存器→缓存→内存→磁盘这条链路再从取指→译码→执行→写回补上执行流多数情况下方向都不会错。11. 总结与深入学习路线这篇文章从三个层面构建了CPU底层原理的模型。第一层是组成ALU、寄存器、控制单元各司其职第二层是指令执行取指、译码、执行、访存、写回这五级流水线以及数据冒险、控制冒险、分支预测和乱序执行第三层是系统视角缓存层级、多核/超线程、CPU与存储器的连接以及性能观察工具。把这套模型装进日常开发里你不会再被玄学性能问题困住而是能准确地把现象对标到机制慢是慢在访存、慢在分支预测、慢在锁竞争还是慢在CPU执行本身这种归因能力比记住任何一条具体的编译器优化规则都值钱。下一步实践我建议你自己动手做三件事写一个简单的C程序用gcc -S导出汇编对着这篇文章的指令旅程图示逐行看取指、译码、访存如何映射。写两个循环顺序相反的C程序用time ./a.out测量差异再最后用perf stat ./a.out确认缓存和分支上的差异。用lscpu和/proc/cpuinfo分析你正在用的机器弄清物理核、逻辑核、缓存、支持哪些指令集扩展。如果还想继续深入比较合适的路径是先读一遍《深入理解计算机系统》里关于处理器、缓存和性能优化的章节再体系化学习RISC-V或MIPS的简单实现甚至在Logisim里动手设计一个多周期CPU彻底打通指令集和微架构的最后一公里。到了那一步你再回头看10分钟讲明白CPU底层原理这个题目就会发现它不再是夸张而是一张你已经真正拥有的、随手就能画的运行图。