知识全景图/ 软件工程与系统/ 计算机系统底座

计算机系统底座

软件运行在真实机器上的共同地基：物理限制、CPU 执行、内核资源、语言运行时与工程排障入口

阅读定位: 这页是“系统底座分支”的入口和路由器，不再承担完整教材职责。它帮助你判断一个问题应该下钻到硬件物理、体系结构、操作系统内核，还是编译器与运行时。

边界原则: 本页只保留分层、分工、问题入口和学习路线；具体机制、设计训练、案例和排障证据交给五张下钻页展开。
一、系统底座总分层
物理世界→ 数字电路 / 设备→ CPU / 内存体系→ 操作系统内核→ 编译器 / 运行时→ 语言 / 框架 / 服务
层级核心问题它给上层留下的约束
物理与设备电压、信号传播、存储介质、总线、功耗、散热距离有延迟下限，SSD / GPU / 网卡都有介质、队列和搬运成本
体系结构指令、流水线、Cache、分支预测、多核、NUMA同样 Big-O 的代码会因为局部性、共享写和内存带宽表现完全不同
操作系统内核调度、虚拟内存、文件系统、网络栈、cgroup / namespace应用慢、OOM、磁盘满、连接异常常常需要回到内核证据判断
编译器与运行时编译、JIT、GC、对象布局、协程、事件循环、GIL、unsafe不同语言生态在性能、内存和并发上的差异来自运行时模型
二、五张下钻页怎么分工
数字电路与硬件物理底座
回答“物理世界为什么给软件设下硬约束”：跨地域延迟、SSD 长尾、GPU 数据搬运、功耗与热降频。
计算机体系结构底座
回答“代码为什么在真实 CPU 上快慢不同”：指令、Cache、分支预测、内存带宽、多核一致性、NUMA。
操作系统内核机制底座
回答“应用怎样使用 Linux 资源”：进程线程、虚拟内存、VFS、page cache、epoll、TCP、cgroup、namespace。
如何设计操作系统
回答“如果从零设计一个小 OS，要先决定什么”：启动、进程、内存、系统调用、文件、设备、网络和安全边界。
编译器与运行时底座
回答“语言生态为什么差异明显”：Java、Go、Node、Python、Rust / C++ 的 JIT、GC、调度、内存和崩溃边界。
三、问题入口导航
你看到的现象优先去哪里为什么不要先做什么
跨地域接口怎么优化都慢硬件物理底座、分布式系统距离、传播速度、路由和一致性协议会给延迟设物理下限不要只换 RPC 框架或盲目调超时
CPU 高但吞吐不涨体系结构底座、运行时底座可能是 Cache miss、内存带宽、锁竞争、GC、解释器或反优化不要只凭 CPU 高就扩容
线程越多越慢体系结构底座、内核机制底座共享缓存行、锁、原子操作、内存带宽、调度和 NUMA 都会限制扩展性不要继续无脑加线程池
CPU 不高但接口慢内核机制底座、可观测性 / SRE线程可能在等锁、IO、网络、连接池、下游或 cgroup quota不要只看应用函数耗时
OOMKilled 但 heap 不高内核机制底座、运行时底座容器 OOM 看 cgroup RSS，heap 外还有 direct、线程栈、mmap、native、page cache不要只调大 JVM heap
Java / Go / Node / Python / Rust 表现差异很大编译器与运行时底座真正差异来自 JIT、GC、对象模型、事件循环、GIL、goroutine、unsafe 和 ABI不要用“语言快慢”一句话下结论
SSD 平均快但写入 P99 抖硬件物理底座、内核机制底座NAND 擦除、FTL、盘内 GC、fsync、设备队列都会制造长尾不要只看平均 IOPS / MB/s
GPU 利用率不高但推理慢硬件物理底座、AI Infra / GPU瓶颈可能在 CPU 预处理、H2D / D2H 拷贝、kernel launch、batch 形状和显存带宽不要只换更贵 GPU
四、学习路线
目标推荐顺序学到什么程度就够
应用工程师补系统判断力如何设计操作系统 → 内核机制 → 编译器与运行时 → 体系结构 → 硬件物理能把线上现象拆成 CPU、内存、IO、网络、运行时、容器资源几类证据
性能工程 / 高性能服务体系结构 → 编译器与运行时 → 内核机制 → 硬件物理能用 profile、硬件计数器、GC / runtime 证据解释吞吐和长尾
基础设施 / 平台方向硬件物理 → 体系结构 → 内核机制 → 编译器与运行时能理解机器、内核、容器、运行时和服务治理之间的约束传导
五、和现有工程页怎么分工
如果你关心继续看分工说明
日常 Linux 命令、服务状态和线上排障Linux / DevOpsLinux 页偏命令和操作动作，系统底座页解释这些动作背后的机制
Java、JVM、GC 和 Java 并发Java 生态Java 页把运行时底座落到 JVM、Spring 和工程生态
Profiling、压测、容量和热点优化性能工程性能页负责方法和工具闭环，系统底座页负责解释为什么这些证据有意义
远程调用、一致性、复制和部分失败分布式系统分布式页展开多节点协议，本页只提供网络、时间、失败和持久化前提
容器、Kubernetes 和资源限制云原生云原生页负责集群编排，本页解释 namespace / cgroup / 内核资源边界
指标、Trace、SLO 和事故复盘可观测性 / SRESRE 页把底层信号变成生产治理和用户体验指标
六、维护边界
规则原因执行方式
hub 不展开具体案例避免总页变成又长又散的教材页总页只给入口，案例放到四张下钻页
重复主题只保留一个主责页CPU、内存、IO、GPU 等主题天然跨层，容易重复按“物理限制 / CPU 执行 / 内核资源 / 运行时模型”分主责
每张下钻页都写清楚不负责什么读者需要知道什么时候该跳页在阅读边界里写“本页不负责”，并用跨页读法路线分流；OS 设计页负责设计训练，内核机制页负责 Linux 机制和排障证据
新增内容优先按问题入口组织系统底座的价值是形成判断力，不是堆术语优先补“现象 → 机制 → 证据 → 动作”的案例
总结: 计算机系统底座分支现在采用“hub 导航 + 五张下钻页”的结构。总页负责分层和入口，硬件物理、体系结构、操作系统设计、操作系统内核机制、编译器与运行时分别解释不同层级的约束，避免一个主题在多页里重复抢边界。