Linux、Docker、Kubernetes 与 Pod

学习目标

能力目标

完成本章学习后，你将能够：

1. 理解 Linux 进程与线程的本质区别，从资源分配与 CPU 调度两个维度解释 fork/exec/wait 底层机制，并能区分用户级线程、内核级线程与轻量级进程（LWP）。
2. 掌握 Docker 三大核心技术（Namespace 隔离、Cgroups 限制、UnionFS 分层），熟练使用 docker build/run/exec 等常用命令，理解容器隔离的根本原理。
3. 编写生产级 Go 项目多阶段 Dockerfile，掌握依赖缓存优化策略，能将镜像体积从数百 MB 压缩到 20MB 以内，并正确使用 .dockerignore 排除无关文件。
4. 理解 K8s 集群架构与核心概念，画出 Master/Node 组件关系图，掌握 Pod 生命周期、健康检查三件套、Deployment 滚动更新与 Service 四层负载均衡。
5. 系统排查 Pod CPU 线性增长问题，运用 go tool pprof 火焰图定位 goroutine 泄露、全局 map 膨胀、ticker 未 Stop 等常见根因，并建立 Prometheus 监控告警体系。

前置知识

• 了解 Linux 基本命令行操作（ls/cd/cat/grep 等基础命令）
• 能用 Go 语言编写简单的 HTTP 服务（net/http 包基本用法）
• 了解操作系统进程、线程的基本概念
• 对容器和微服务有初步认知

动手做三件事

1. 在本地用 Docker 构建一个 Go 项目的多阶段镜像，要求最终镜像小于 20MB，并对比单阶段构建与多阶段构建的镜像体积差异。
2. 用 minikube 或 kind 搭建本地 K8s 集群，部署一个 Deployment（3 副本）+ Service，手动触发滚动更新并验证回滚操作。
3. 编写一个故意泄露 goroutine 的 Go 程序，用 go tool pprof 定位泄露位置，修复后验证 goroutine 数量稳定。

一、Linux 进程与线程

1.1 用生活类比先建立直觉

想象一栋独立别墅。进程就像别墅本身——它拥有自己的土地（地址空间）、门牌号列表（文件描述符表）和门铃系统（信号处理表）。别墅之间互相独立，A 栋别墅的水管坏了不会影响 B 栋。两栋别墅要交流，得通过快递（管道）、公共公告板（共享内存）或对讲机（信号）。

线程则像是别墅里的多个住户。住在同一栋别墅里的三个人共享客厅、厨房、卫生间（地址空间、文件描述符），但每人有自己的独立卧室（栈）、私人笔记本（寄存器）和书签（PC 计数器）。一个人把厨房水管搞坏了，所有人都要受影响——这就是线程安全问题。一个人搞装修太吵影响别人——这就是竞态条件。

再换一个角度：进程是"资源分配的基本单位"（操作系统给谁分房子），线程是"CPU 调度的基本单位"（谁排队去用 CPU 这个公共厨房）。

graph TB
    subgraph 进程资源
        MEM[地址空间]
        FD[文件描述符表]
        SIG[信号处理表]
        HEAP[堆内存]
    end
    T1[线程1
独立栈 / 寄存器 / PC]
    T2[线程2
独立栈 / 寄存器 / PC]
    T3[线程3
独立栈 / 寄存器 / PC]
    T1 -->|共享| MEM
    T2 -->|共享| MEM
    T3 -->|共享| MEM
    T1 -->|共享| FD
    T2 -->|共享| FD
    T3 -->|共享| FD

桥接： 从"别墅与住户"到"进程与线程"——进程拥有独立资源（地址空间、文件描述符表、信号处理表），线程共享进程资源但拥有独立的执行上下文（栈、寄存器、PC）。理解了这个资源模型后，我们来看 Linux 内核是如何创建和管理它们的——底层机制是 fork/exec/wait 三板斧。

1.2 工程要点

进程底层逻辑：fork / exec / wait

Linux 创建进程的经典三步曲是理解一切进程行为的根基：

• fork()：创建子进程，采用写时复制（Copy-On-Write, COW）。fork 瞬间父子进程共享同一份物理内存页，只有当某一方尝试写入时，内核才真正复制那一页。这大大减少了创建开销。
• exec()：加载新程序替换当前进程映像。代码段、数据段、堆栈全部被新程序覆盖，但文件描述符表默认保留（这就是 shell 管道能工作的原因）。
• wait()：父进程等待子进程退出并回收资源。如果父进程不 wait，子进程退出后会变成僵尸进程（Z 状态），占用 PID 资源。

// 进程创建的经典三步（C 伪代码展示概念）
pid_t pid = fork();      // 步骤1：fork 创建子进程，返回值区分父子
if (pid == 0) {
    // 子进程执行流
    exec("/bin/ls", "-l", NULL); // 步骤2：exec 加载新程序替换当前映像
    // 如果 exec 成功，以下代码永远不会执行
    perror("exec failed");
    exit(1);
} else if (pid > 0) {
    // 父进程执行流
    int status;
    waitpid(pid, &status, 0); // 步骤3：wait 等待子进程退出，回收资源
    if (WIFEXITED(status)) {
        printf("子进程退出码: %d\n", WEXITSTATUS(status));
    }
} else {
    perror("fork failed"); // fork 失败（如 PID 耗尽）
}

线程三种实现方式

Linux 线程的实现经历了从用户态到内核态的演进，三种方式各有取舍：

⚠️ 新手必踩的坑： 很多人以为 Go 的 goroutine 就是操作系统线程。实际上 goroutine 是用户级线程，由 Go runtime 调度到少量的内核线程（LWP）上执行（GMP 模型）。一个 goroutine 阻塞在系统调用上时，runtime 会把该内核线程分离出去（handoff），新建一个线程继续调度其他 goroutine，这就是为什么 Go 能轻松创建十万级 goroutine 而 pthread 做不到。

进程与线程三维度对比

常见 Linux 运维命令

日常开发和排查问题离不开这些命令，建议收藏速查：

# 步骤1：查看所有进程（BSD 风格，显示用户/PID/CPU/内存/命令）
ps aux

# 步骤2：查找特定进程（如查找 nginx 工作进程）
ps aux | grep nginx | grep -v grep

# 步骤3：实时监控系统资源（CPU/内存排行，按 q 退出，按 M 按内存排序，按 P 按 CPU 排序）
top

# 步骤4：按 CPU 使用率降序，取前 10 个进程
ps aux --sort=-%cpu | head -10

# 步骤5：优雅终止进程（发送 SIGTERM 信号，程序可捕获并做清理）
kill -15 12345

# 步骤6：强制终止进程（发送 SIGKILL，内核直接杀，不可被捕获，不给清理机会）
kill -9 12345

# 步骤7：查看 TCP 监听端口（比 netstat 更快，推荐使用 ss）
ss -tlnp

# 步骤8：查看某个端口被哪个进程占用
lsof -i :8080

# 步骤9：查看磁盘分区使用情况（-h 人类可读）
df -h

# 步骤10：查看目录占用空间（-s 只显示汇总，-h 人类可读）
du -sh /var/log

# 步骤11：实时查看日志文件尾部（-f 跟踪追加）
tail -f /var/log/app.log

# 步骤12：查看 systemd 服务日志（-u 指定服务，-f 实时跟踪，--since 指定时间）
journalctl -u nginx -f --since "10 min ago"

# 步骤13：用 awk 提取进程信息（打印第 1/2/3/11 列：用户/PID/CPU/命令）
ps aux | awk '{print $1, $2, $3, $11}' | head -10

# 步骤14：统计各状态进程数量（R=运行 S=睡眠 Z=僵尸 D=不可中断睡眠）
ps aux | awk '{print $8}' | sort | uniq -c | sort -rn

⚠️ 新手必踩的坑： kill -9 会直接终止进程，不给程序任何清理机会（数据库连接不关闭、临时文件不删除、信号量不释放）。生产环境应该先 kill -15，等待 5 秒后如果进程仍存活再 kill -9。Docker 的 docker stop 默认就是先发 SIGTERM 等待 10 秒，超时才发 SIGKILL。

二、Docker 基础

2.1 用生活类比先建立直觉

在 Docker 出现之前，把应用部署到服务器就像搬家——你得把家具（代码）、水电管线（运行环境）、装修风格（依赖库版本）全部原样搬过去，稍有差异就报错（“在我机器上是好的啊！"）。

Docker 就像标准化的集装箱系统。 在集装箱出现之前，货物装在各种形状的箱子里，运输船要为每种箱子准备不同的固定方式。Docker 统一了标准——每个集装箱内部有：

• 独立隔间（Namespace）：每个集装箱里的货物看不到其他集装箱的货物，PID 隔离让容器内看到自己是 1 号进程
• 重量标签（Cgroups）：每个集装箱有载重上限，CPU 和内存不能超用
• 分层叠放（UnionFS）：集装箱可以一层层叠放，底层是公共底座（基础镜像），上层是你的改动，只存差异

graph TB
    subgraph 宿主机内核
        NS[Namespace
隔离视图: PID/网络/挂载/UTS/IPC/User]
        CG[Cgroups
资源限制: CPU/内存/IO]
        UFS[UnionFS
分层文件系统: 只读层+读写层]
    end
    subgraph 容器A
        PA[容器A进程
PID=1]
        FA[容器A文件系统]
    end
    subgraph 容器B
        PB[容器B进程
PID=1]
        FB[容器B文件系统]
    end
    NS --> 容器A
    NS --> 容器B
    CG --> 容器A
    CG --> 容器B
    UFS --> FA
    UFS --> FB

桥接： 从"集装箱"到"Docker”——Namespace 让每个容器以为自己独占系统（看不到其他容器），Cgroups 给每个容器画了资源红线（CPU/内存不能超标），UnionFS 让镜像可以分层叠加复用（基础层共享，差异层独立）。理解了这三大核心技术，我们来看 Docker 的日常工程操作。

2.2 工程要点

Docker 三大核心技术详解

docker build 镜像流程

从 Dockerfile 到镜像的完整流程：

Dockerfile（文本描述）  →  docker build  →  Image（分层只读镜像）
                                              ↓
                                     docker run  →  Container（镜像 + 读写层）

Docker 常用命令

# 步骤1：构建镜像（-t 指定名称和标签，最后的 . 表示构建上下文为当前目录）
docker build -t myapp:v1 .

# 步骤2：运行容器（-d 后台运行，--name 指定名称，-p 端口映射 宿主机端口:容器端口）
docker run -d --name myapp -p 8080:8080 myapp:v1

# 步骤3：查看运行中的容器
docker ps

# 步骤4：查看所有容器（包括已停止的，-a 即 all）
docker ps -a

# 步骤5：查看本地镜像列表
docker images

# 步骤6：进入运行中的容器（推荐方式）
docker exec -it myapp /bin/sh

# 步骤7：查看容器实时日志（-f 跟踪输出，--tail 100 只显示最后 100 行）
docker logs -f --tail 100 myapp

# 步骤8：停止容器（先发 SIGTERM 等待 10 秒，超时发 SIGKILL）
docker stop myapp

# 步骤9：删除已停止的容器
docker rm myapp

# 步骤10：删除镜像（必须先删除依赖该镜像的容器）
docker rmi myapp:v1

# 步骤11：清理无用镜像和停止的容器（释放磁盘空间，-a 清理所有未使用镜像）
docker system prune -a

# 步骤12：查看容器资源使用（CPU/内存/网络 IO）
docker stats myapp

进入运行中的容器：exec vs attach

进入容器有两种方式，适用场景完全不同：

# 推荐方式：exec 启动新 shell 进程，Ctrl+D 退出不影响容器
docker exec -it myapp /bin/sh

# 不推荐方式：attach 共享主进程的输入输出
docker attach myapp

⚠️ 新手必踩的坑： docker attach 会共享容器的 stdin/stdout/stderr。如果你在 attach 状态下按 Ctrl+C，信号会直接发给容器主进程（PID=1），导致容器直接退出。正确做法是用 docker exec 进入容器，这样退出 shell 不影响主进程。如果必须用 attach，退出时用 Ctrl+P, Ctrl+Q（先按 P 再按 Q）可以安全脱离而不发送信号。

三、Dockerfile 最佳实践

3.1 用生活类比先建立直觉

把 Dockerfile 比作一份菜谱。FROM 是选锅（基础镜像），RUN 是炒菜步骤（执行命令），COPY 是放食材（复制文件），CMD 是最后的"上菜"指令（容器启动时执行）。

多阶段构建就像是先在厨房（builder 阶段）做好半成品菜肴，然后只把成品端到餐桌上（runtime 阶段）。厨房里的锅碗瓢盆、切菜板、调料瓶（编译器、Git、构建工具）统统不需要带到餐桌上。你只需要一个干净的盘子和做好的菜——这就是为什么多阶段构建能把镜像从 800MB 缩小到 20MB。

依赖缓存优化就像是备菜。聪明的厨师会先把所有调料按用量分好（COPY go.mod go.sum），一次备齐（go mod download），再去切菜炒菜（COPY 源码 + 编译）。如果今天只是改了一个菜的配方（改了源码），调料盒（依赖）不用重新准备——因为调料没变，之前的备菜结果可以直接复用。

graph LR
    subgraph 构建阶段
        B1[golang:1.22-alpine
约800MB] --> B2[COPY go.mod go.sum]
        B2 --> B3[go mod download
下载依赖,缓存层]
        B3 --> B4[COPY 源码]
        B4 --> B5[go build
编译二进制]
    end
    subgraph 运行阶段
        R1[alpine:3.19
约7MB] --> R2[COPY 二进制
仅几MB]
        R2 --> R3[CMD 运行]
    end
    B5 -->|COPY --from=builder| R2

桥接： 从"菜谱"到"Dockerfile"——多阶段构建的核心思想是"编译环境和运行环境分离"。builder 阶段用完整的 Go 工具链镜像编译出二进制文件，runtime 阶段只需要一个极简镜像加上二进制文件。依赖缓存优化的核心是"把变化频率低的东西放在前面"——依赖文件（go.mod/go.sum）很少变，源码经常变，所以先 COPY 依赖再下载，利用 Docker 层缓存避免重复下载。

3.2 工程要点

Dockerfile 常用指令速查

多阶段构建详解

单阶段构建的问题：把 Go 编译器（约 500MB）、源码、构建缓存全部打包进镜像，但运行时只需要一个二进制文件（约 10MB）。

多阶段构建的解法：

# ==================== 构建阶段 ====================
FROM golang:1.22-alpine AS builder
# AS builder 给这个阶段命名，后面 COPY --from=builder 引用

# ==================== 运行阶段 ====================
FROM alpine:3.19
# 最终镜像基于 alpine，不含 Go 工具链

COPY --from=builder /app/myapp .
# 从 builder 阶段复制编译好的二进制，不带编译器和源码

依赖缓存优化：正确 vs 错误

# ❌ 错误写法：COPY 全部源码在前，任何文件改动都使 go mod download 缓存失效
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go mod download    # 每次改一行代码都要重新下载所有依赖
RUN go build -o myapp .

# ✅ 正确写法：先 COPY 依赖文件，利用 Docker 层缓存
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./  # 依赖文件很少变
RUN go mod download     # 缓存层：go.mod 没变就跳过
COPY . .               # 源码经常变，但只影响这一层和后续层
RUN go build -o myapp .

⚠️ 新手必踩的坑： 把 COPY . . 写在 RUN go mod download 之前是最常见的 Dockerfile 错误。Docker 按层构建，每一层是否需要重建取决于上一层是否变化。如果你先 COPY . .（包含所有源码），即使只改了一行代码，Docker 也会认为这一层变了，导致后面的 go mod download 缓存全部失效，每次构建都要重新下载依赖。正确做法是先 COPY go.mod go.sum，这样只有依赖文件变化时才会重新下载。

如果有本地依赖库不想每次都编译

项目中有 vendor 目录或本地依赖包时，采用分层 COPY 策略：

# 步骤1：先复制依赖描述文件（变化频率最低）
COPY go.mod go.sum ./
# 步骤2：如果有 vendor 目录，复制 vendor（变化频率低）
COPY vendor/ ./vendor/
# 步骤3：下载依赖（vendor 存在时使用 vendor，不联网）
RUN go mod download
# 步骤4：最后复制源码（变化频率最高）
COPY . .
# 步骤5：使用 vendor 模式编译（不依赖网络）
RUN go build -mod=vendor -o myapp ./cmd/server

Go 项目多阶段 Dockerfile 完整示例

以下是一个生产级 Go HTTP 服务的完整 Dockerfile，假设项目结构为：

myapp/
├── cmd/
│   └── server/
│       └── main.go       # 主入口
├── internal/
│   └── handler/
│       └── handler.go    # 业务逻辑
├── go.mod
├── go.sum
├── .dockerignore
└── Dockerfile

# ==================== 阶段一：构建阶段 ====================
# 步骤1：使用官方 Go Alpine 镜像（体积小，约 350MB）
FROM golang:1.22-alpine AS builder

# 步骤2：安装 git 并设置工作目录
RUN apk add --no-cache git
WORKDIR /app

# 步骤4：先复制依赖文件，利用 Docker 层缓存
COPY go.mod go.sum ./

# 步骤5：下载依赖（go.mod 没变时这一层直接命中缓存）
RUN go mod download

# 步骤6：复制全部源码
COPY . .

# 步骤7：编译 Go 程序
# CGO_ENABLED=0：静态编译，不依赖 glibc，可在 scratch/alpine 运行
# GOOS=linux：目标操作系统
# -ldflags="-s -w"：去掉调试符号和 DWARF 信息，减小二进制体积约 25%
RUN CGO_ENABLED=0 GOOS=linux go build \
    -ldflags="-s -w" \
    -o myapp \
    ./cmd/server

# ==================== 阶段二：运行阶段 ====================
# 步骤8：使用极简 Alpine 镜像（约 7MB）
FROM alpine:3.19

# 步骤9：安装 ca-certificates（HTTPS 请求需要根证书）和 tzdata（时区数据）
RUN apk --no-cache add ca-certificates tzdata

# 步骤10：设置时区为上海
ENV TZ=Asia/Shanghai

# 步骤11：创建非 root 用户运行（安全最佳实践）
RUN adduser -D -u 10001 appuser
USER appuser

# 步骤12：设置工作目录
WORKDIR /app

# 步骤13：从构建阶段复制编译好的二进制文件
COPY --from=builder /app/myapp .

# 步骤14：声明容器监听端口
EXPOSE 8080

# 步骤15：健康检查（每 30 秒检查一次，超时 3 秒，重试 3 次）
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
    CMD wget -qO- http://localhost:8080/health || exit 1

# 步骤16：启动程序
CMD ["./myapp"]

验证构建效果：

# 步骤1：构建并查看镜像大小（多阶段约 15-20MB，单阶段约 800MB）
docker build -t myapp:v1 . && docker images myapp:v1

# 步骤2：运行容器并验证健康检查
docker run -d --name myapp -p 8080:8080 myapp:v1
docker inspect --format='{{.State.Health.Status}}' myapp

.dockerignore 文件

.dockerignore 文件告诉 Docker 构建时哪些文件不需要 COPY 到镜像中，减小构建上下文体积、加速构建、避免泄露敏感信息：

# Git 版本控制
.git
.gitignore

# IDE 配置文件
.vscode
.idea
*.swp

# 编译产物（容器内重新编译，不需要本地产物）
*.exe
*.dll
*.so
*.dylib
myapp

# 测试文件（生产镜像不需要）
*_test.go
testdata
coverage.out

# 文档（运行时不需要）
*.md
docs
LICENSE

# 操作系统文件
.DS_Store
Thumbs.db

# 环境变量文件（可能含密钥，避免泄露）
.env
.env.local

⚠️ 新手必踩的坑： 不写 .dockerignore 文件时，COPY . . 会把 .git 目录（可能几百 MB）、本地编译产物、测试数据全部发送到 Docker daemon 作为构建上下文。这不仅让构建变慢，还可能把 .env 中的数据库密码打包进镜像。一定要用 .dockerignore 排除这些文件。

四、Kubernetes 基础

4.1 用生活类比先建立直觉

把 K8s 集群想象成一家大型连锁公司。

Master 是总部。API Server 是前台接待——所有指令（创建 Pod、扩容、更新）都必须经过它登记，它是唯一与 etcd 直接通信的组件。etcd 是公司的档案室——所有集群状态（有哪些 Pod、在哪个 Node 上、什么版本）都存在这个键值数据库里。Scheduler 是人事部——拿到"需要部署 3 个 Pod"的指令后，根据资源情况决定每个 Pod 去哪个 Node（工位）。Controller Manager 是监工团队——不断对比"期望状态"和"实际状态"，发现偏差就自动纠正（比如 Pod 挂了就重新拉起一个）。

Node 是分公司。每个 Node 上跑着 kubelet（分公司经理）——接收总部的指令，确保容器按照规格运行。kube-proxy（网络接线员）——负责 Node 内部的网络规则和负载均衡。容器运行时（containerd）——真正跑容器的地方。

graph TB
    subgraph Master控制平面
        API[API Server
统一入口]
        ETCD[etcd
键值存储]
        SCHED[Scheduler
Pod调度]
        CM[Controller Manager
状态控制器]
    end
    subgraph Node1
        KL1[kubelet
容器管理]
        KP1[kube-proxy
网络规则]
        CR1[containerd
容器运行时]
    end
    subgraph Node2
        KL2[kubelet
容器管理]
        KP2[kube-proxy
网络规则]
        CR2[containerd
容器运行时]
    end
    API --> ETCD
    SCHED --> API
    CM --> API
    API --> KL1
    API --> KL2
    KL1 --> CR1
    KL2 --> CR2

桥接： 从"连锁公司"到"K8s 集群"——Master 负责全局决策（调度、状态管理、API 入口），Node 负责执行（运行容器、网络代理）。理解了公司架构后，我们来看 K8s 中最核心的工作单元——Pod，以及围绕它的 Deployment、Service 等管理对象。

4.2 工程要点

Pod：最小调度单位

Pod 是 K8s 中最小的可部署和可调度单元。一个 Pod 可以包含一个或多个紧密耦合的容器，它们共享网络和存储。

为什么不直接调度容器？ 因为容器之间有时需要紧密协作——比如一个业务容器加一个 sidecar 代理容器，它们需要通过 localhost 通信、共享数据卷。Pod 把这些容器"绑"在一起，作为一个整体被调度到同一个 Node 上。

# 步骤1：定义 Pod
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  # 步骤2：定义容器
  containers:
    - name: myapp
      image: myapp:v1
      ports:
        - containerPort: 8080
      # 步骤3：资源限制
      resources:
        limits:
          cpu: "500m"      # 最多 0.5 核
          memory: "256Mi"   # 最多 256MB
        requests:
          cpu: "250m"      # 保底 0.25 核
          memory: "128Mi"   # 保底 128MB
      # 步骤4：存活探针（失败则重启容器）
      livenessProbe:
        httpGet:
          path: /health
          port: 8080
        initialDelaySeconds: 15   # 容器启动后等 15 秒再开始探测
        periodSeconds: 10          # 每 10 秒探测一次
      # 步骤5：就绪探针（失败则从 Service 摘除但不重启）
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5
      # 步骤6：启动探针（保护慢启动应用，成功前不执行 liveness/readiness）
      startupProbe:
        httpGet:
          path: /startup
          port: 8080
        failureThreshold: 30       # 允许失败 30 次
        periodSeconds: 10           # 每 10 秒探测一次，最长等待 5 分钟
  # 步骤7：重启策略
  restartPolicy: Always

Pod 生命周期

graph LR
    P[Pending
等待调度和拉取镜像] --> R[Running
容器运行中]
    R --> S[Succeeded
所有容器正常退出]
    R --> F[Failed
至少一个容器异常退出]
    F -->|restartPolicy: Always/OnFailure| P
    F -->|restartPolicy: Never| C[CrashLoopBackOff
不再重启]

重启策略说明：

健康检查三件套

⚠️ 新手必踩的坑： livenessProbe 和 readinessProbe 的失败行为完全不同！livenessProbe 失败会重启容器（杀掉再拉起），readinessProbe 失败只是从 Service 的负载均衡列表中摘除（不重启，等恢复后自动加回）。新手常把就绪检查写成存活检查，导致应用还没启动完就被反复重启（CrashLoopBackOff）。对于慢启动应用，一定要加 startupProbe 保护启动窗口。

Deployment：管理 Pod 副本集

Deployment 是更高层的抽象，它管理一组相同的 Pod（通过 ReplicaSet），支持滚动更新和回滚：

# 步骤1：定义 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  # 步骤2：副本数量
  replicas: 3
  # 步骤3：选择器：管理带 app=myapp 标签的 Pod
  selector:
    matchLabels:
      app: myapp
  # 步骤4：Pod 模板
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:v1
          ports:
            - containerPort: 8080
          resources:
            limits:
              cpu: "500m"
              memory: "256Mi"
            requests:
              cpu: "250m"
              memory: "128Mi"

# 步骤5：应用 Deployment
kubectl apply -f deployment.yaml

# 步骤6：查看 Deployment 状态
kubectl get deployments

# 步骤7：触发滚动更新（更新镜像版本）
kubectl set image deployment/myapp-deployment myapp=myapp:v2

# 步骤8：查看滚动更新状态
kubectl rollout status deployment/myapp-deployment

# 步骤9：查看更新历史
kubectl rollout history deployment/myapp-deployment

# 步骤10：回滚到上一版本
kubectl rollout undo deployment/myapp-deployment

# 步骤11：回滚到指定版本
kubectl rollout undo deployment/myapp-deployment --to-revision=2

Service：为一组 Pod 提供固定访问入口

Pod 的 IP 是不固定的（每次重建都会变），Service 提供一个稳定的虚拟 IP（ClusterIP）和 DNS 名称，通过标签选择器将流量负载均衡到后端 Pod：

# 步骤1：定义 Service
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  # 步骤2：Service 类型
  type: ClusterIP
  # 步骤3：标签选择器（匹配 app=myapp 的 Pod）
  selector:
    app: myapp
  # 步骤4：端口映射
  ports:
    - port: 80           # Service 暴露的端口
      targetPort: 8080   # Pod 容器端口
      protocol: TCP
      name: http

Ingress：七层路由

Service 工作在四层（TCP/UDP），Ingress 工作在七层（HTTP/HTTPS），可以根据域名和路径将流量路由到不同的 Service：

外部请求 → Ingress Controller（如 Nginx Ingress）
              ↓
         根据域名/路径路由
         ↓              ↓              ↓
    api.example.com  web.example.com  admin.example.com
         ↓              ↓              ↓
    api-service     web-service    admin-service

# 步骤1：定义 Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  # 步骤2：TLS 证书配置
  tls:
    - hosts:
        - myapp.example.com
      secretName: myapp-tls
  # 步骤3：路由规则
  rules:
    - host: myapp.example.com
      http:
        paths:
          # 步骤4：API 路径转发到 api-service
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 80
          # 步骤5：其他路径转发到 web-service
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-service
                port:
                  number: 80

kubectl 常用命令速查

# 步骤1：查看集群节点状态
kubectl get nodes

# 步骤2：查看所有命名空间的 Pod
kubectl get pods -A

# 步骤3：查看 Pod 详情（事件、状态、探针配置）
kubectl describe pod myapp-pod

# 步骤4：查看 Pod 日志（-f 实时跟踪，--previous 查看上次崩溃的日志）
kubectl logs -f myapp-pod
kubectl logs --previous myapp-pod

# 步骤5：进入 Pod 容器
kubectl exec -it myapp-pod -- /bin/sh

# 步骤6：应用 YAML 配置文件
kubectl apply -f deployment.yaml

# 步骤7：查看 Pod 资源使用（需要 metrics-server）
kubectl top pod myapp-pod

# 步骤8：端口转发（本地访问 Pod，调试用）
kubectl port-forward pod/myapp-pod 8080:8080

⚠️ 新手必踩的坑： kubectl logs 只能看到当前容器的日志。如果容器反复重启（CrashLoopBackOff），想看上一次崩溃的日志需要加 --previous（简写 -p）参数：kubectl logs -p myapp-pod。不加这个参数你看到的可能只是最新一次启动的日志，而崩溃原因在上一轮。

五、Pod CPU 线性增长排查（实战面试题）

5.1 用生活类比先建立直觉

Pod CPU 线性增长就像一个漏水的水桶。水桶底部有个小洞（资源泄露），水（CPU 资源）一直在慢慢漏出。桶里的水位（CPU 使用率）随时间持续上升。如果你不去找到那个洞并修补，水迟早会溢出来（CPU 100%，服务不可用）。

排查的关键思路像侦探破案：先缩小范围，再精准定位。

• 第一步：看看是不是 goroutine 在"偷偷繁殖"（goroutine 数量持续增长 → 每个泄露的 goroutine 都在消耗调度开销）
• 第二步：检查是不是有一个"只进不出"的仓库（全局 map 只 put 不 delete → GC 扫描时间随 map 增大而增长）
• 第三步：看看是不是有一堆"忘记关掉的水龙头"（time.After 每次创建新 timer 不回收 / ticker 没 Stop → timer 堆积）
• 第四步：检查是不是"管道接头松了没拧紧"（HTTP/DB 连接用完不关闭 → 连接池泄露，polling 开销增大）

graph TB
    START[Pod CPU 线性增长
内存/网络正常] --> Q1{goroutine 数量
是否持续增长}
    Q1 -->|是| A1[pprof goroutine 分析
定位泄露位置]
    Q1 -->|否| Q2{全局 map 是否
只增不减}
    Q2 -->|是| A2[检查 map 写入逻辑
添加删除机制]
    Q2 -->|否| Q3{time.After 或 ticker
是否未 Stop}
    Q3 -->|是| A3[添加 defer ticker.Stop
用 time.NewTimer + Stop]
    Q3 -->|否| Q4{HTTP 或 DB 连接
是否未关闭}
    Q4 -->|是| A4[添加 defer resp.Body.Close
使用连接池]
    Q4 -->|否| A5[pprof CPU 火焰图
定位热点函数]
    A1 --> FIX[修复泄露
添加 Prometheus 告警]
    A2 --> FIX
    A3 --> FIX
    A4 --> FIX
    A5 --> FIX

桥接： 从"漏水水桶"到"CPU 泄露排查"——核心思想是"先判断泄露类型，再精准定位"。goroutine 泄露是最常见原因（每个泄露的 goroutine 虽然不干活，但调度器要轮询它们），其次是大 map 导致 GC 压力增加、timer/ticker 堆积、连接泄露。我们用 pprof 工具系统排查。

5.2 工程要点

问题现象

• 部分 Pod CPU 使用率随时间线性增长（如每天涨 10%）
• 内存使用正常（没有 OOM）
• 网络流量正常（没有异常请求）
• goroutine 数量可能持续增长（但也可能不增长，取决于泄露类型）
• 重启 Pod 后 CPU 恢复正常，但过几天又开始增长

排查思路：五大常见根因

定位方法：pprof 火焰图

首先在 Go 服务中启用 pprof：

package main

import (
    "log"
    "net/http"
    _ "net/http/pprof" // 步骤1：导入 pprof 包，init() 自动注册所有 handler 到 DefaultServeMux
    "time"
)

func main() {
    // 步骤2：启动 pprof HTTP 服务（监听 6060 端口）
    // 生产环境建议加鉴权或只绑定 localhost
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()

    // 步骤3：业务 HTTP 服务
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        time.Sleep(10 * time.Millisecond)
        w.Write([]byte("Hello, World!"))
    })

    log.Println("server starting on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

进入容器或端口转发后采集 pprof 数据：

# 方法一：进入容器内分析（容器需安装 go 工具链）
kubectl exec -it myapp-pod -- /bin/sh

# 方法二：端口转发到本地分析（推荐，生产容器无 go 工具链）
kubectl port-forward pod/myapp-pod 6060:6060

# 步骤1：查看 goroutine 数量（快速判断是否泄露）
curl -s http://localhost:6060/debug/pprof/goroutine?debug=1 | head -5

# 步骤2：交互式分析 goroutine（输入 top 查看 goroutine 排行）
go tool pprof http://localhost:6060/debug/pprof/goroutine

# 步骤3：在 pprof 交互界面中常用命令
# (pprof) top 20        # 查看 goroutine 数量最多的调用栈
# (pprof) list 函数名    # 查看具体代码行
# (pprof) traces         # 查看所有 goroutine 调用栈

# 步骤4：采集 CPU profile（默认 30 秒采样）
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

# 步骤5：在 pprof 交互界面中分析 CPU 热点
# (pprof) top 20        # CPU 消耗最多的函数
# (pprof) list 函数名    # 查看热点代码行
# (pprof) web            # 在浏览器打开火焰图（需要 graphviz）

# 步骤6：使用 Web UI 分析火焰图（Go 1.22+ 推荐）
go tool pprof -http=:8081 http://localhost:6060/debug/pprof/profile?seconds=30

⚠️ 新手必踩的坑： 忘记导入 _ "net/http/pprof" 会导致 pprof 端点返回 404。这个导入利用 Go 的 init() 机制自动把所有 pprof handler 注册到 http.DefaultServeMux。注意：只有使用 nil 作为 handler 时（即 http.ListenAndServe(addr, nil)）才会用到 DefaultServeMux。如果你用了自定义的 http.ServeMux，需要手动注册：mux.HandleFunc("/debug/pprof/", pprof.Index)。

goroutine 泄露示例与修复

以下代码展示了一个典型的 goroutine 泄露场景及其修复方法：

package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    _ "net/http/pprof"
    "time"
)

func main() {
    // 步骤1：启动 pprof
    go func() {
        log.Println(http.ListenAndServe("localhost:6060", nil))
    }()

    // 步骤2：模拟持续泄露 goroutine 的业务逻辑
    go func() {
        for i := 0; ; i++ {
            leakyFunction(i)
            time.Sleep(10 * time.Millisecond) // 每 10ms 泄露一个 goroutine
        }
    }()

    // 步骤3：业务 HTTP 服务
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello"))
    })
    log.Fatal(http.ListenAndServe(":8080", nil))
}

// leakyFunction 模拟 goroutine 泄露：channel 永远不会被写入
func leakyFunction(id int) {
    // 问题1：创建无缓冲 channel，没人发送则接收方永远阻塞
    ch := make(chan int)

    // 问题2：启动 goroutine 等待接收，但函数返回后没有人会往 ch 发送数据
    go func() {
        val := <-ch // 永远阻塞，goroutine 无法退出
        fmt.Println("received:", val)
    }()
    // 问题3：函数返回后，ch 和 goroutine 都不会被 GC 回收
    // 因为 goroutine 持有 ch 的引用，ch 又被 goroutine 引用（循环引用不会被 GC）
}

// fixedFunction 修复版本：使用 context 控制生命周期
func fixedFunction(ctx context.Context, id int) {
    // 步骤1：设置超时，5 秒后自动取消
    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
    defer cancel() // 步骤2：确保 cancel 被调用，释放 timer

    // 步骤3：使用带缓冲的 channel（即使没人接收也不会阻塞发送方）
    ch := make(chan int, 1)

    go func() {
        select {
        case <-ctx.Done(): // 步骤4：超时或取消时退出，不泄露
            return
        case ch <- id: // 步骤5：正常发送
        }
    }()
}

验证泄露与修复效果：

# 步骤1：运行泄露版本，每 10 秒查看 goroutine 数量（应持续增长）
go run main.go &
for i in 1 2 3 4 5; do
    curl -s http://localhost:6060/debug/pprof/goroutine?debug=1 | head -1
    sleep 10
done
# 输出示例：goroutine profile: total 102 → 203 → 304 → 405 → 506 ← 持续增长，确认泄露

# 步骤2：用 pprof 定位泄露位置
go tool pprof http://localhost:6060/debug/pprof/goroutine
# (pprof) top
# 输出示例：506 @ main.leakyFunction.func1+0x34 /app/main.go:35

其他常见泄露模式

// 泄露模式1：time.After 在循环中使用——每次创建新 timer，旧 timer 堆积
func badLoop() {
    for {
        select {
        case <-time.After(5 * time.Second): // 死循环中每次创建新 timer
            fmt.Println("tick")
        }
    }
}

// 修复：使用 time.NewTicker 并 defer Stop
func goodLoop(ctx context.Context) {
    ticker := time.NewTicker(5 * time.Second)
    defer ticker.Stop() // 步骤1：函数退出时停止 ticker，释放 timer
    for {
        select {
        case <-ctx.Done():
            return // 步骤2：context 取消时退出
        case <-ticker.C: // 步骤3：复用同一个 ticker
            fmt.Println("tick")
        }
    }
}

// 泄露模式2：HTTP 响应 Body 未关闭——连接不归还连接池
func badHTTP() {
    resp, _ := http.Get("https://api.example.com/data")
    // 忘记 resp.Body.Close()，连接泄露
    data, _ := io.ReadAll(resp.Body)
    fmt.Println(len(data))
}

// 修复：defer 关闭 Body
func goodHTTP() {
    resp, _ := http.Get("https://api.example.com/data")
    defer resp.Body.Close() // 步骤1：确保 Body 被关闭，连接归还连接池
    data, _ := io.ReadAll(resp.Body)
    fmt.Println(len(data))
}

// 泄露模式3：全局 map 只增不减——缓存只写不删，GC 扫描时间线性增加
var globalCache = make(map[string]*Data)

func badCache(key string, data *Data) {
    globalCache[key] = data // 只增不删
}

// 修复：使用带过期的缓存，定期清理过期条目
type SafeCache struct {
    mu   sync.RWMutex
    data map[string]*CacheEntry
}

type CacheEntry struct {
    Value     *Data
    ExpiresAt time.Time
}

func (c *SafeCache) Set(key string, value *Data, ttl time.Duration) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[key] = &CacheEntry{Value: value, ExpiresAt: time.Now().Add(ttl)}
}

// 步骤1：定期清理过期条目
func (c *SafeCache) Cleanup() {
    c.mu.Lock()
    defer c.mu.Unlock()
    for k, v := range c.data {
        if time.Now().After(v.ExpiresAt) {
            delete(c.data, k) // 步骤2：删除过期条目
        }
    }
}

监控告警：Prometheus + pod CPU metrics

建立监控体系，在 CPU 线性增长演变成事故前发现问题：

# Prometheus 告警规则：Pod CPU 持续增长告警
groups:
  - name: pod-cpu-alerts
    rules:
      # 步骤1：CPU 使用率超过 80% 持续 5 分钟
      - alert: PodCPUHighUsage
        expr: |
          sum(rate(container_cpu_usage_seconds_total{container!=""}[5m])) by (pod)
          / sum(kube_pod_container_resource_limits{resource="cpu"}) by (pod)
          > 0.8          
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.pod }} CPU 使用率超过 80%"

      # 步骤2：goroutine 数量超过 1000
      - alert: GoroutineCountHigh
        expr: go_goroutines > 1000
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "goroutine 数量异常: {{ $value }}"

      # 步骤3：CPU 使用率持续上升（线性增长检测）
      - alert: PodCPURisingTrend
        expr: |
          deriv(rate(container_cpu_usage_seconds_total[10m])[30m:1m]) > 0          
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Pod CPU 呈上升趋势，可能存在泄露"

六、Linux 系统与 GNU 基础

6.1 用生活类比先建立直觉：Linux 是什么

把一辆能跑的车想象成一个完整操作系统——内核是发动机和底盘（真正驱动硬件的核心），Shell 是方向盘和仪表盘（你操作汽车的界面），GNU 工具是车里的工具箱（扳手、千斤顶），应用程序就是你用这辆车要做的事（拉货、载人）。

Linux 严格来说只是内核（Linus Torvalds 1991 年写出），而日常所说的"Linux 系统"（Ubuntu、CentOS 等）其实是"Linux 内核 + GNU 工具链 + 各种软件"的组合。这就像发动机本身不能跑，还得配上车身、轮胎、座椅才能上路。

GNU 项目的重要性（条目 19）：在 Linus 写出内核之前，Richard Stallman 发起的 GNU 项目已经写好了编译器（gcc）、Shell（bash）、编辑器（emacs）等大量自由软件，唯独缺一个能跑的内核。Linux 内核恰好补上了这个空缺，“GNU/Linux"才成为完整可用的系统。没有 GNU，Linux 内核只是一个跑不起来的发动机。

开源的优势（条目 18）：

• 透明可审计：任何人能看源码，安全漏洞更难被长期隐藏（对比闭源系统的"黑盒”）。
• 社区协作：全球开发者共同维护，bug 修复快。
• 自由定制：可裁剪出只含需要功能的极小系统（嵌入式、容器基础镜像）。
• 无厂商锁定：不被单一公司绑定，可自由迁移。

graph TB
    APP[应用程序
浏览器/数据库/Web服务]
    GNU[GNU 工具链
gcc / bash / coreutils]
    SH[Shell
bash 命令行界面]
    K[Linux 内核
进程/内存/文件系统/驱动]
    HW[硬件
CPU/内存/磁盘/网卡]
    APP --> GNU
    APP --> SH
    GNU --> K
    SH --> K
    K --> HW

桥接：Linux 不只是"一个操作系统名字"，而是"内核 + GNU 工具 + 应用"的协作体。理解这套分层后，我们来看 Linux 与它的"前辈"UNIX 有什么血缘和区别。

6.2 工程要点

UNIX 与 Linux 的区别（条目 2）

简单来说：UNIX 是"贵族血统的闭源商用系统"，Linux 是"继承 UNIX 设计思想但开源免费的分支"。Linux 并非 UNIX 的代码分支，而是重写，但遵循相同的 POSIX 接口标准，所以 UNIX 上编译的程序大多能迁移到 Linux。

Linux 内核与基本组件（条目 3、4、5）

**内核（Kernel）**是操作系统的核心，运行在最高特权级（Ring 0），负责：进程调度、内存管理、文件系统、设备驱动、网络栈。它向上提供系统调用（syscall）接口，应用程序通过 syscall 请求内核服务（如读文件、创建进程）。

Linux 体系结构（自上而下）：

用户空间（User Space）
  ├── 应用程序（浏览器、Shell）
  ├── GNU 工具（gcc、ls、cp）
  └── C 库（glibc，封装 syscall）
-------------------- 系统调用接口（syscall） --------------------
内核空间（Kernel Space）
  ├── 进程调度（Scheduler）
  ├── 内存管理（MM，含虚拟内存/分页）
  ├── 虚拟文件系统（VFS）
  ├── 网络栈（TCP/IP）
  └── 设备驱动（Driver）
-------------------- 硬件抽象层 --------------------
硬件（CPU/内存/磁盘/网卡）

基本组件包括：内核、Shell（命令解释器）、文件系统（ext4/xfs）、GNU 工具集、桌面环境、守护进程（daemon）。

⚠️ 新手必踩的坑： 经常有人把"Linux"和"GNU/Linux"混用。严谨说法：Linux 指内核，GNU/Linux 指完整系统。Stallman 因此坚持叫"GNU/Linux"，避免抹杀 GNU 项目的贡献。

考点总结：Linux 内核是系统的"大脑"，用户程序只能通过 syscall 与它通信；内核态与用户态的隔离是系统稳定的基石。

CLI、GUI 与 BASH（条目 15、16、17）

• CLI（Command Line Interface，命令行界面）：通过输入文本命令与系统交互，如终端里敲 ls、cd。适合批量、自动化、远程操作。
• GUI（Graphical User Interface，图形界面）：用窗口、按钮、鼠标操作，如 GNOME、KDE 桌面。适合日常桌面使用。
• BASH（Bourne Again Shell）：Linux 默认的 CLI 解释器（Shell 的一种），既能交互式敲命令，也能执行脚本（.sh 文件）。它向下调用内核 syscall，是用户与内核之间的"翻译官"。

三者的关系：GUI 和 CLI 都是用户操作系统的"入口"，CLI 背后由 Shell（通常是 bash）解释执行，BASH 是最常见的 Shell 实现。

BASH 与 DOS 的区别（条目 6）

考点总结：BASH 比 DOS 强大得多——核心是管道（|）和大小写敏感，面试常问"Linux 区分大小写吗"答案是区分。

Linux 开机启动过程（条目 7）

从按下电源到看到登录界面，经历以下阶段：

1. BIOS/UEFI：加电自检（POST），找到启动设备。
2. Bootloader（如 GRUB）：加载内核到内存（条目 14 的 LILO 也是同类，GRUB 的现代替代品）。
3. 内核初始化：解压、探测硬件、挂载根文件系统（initramfs）。
4. init 进程（PID=1）：现代系统用 systemd，负责拉起所有系统服务。
5. 系统服务与登录：启动 sshd、网络等，最后显示登录界面或 Shell。

graph LR
    A[BIOS/UEFI
加电自检] --> B[Bootloader
GRUB/LILO]
    B --> C[加载内核
到内存]
    C --> D[init 进程
PID=1 systemd]
    D --> E[启动系统服务
网络/SSH]
    E --> F[登录界面/Shell]

考点总结：启动链是 BIOS/UEFI → Bootloader → 内核 → init(PID=1) → 服务。PID=1 进程退出系统就崩了。

缺省运行级别（条目 8）

传统 SysV init 用"运行级别"（runlevel）表示系统状态，0-6：

• 0：关机
• 1：单用户模式（救援模式，仅 root）
• 3：多用户多终端（纯命令行，服务器常用）
• 5：图形界面（多用户+GUI）
• 6：重启

⚠️ 注意： 现代 systemd 已用 target 取代 runlevel（如 multi-user.target 对应 3，graphical.target 对应 5），但面试官常按老术语问，需知道二者对应关系。

考点总结：默认运行级别通常是 3（服务器命令行）或 5（桌面图形）；systemd 时代用 target 概念。

Root 账户与 LILO（条目 13、14）

• Root 账户：Linux 的超级管理员，UID=0，拥有系统所有权限（可删系统文件、改内核参数）。日常操作应避免直接用 root，用 sudo 临时提权更安全。
• LILO（LInux LOader）：早期的 Linux 引导加载程序，现基本被 GRUB 取代。作用是在开机时把内核加载进内存。

考点总结：root = UID 0 的超级用户；生产环境用 sudo 而非直接 root 登录以避免误操作。

交换空间（条目 12、OS 部分 17 重复）

**交换空间（Swap）**是一块磁盘区域（swap 分区或 swap 文件），当物理内存不足时，内核把不常用的内存页换出到磁盘，腾出 RAM 给活跃进程。它是"内存不够时向磁盘借空间"的机制，代价是磁盘比内存慢几个数量级。

注意：交换空间 ≠ 虚拟内存，但它是虚拟内存机制中"换页"的落盘载体。现代系统也用 zram（内存中压缩）替代部分 swap 以提升性能。

考点总结：swap 是内存的"应急磁盘缓冲区"，避免 OOM 直接杀进程，但速度极慢，频繁 swap 会导致系统卡顿（thrashing）。

系统日志文件（条目 10）

Linux 日志集中存放在 /var/log/：

# 步骤1：系统通用日志（旧版 syslog）
cat /var/log/messages

# 步骤2：认证相关（登录、sudo、ssh 失败）
cat /var/log/auth.log        # Debian/Ubuntu
cat /var/log/secure          # RHEL/CentOS

# 步骤3：内核日志
cat /var/log/kern.log

# 步骤4：系统启动和服务日志（systemd 时代推荐）
journalctl -xe

# 步骤5：某个服务日志（如 nginx）
tail -f /var/log/nginx/error.log

考点总结：/var/log/ 是日志大本营；现代系统首选 journalctl 查 systemd 日志。

安装多个桌面环境（条目 11）

可以装多个（如 GNOME + KDE），登录时选会话即可。帮助是：不同桌面适合不同场景（轻量 vs 功能全），便于在低端机和主力机间切换。缺点是占用更多磁盘、可能配置冲突。对服务器而言不需要桌面环境（省资源、减攻击面）。

考点总结：多桌面环境可共存、按需切换，但服务器一般不用 GUI 以省资源。

七、容器技术进阶（DevOps、虚拟化与 Docker 深入）

7.1 用生活类比先建立直觉：DevOps 是什么

传统软件交付像"接力赛"——开发写完代码扔给运维，运维部署出问题又扔回开发，双方互相甩锅（“开发环境能跑，生产跑不了”）。

DevOps 就像"把开发和运维合并成一个团队的足球队"：开发写完代码，自动化流水线（CI/CD）立刻打包、测试、部署，运维的经验（监控、告警）也前置到开发阶段。目标是"更快、更稳地交付"。

• 为什么需要 DevOps（条目 1）：缩短交付周期、减少手工部署出错、快速回滚。
• DevOps 优势（条目 3）：自动化替代手工、频繁小步发布降低风险、开发与运维协作透明。
• CI 服务用途（条目 4）：持续集成（Continuous Integration）在每次 git push 时自动拉代码、编译、跑测试，尽早发现 bug。常见：GitHub Actions、GitLab CI、Jenkins。

graph LR
    DEV[开发 push 代码] --> CI[CI 服务
自动构建+测试]
    CI -->|通过| CD[CD 自动部署
到测试/生产]
    CD --> MON[监控告警
Prometheus]
    MON -->|异常| DEV

桥接：DevOps 是文化+工具链，Docker 是其中"环境一致性"的关键一环——一次构建、到处运行，让 CI/CD 不再受"环境问题"困扰。

7.2 工程要点

虚拟化技术基础（条目 16、17、21）

• 虚拟化技术：在一台物理机上用软件模拟出多台"虚拟机器"，每台都有独立的操作系统。核心技术是虚拟管理层（Hypervisor，条目 17）——它直接跑在硬件上（Type-1，如 KVM、VMware ESXi）或跑在宿主 OS 上（Type-2，如 VirtualBox），负责把 CPU/内存/IO 虚拟分配给各虚拟机。
• 半虚拟化（Paravirtualization，条目 21）：虚拟机"知道"自己被虚拟化，通过 Hypervisor 提供的特殊接口（如 virtio）直接请求资源，绕过繁琐的硬件模拟，性能比"完全虚拟化"更好。代价是客户机 OS 需修改内核配合。

Docker 与虚拟机的区别 / 容器化与虚拟化的优缺点（条目 22、28）

优点对比：容器轻量、启动快、密度高；虚拟机隔离更彻底、安全性更高（内核级隔离）。 缺点对比：容器共享内核，一个内核漏洞影响所有容器；虚拟机启动慢、占资源多。

考点总结：容器共享内核所以轻快，代价是隔离性弱于虚拟机；选型看"要隔离强度还是密度/速度"。

Docker Hub 与镜像分发（条目 9）

Docker Hub 是官方公共镜像仓库（类似 GitHub 之于代码、Maven 中央仓库之于 jar）。docker pull nginx 默认从 Docker Hub 拉取。企业常用私有仓库（Harbor、AWS ECR）。镜像通过 tag 区分版本，不指定 tag 默认 latest（不推荐生产用 latest，应锁定版本）。

考点总结：Docker Hub 是公共镜像仓库；生产应锁定具体 tag，避免 latest 漂移带来不可复现部署。

容器的生命周期状态（条目 10）

一个容器在任意时刻处于以下状态之一：

• created：已创建但未启动（docker create）
• running：运行中（docker start / docker run）
• paused：暂停（内存冻结，docker pause）
• stopped / exited：已停止
• deleted：已删除（docker rm）

graph LR
    C[created] --> R[running]
    R -->|docker pause| P[paused]
    P -->|docker unpause| R
    R -->|docker stop| S[stopped]
    S -->|docker start| R
    S -->|docker rm| D[deleted]

考点总结：容器状态机 created→running→stopped→deleted；docker pause 冻结内存而非停止进程。

无状态 vs 有状态应用（条目 13、24）

• 无状态（Stateless）：应用不保存本地状态，请求可路由到任意副本（如 Web API、网关）。最适合 Docker——可随意扩容、缩容、调度到任意节点。
• 有状态（Stateful）：需要持久化数据或稳定身份（如数据库、消息队列）。

有状态应用实践（条目 24）：用 Volume 把数据持久化到宿主或网络存储（容器删除数据不丢）；用 StatefulSet（K8s）保证 Pod 有稳定网络标识和独立持久卷；最适合场景是数据库、缓存等有状态中间件（此时容器只承载进程，数据落外部存储）。

考点总结：无状态应用最契合容器（易扩容）；有状态应用务必用 Volume/StatefulSet 把数据外置，否则容器一删数据全失。

Docker Swarm（条目 18）

Docker Swarm 是 Docker 原生的集群编排工具，把多台 Docker 主机组成一个"swarm 集群"，用 docker service 部署可横向扩展的服务，内置负载均衡和故障转移。相比 K8s，Swarm 更轻量、学习成本低，但生态和复杂度不及 K8s。

考点总结：Swarm 是 Docker 原生轻量编排；生产大规模场景多被 K8s 取代，但小集群够用。

孤儿卷及清理（条目 20）

孤儿卷（dangling/orphan volume）：容器被删除后，其挂载的匿名 Volume 没有被自动删除，变成"无主"数据堆积占磁盘。

# 步骤1：列出所有 volume
docker volume ls

# 步骤2：找出孤儿卷（无容器引用，dangling=true）
docker volume ls -f dangling=true

# 步骤3：删除孤儿卷，释放磁盘
docker volume prune

考点总结：容器删除不自动删 Volume，用 docker volume prune 清理孤儿卷防磁盘撑爆。

Dockerfile 进阶：ONBUILD 指令（条目 23）

ONBUILD 让指令"延迟触发"：它在当前镜像构建时不执行，而是当别的 Dockerfile 以本镜像为 FROM 基础镜像时才执行。常用于制作"基础模板镜像"（如官方 python:onbuild），让下游镜像自动触发 ONBUILD COPY . /app 等动作。

# 基础镜像中定义 ONBUILD：下游 FROM 它时才执行
FROM python:3.11-slim
ONBUILD COPY . /app       # 下游构建时才复制源码
ONBUILD RUN pip install -r /app/requirements.txt

考点总结：ONBUILD 是"延迟到下游镜像构建才触发"的指令，适合做通用基础镜像模板。

跨平台运行 Docker（条目 25、26）

• Windows 原生 Docker 容器（条目 25）：可以。Windows Server 支持原生 Windows 容器（基于 Windows 内核隔离），也有 Linux 容器需借助 WSL2。
• 非 Linux 平台运行 Docker（条目 26）：macOS、Windows 上 Docker 实际上跑在一个轻量 Linux 虚拟机里（Docker Desktop 用 HyperKit / WSL2 / Hyper-V）。Docker 守护进程（daemon）依赖 Linux 内核的 namespace/cgroup，所以非 Linux 平台必须有一个 Linux VM 作为宿主。

graph TB
    subgraph "macOS / Windows"
        DD[Docker Desktop]
        VM[轻量 Linux 虚拟机
提供 Linux 内核]
        DD --> VM
        VM -->|namespace/cgroup| C[容器]
    end

考点总结：Docker 本质依赖 Linux 内核，非 Linux 平台靠"内嵌 Linux 虚拟机"跑容器；Windows Server 可原生跑 Windows 容器。

适应多种运行环境（条目 29）

用以下手段让同一镜像/编排适配开发、测试、生产：

• 环境变量 + 配置挂载：镜像固定，配置通过 -e 或 ConfigMap/Secret 注入。
• 多阶段构建产出环境无关的最小镜像。
• Docker Compose / K8s 多环境 overlay：同一份 service 定义，不同环境叠加不同配置。

考点总结：用"镜像固定 + 配置外置注入"实现一套镜像跨环境运行，是十二因子应用的核心理念。

为什么 Docker Compose 不等待依赖就绪（条目 30）

docker-compose up 默认只按依赖顺序启动容器（depends_on 控制启动顺序），但不检测依赖服务是否"真正可用"（如数据库完成初始化、端口可连接）。因为"启动完成"和"服务就绪"不同——容器进程起来 ≠ 应用能接请求。

解决：用 wait-for-it.sh / dockerize / 应用自身重试 等工具在入口脚本里等待依赖端口/健康检查通过再启动主进程；或 K8s 中用 initContainer + 就绪探针 实现真正等待。

# 用 wait-for-it 等待 MySQL 端口就绪再启动应用
./wait-for-it.sh db:3306 -- npm start

考点总结：depends_on 只管启动顺序不管就绪；用 wait-for-it 或应用重试等待依赖真正可用。

八、操作系统原理进阶

8.1 用生活类比先建立直觉

把 CPU 比作一个收银台，多个顾客（任务）要结账。

• 并发（Concurrency，条目 3）：一个收银台，多个顾客轮流结账——同一时刻只有一人在结账，但宏观上"都在推进"。对应单核交替执行多任务。
• 并行（Parallel）：多个收银台同时结账，同一时刻真的有多人在结账。对应多核同时执行。

**协程（Coroutine，条目 2）**像"同一个人大脑一次只想一件事，但能快速在多个任务间切换"——协程是用户态轻量"线程"，由程序（runtime）自己调度，切换不进内核，开销极小（Go 的 goroutine 就是协程）。

graph TB
    subgraph 并发_单核
        A1[任务A] --> A2[任务B] --> A3[任务A] --> A4[任务B]
    end
    subgraph 并行_多核
        B1[任务A
核1] 
        B2[任务B
核2]
    end

桥接：并发是"交替推进"的结构，并行是"同时执行"的能力；协程是在并发基础上把切换成本压到最低的 user-space 调度。理解了这些，再看内核是如何真正切换任务的。

8.2 工程要点

协程与线程的区别（条目 2）

考点总结：协程是用户态调度、切换极轻；goroutine 即 Go 的协程实现，百万级并发靠它。

进程/线程切换流程与虚拟地址空间切换耗时（条目 4、5）

切换流程：保存当前任务上下文（寄存器、PC、栈指针）→ 调度器选下一个任务 → 恢复其上下文 → 执行。

为什么虚拟地址空间切换耗时（条目 5）：进程切换要换页表（CR3 寄存器指向新页表），导致 TLB（地址翻译缓存）全部失效，接下来大量内存访问要重新走页表查物理地址，cache 命中率骤降，因此比线程切换（共享地址空间、不换页表）慢得多。这也是线程比进程轻的核心原因。

考点总结：进程切换比线程慢的元凶是 TLB 失效导致页表重查；线程共享地址空间所以切换更轻。

进程状态与调度策略（条目 13、12）

进程状态（Linux 常见）：

调度策略：

• SCHED_OTHER（CFS，完全公平调度）：默认，按权重公平分配 CPU。
• SCHED_FIFO / SCHED_RR：实时调度，优先级高，用于低延迟场景。
• SCHED_BATCH / SCHED_IDLE：批处理/极低优先级。

stateDiagram-v2
    [*] --> R: 创建/fork
    R --> S: 等待资源
    S --> R: 资源就绪/被唤醒
    R --> D: 发起磁盘IO
    D --> R: IO完成
    R --> Z: 退出且父未wait
    Z --> [*]: 父wait回收
    R --> T: 收到SIGSTOP
    T --> R: 收到SIGCONT

考点总结：Z 状态表示父进程没回收子进程，会泄漏 PID；实时任务用 SCHED_FIFO/RR，普通任务用 CFS。

临界区、进程间同步、死锁（条目 10、7、11）

• 临界区（Critical Section，条目 10）：访问共享资源（如全局变量、共享内存）的那段代码。冲突解决：用**互斥锁（mutex）/ 信号量（semaphore）**保证同一时刻只有一个任务进入。
• 进程间同步方式（条目 7）：信号量（semaphore）、互斥量、条件变量、管程（monitor）、屏障（barrier）、消息传递。
• 死锁（Deadlock，条目 11）：多个进程互相持有对方需要的资源并等待，谁都推进不了。

死锁四个必要条件（缺一不可，破坏任一即可避免）：

1. 互斥：资源只能被一个进程占用。
2. 占有并等待：持有资源的同时等待别的资源。
3. 不可抢占：资源不能被强行夺走。
4. 循环等待：形成等待环路（A等B、B等A）。

预防思路：按固定顺序加锁、一次性申请所有资源、超时放弃、银行家算法。

考点总结：死锁四条件"互斥/占有等待/不可抢占/循环等待"；破坏任一即可解除。加锁顺序一致是预防死锁的常用手段。

内存管理：虚拟内存 / 分页 / 分段 / 页面替换（条目 19、14、15、16、页面替换）

• 虚拟内存（条目 19）：每个进程拥有独立的、连续的虚拟地址空间，由 MMU 映射到物理内存。好处：隔离（进程互不干扰）、用户视角内存无限（可超物理内存，配合 swap）、共享库只需加载一份。
• 分页（Paging，条目 14）：把虚拟和物理内存都切成固定大小的"页"（通常 4KB），用页表记录映射。简单、无外部碎片，但有少量内部碎片。
• 分段（Segmentation，条目 15）：按逻辑意义（代码段、数据段、栈段）划分不定长区域，有段号+段内偏移。符合程序逻辑，但会产生外部碎片。
• 分页 vs 分段（条目 16）：

现代 OS（如 Linux）以分页为主，分段基本被弱化（段仅作权限划分）。

• 页面替换算法（页面替换）：内存满时把哪个页换出？常见：
  • OPT（最佳）：换未来最久不用的（理论最优，不可实现，作基准）。
  • FIFO：先进先出，简单但可能换掉常用页（Belady 异常）。
  • LRU（最近最少使用）：换最久没访问的，近似 OPT，实际常用。
  • Clock（二次机会）：LRU 的近似，环形扫描带访问位。

graph LR
    VM[虚拟地址空间] --> MMU[MMU
页表映射]
    MMU --> RAM[物理内存页框]
    RAM -->|满时| PR[页面替换算法
LRU/FIFO/Clock]
    PR -->|换出不常用页| SWAP[Swap 磁盘]

考点总结：虚拟内存靠页表映射实现隔离与超卖；分页无外部碎片、分段有；换页常用 LRU；分段在现代 Linux 已弱化。

硬链接与软链接（条目 21）

考点总结：硬链接共享 inode（删原文件不影响），软链接是指向路径的独立文件（原删则失效）。ln -s 才是"快捷方式"那种。

中断：处理过程与轮询区别（条目 22、23）

中断处理过程（条目 22）：

1. 硬件/软件触发中断，CPU 保存当前上下文（压栈）。
2. 查中断向量表，跳转到对应 ISR（中断服务程序）。
3. ISR 处理（通常上半部快处理、下半部延后）。
4. 恢复上下文，返回被中断的程序。

中断 vs 轮询（条目 23）：

• 中断：事件发生时硬件"主动通知"CPU，CPU 平时干别的，效率高、延迟低，但高频中断会打断正常任务。
• 轮询：CPU 不断循环查询设备状态，简单但不干活的等待浪费 CPU，适合确定性强、高频场景。

考点总结：中断是"被动等通知"，轮询是"主动不停问"；中断效率高但有上下文切换开销。

缓冲区溢出（条目 18）

缓冲区溢出：向固定大小的缓冲区（如 C 语言的数组/栈）写入超过其容量的数据，越界覆盖相邻内存（如返回地址），可导致程序崩溃或被攻击者植入恶意代码。

危害：程序崩溃（DoS）、执行任意代码（提权攻击，如栈溢出覆盖返回地址跳到 shellcode）、数据破坏。防护：边界检查、栈保护（canary）、DEP（数据执行保护）、ASLR（地址随机化）。Go 这类内存安全语言默认不出现此类问题。

考点总结：缓冲区溢出是 C/C++ 经典安全漏洞，靠越界写入破坏内存；现代语言/栈保护机制（canary/ASLR/DEP）缓解。

九、Linux 日志排查实战

9.1 用生活类比先建立直觉

把线上服务想象成一辆行驶中的汽车，日志就是它的"黑匣子"——油门踩多深、哪里报了故障码、什么时候熄火，全记在里面。当服务半夜告警，你没法钻进车厢看现场，只能靠黑匣子（日志）回放事故过程。

排查日志的核心思路和"在监控录像里找凶手"一样：先用粗筛缩小时间窗口，再用精筛定位关键帧，最后提取细节还原作案手法。grep 负责"按关键字找录像片段"，sed/awk 负责"把画面里无关的人打码、只保留关键信息"，管道 | 就是把上一步的结果喂给下一步，像流水线一样逐层逼近真相。

graph LR
    LOG[应用日志 app.log
几GB文本] --> G[grep 粗筛
错误行/关键字]
    G --> E[grep -E 正则精筛
ERROR|panic|timeout]
    E --> A[awk 提取字段
时间/IP/耗时]
    A --> OUT[定位错误根因
哪个接口/哪台机器/几点]

桥接： 从"黑匣子回放"到"日志排查"——grep 是定位问题行的第一刀，sed/awk 是把海量日志压缩成可读摘要的手术刀，管道把它们串成一条自动化的排查流水线。下面看真实可运行的命令。

9.2 工程要点

grep 常用参数速查

# 准备一份示例日志（实际排查时通常是 cat 线上文件）
cat > /tmp/app.log <<'EOF'
2024-03-01 10:00:01 INFO  user login success ip=10.0.0.1
2024-03-01 10:00:02 ERROR db query timeout ip=10.0.0.2
2024-03-01 10:00:03 WARN  retry connection ip=10.0.0.2
2024-03-01 10:00:04 error disk full ip=10.0.0.3
2024-03-01 10:00:05 PANIC nil pointer ip=10.0.0.2
EOF

# 步骤1：-n 显示行号，-i 忽略大小写（匹配 ERROR 和 error）
grep -ni "error" /tmp/app.log
# 输出：
# 2:2024-03-01 10:00:02 ERROR db query timeout ip=10.0.0.2
# 4:2024-03-01 10:00:04 error disk full ip=10.0.0.3

# 步骤2：-r 递归搜索目录下所有文件（排查时常用 -r /var/log）
grep -rn "PANIC" /tmp/

# 步骤3：-E 启用扩展正则（| 表示"或"，不需转义）
grep -nE "ERROR|PANIC|timeout" /tmp/app.log
# 输出：行2 ERROR、行5 PANIC、行2 timeout

# 步骤4：-A 3 显示匹配行及其后 3 行（After），看错误上下文
grep -nA3 "PANIC" /tmp/app.log
# 输出：行5 PANIC + 其后（示例无后续行，真实日志会带堆栈）

# 步骤5：-B 2 显示匹配行及其前 2 行（Before），看错误发生前的动作
grep -nB2 "disk full" /tmp/app.log

# 步骤6：-C 2 显示匹配行前后各 2 行（Context），最常用
grep -nC2 "timeout" /tmp/app.log

# 步骤7：-c 只统计匹配行数（快速看错误量级）
grep -c "ERROR" /tmp/app.log

# 步骤8：-v 反向匹配（排除噪音，如排除健康检查的 INFO 行）
grep -v "INFO" /tmp/app.log

# 步骤9：-o 只输出匹配的部分（配合正则提取 IP）
grep -oE "ip=[0-9.]+" /tmp/app.log
# 输出：ip=10.0.0.1 / ip=10.0.0.2 / ip=10.0.0.3 ...

sed / awk 过滤与统计

# 步骤1：sed 提取某时间段的日志（删除 10:00:02 之前的行，保留之后）
sed -n '/10:00:02/,$p' /tmp/app.log

# 步骤2：sed 替换脱敏（把真实 IP 打成 ***，避免日志外泄）
sed 's/ip=[0-9.]\+/ip=***/g' /tmp/app.log

# 步骤3：awk 按列提取（默认空格分隔，打印第1列日期+第3列级别）
awk '{print $1, $3}' /tmp/app.log
# 输出：2024-03-01 INFO / 2024-03-01 ERROR ...

# 步骤4：awk 条件过滤（只打印第3列为 ERROR/PANIC 的行，并统计）
awk '$3=="ERROR" || $3=="PANIC" {print; cnt++} END{print "错误总数:", cnt}' /tmp/app.log

# 步骤5：awk 按分钟聚合错误数（提取时间到分钟，统计每分钟错误条数）
awk '/ERROR|PANIC/{split($2,t,":"); print $1" "t[1]":"t[2]}' /tmp/app.log \
  | sort | uniq -c

管道组合定位真实错误（实战套路）

# 套路1：找最近的 500 错误，并显示前后上下文，再提取请求路径
grep -nC5 " 500 " /var/log/nginx/access.log | grep -oE "/api/[a-z]+"

# 套路2：按错误类型分组计数，按数量降序排列（快速定位 Top 错误）
grep -oE "ERROR|PANIC|WARN|timeout" /tmp/app.log | sort | uniq -c | sort -rn

# 套路3：找出响应最慢的 10 个接口（假设第 10 列是耗时 ms）
awk '{print $10, $7}' /var/log/nginx/access.log | sort -rn | head -10

# 套路4：实时跟踪日志，只显示错误行（排查线上故障时常驻）
tail -f /var/log/app.log | grep --line-buffered -iE "ERROR|PANIC|exception"

# 套路5：跨多个压缩历史日志搜索（zgrep 直接读 .gz）
zgrep -nE "OutOfMemory" /var/log/app.log.*.gz

⚠️ 新手必踩的坑： tail -f 配合管道 grep 时，grep 默认会缓冲输出，可能几秒甚至几分钟才刷出一行，让人误以为没错误。解决：加 --line-buffered（GNU grep）或用 stdbuf -oL grep。另外 --color=auto 在管道里会失效，需要时显式 --color=always（但会带颜色转义字符，建议写文件时别加）。

十、线程调度

10.1 用生活类比先建立直觉

把 CPU 想象成一个公共厨房，每个线程就是一位想用厨房做饭的住户。厨房同一时刻只能容一个人（单核），多核则是多个灶台。

• 时间片（Time Slice）：物业规定每人最多用厨房 10 毫秒，时间一到就必须让给别人——这保证了没人能独占厨房，大家都能轮到。
• 优先级 nice 值：有人手头急（高优先级，nice 值小，甚至为负），物业让他插队多用一会儿；有人不急（低优先级，nice 值大，19 最大），就少排点。nice 取值范围 -20（最优先）~ 19（最不优先），默认 0。
• CFS 完全公平调度器：物业不再简单"轮流"，而是给每人记一本账（vruntime = 虚拟运行时间），谁"用厨房最少"就优先让谁进——这样长期来看每个人占用的 CPU 时间完全公平。

用户态线程 vs 内核态线程的映射：Go 的 goroutine 是"住户自己记的排队表"（用户态，runtime 管），而真正能进厨房的必须是"物业登记的正式工"（内核线程 LWP）。最常见的模型是 1:1——每创建一个用户线程（pthread），内核就对应创建一个内核线程，由内核直接调度。

graph TB
    subgraph CFS调度器
        RB[红黑树
按 vruntime 排序]
        CFS[每次选 vruntime 最小者运行
运行后 vruntime 增加]
    end
    CFS --> RB
    RB -->|出队运行| T1[线程A
vruntime=120]
    RB -->|出队运行| T2[线程B
vruntime=80]
    RB -->|出队运行| T3[线程C
vruntime=200]
    CFS -->|时间片用完/主动让出| RB

桥接： 从"公共厨房排队"到"线程调度"——CFS 用 vruntime 红黑树实现"谁用得少谁先上"的公平调度，nice 值微调权重，时间片控制单次最长占用。理解了内核调度，再看用户线程如何映射到内核线程。

10.2 工程要点

用户态与内核态线程的映射模型

Linux 的 pthread 采用 1:1 模型：每次 pthread_create 都向内核申请一个 LWP（轻量级进程），调度完全由内核 CFS 负责。

graph LR
    subgraph 用户态
        UT1[pthread 线程1]
        UT2[pthread 线程2]
        UT3[pthread 线程3]
    end
    subgraph 内核态_LWP_1:1模型
        KT1[内核线程 LWP1]
        KT2[内核线程 LWP2]
        KT3[内核线程 LWP3]
    end
    UT1 --> KT1
    UT2 --> KT2
    UT3 --> KT3
    KT1 -->|CFS 调度| CPU[CPU 核]
    KT2 --> CPU
    KT3 --> CPU

调度策略与优先级

# 步骤1：查看进程调度策略与优先级（普通进程一般是 TS = SCHED_OTHER）
ps -eo pid,comm,cls,pri,ni | head

# 步骤2：启动一个低优先级任务（nice 值 10，更"谦让"）
nice -n 10 ./cpu_intensive_job

# 步骤3：修改运行中进程的 nice 值（需要权限，renice）
renice -n 5 -p 12345

# 步骤4：用 chrt 设置实时调度策略（SCHED_FIFO，优先级 50）
# 注意：实时策略优先级高于所有普通进程，设错会导致系统卡死
chrt -f 50 ./realtime_task

# 步骤5：Go 程序中设置当前 goroutine 所属线程优先级（需 syscall）
# 仅示例，生产环境慎用实时优先级

⚠️ 新手必踩的坑： nice 值只能降低自己优先级（调大），普通用户不能把 nice 调成负数（提权需要 root）。另外 SCHED_FIFO 实时线程如果写了死循环且不主动让出 CPU，会饿死所有普通进程，连 kill 都敲不进去——所以实时策略只在真正需要低延迟的硬件控制场景使用。

十一、进程间通信 IPC

11.1 用生活类比先建立直觉

回到"别墅与住户"模型：不同别墅（进程）之间内存完全隔离，要交流得靠"外部渠道"。Linux 提供了 6 种主要渠道，就像 6 种联系方式：

• 管道（pipe）：两栋楼之间拉一根专用水管，水只能单向流（匿名管道，父子进程专用）；命名管道（FIFO）则是楼下公共水管，任何知道位置的人都能接。
• 消息队列：前台放一个信箱，A 写好信投进去，B 有空来取，信按先后顺序排队。
• 共享内存：两栋楼之间开一扇"公共窗户"，双方直接看同一块空间，最快但得自己加锁防抢。
• 信号（signal）：物业大喇叭广播"要停电了"（SIGTERM）或"立即断电"（SIGKILL），只能传极简消息（一个编号）。
• 信号量（semaphore）：公共洗手间的"占用指示灯"，控制同时只能用几个人，用来做同步/互斥。
• socket：打电话，不仅能楼间打，还能打给另一个城市（跨网络/跨主机）。

graph TB
    subgraph 同一台主机内
        PIPE[管道
匿名pipe/命名FIFO
字节流,单向]
        MSG[消息队列
结构化消息,有边界]
        SHM[共享内存
最快,需自己加锁]
        SIG[信号
异步通知,仅编号]
        SEM[信号量
计数器,做同步互斥]
    end
    SOCK[socket
跨网络/跨主机
最通用]
    PIPE --> SHM

桥接： 从"别墅联系方式"到"IPC"——按"速度/复杂度/跨主机能力"三维度选型：要最快选共享内存（但自己管锁），要简单通知选信号，要跨机器只能选 socket。下面用对比表看清各自适用场景。

11.2 工程要点

六种 IPC 方式对比

代码示例：管道与共享内存

// ===== 匿名管道：用 os/exec 模拟 shell 的 cmd1 | cmd2 =====
package main

import (
    "fmt"
    "os/exec"
)

func pipeDemo() {
    // 步骤1：第一个命令 grep 从输入过滤 "error"
    grep := exec.Command("grep", "error")
    // 步骤2：第二个命令 wc -l 统计行数
    wc := exec.Command("wc", "-l")
    // 步骤3：把 grep 的标准输出接到 wc 的标准输入（这就是管道）
    wc.Stdin, _ = grep.StdoutPipe()
    // 步骤4：启动管道末端
    wc.Start()
    // 步骤5：把数据喂给 grep 的输入，并等待整条管道结束
    grep.Stdin = strings.NewReader("error: disk full\nok: fine\nerror: timeout\n")
    grep.Start()
    grep.Wait()
    wc.Wait()
}

/* ===== 共享内存 + 信号量（System V，C 伪代码展示概念）===== */
// 写进程：创建共享内存段，写入数据
int shmid = shmget(KEY, 4096, IPC_CREAT | 0666); // 步骤1：申请共享内存
char *shm = shmat(shmid, NULL, 0);               // 步骤2：挂接到进程地址空间
sem_wait(sem);                                    // 步骤3：用信号量加锁
strcpy(shm, "hello from writer");                 // 步骤4：写入（双方看到同一块）
sem_post(sem);                                    // 步骤5：解锁
// 读进程：同样的 KEY 拿到同一段，直接读 shm 即可，零拷贝

⚠️ 新手必踩的坑： 共享内存是最快的 IPC，但内核不提供任何同步——两个进程同时写会直接数据竞争（race），必须配合信号量/互斥锁。这也是 Go channel 比裸共享内存安全的原因：channel 底层封装了锁和拷贝，用户无需手动同步。

十二、孤儿进程与僵尸进程

12.1 用生活类比先建立直觉

把进程父子关系想象成"家长带孩子"：

• 僵尸进程（Zombie）：孩子（子进程）意外去世了，但家长（父进程）一直没来料理后事（wait 回收）。孩子虽然已经"死"了，但在派出所（内核）的户口（PID）还没注销，变成一个"既死又占着名额"的僵尸。僵尸不占内存、不占 CPU，只占一个 PID 号。
• 孤儿进程（Orphan）：家长（父进程）自己先走了，孩子还在跑。孩子变成"没爹的孩子"，内核把它**过继给 1 号进程（init/PID 1）**收养，由 init 负责等它结束后回收。孤儿进程一切正常，不是问题。

一句话：僵尸是"父不管尸"，孤儿是"父先走"，孤儿被 init 收养所以无害，僵尸没人收所以有害。

stateDiagram-v2
    [*] --> Child: fork 创建子进程
    Child --> Running: 子进程运行
    Running --> Zombie: 子进程退出
但父进程未 wait
    Zombie --> [*]: 父进程 wait 回收
PID 释放（无害）
    Running --> Orphan: 父进程先退出
    Orphan --> Adopted: 被 init/PID1 收养
    Adopted --> [*]: init wait 回收
（正常，无害）

桥接： 从"家长与孩子"到"进程状态"——子进程退出后内核保留其退出状态，等父进程 wait 读取；父进程若先死，子进程被 init 接管自动被回收。理解了产生原因，再看危害与避免手段。

12.2 工程要点

产生原因与危害

避免方法一：父进程正确回收（wait/waitpid）

// 正确写法：父进程用 SIGCHLD 信号异步回收，避免僵尸堆积
#include <signal.h>
#include <sys/wait.h>

void reap_child(int sig) {
    // 步骤1：循环 waitpid 直到没有更多已退出子进程（-1 表示任意子进程）
    // WNOHANG 表示非阻塞，没有可回收的立即返回
    while (waitpid(-1, NULL, WNOHANG) > 0) {
        // 步骤2：每回收一个就继续循环，防止信号合并导致漏收
    }
}

int main() {
    signal(SIGCHLD, reap_child); // 步骤3：子进程退出时内核发 SIGCHLD
    if (fork() == 0) { /* 子进程干活后 exit */ }
    // 父进程继续运行，僵尸会被 reap_child 即时回收
    return 0;
}

避免方法二：fork 两次（守护进程经典手法）

// 两次 fork：让"干活的孩子"变成孤儿被 init 收养，从而绝不产生僵尸
pid_t pid = fork();          // 第一次 fork
if (pid == 0) {
    pid_t pid2 = fork();     // 第二次 fork
    if (pid2 > 0) _exit(0);  // 中间父进程立刻退出
    // 孙子进程（pid2==0）的父进程已退出 → 被 init 收养
    // 它退出时由 init 自动 wait，不会变成任何进程的僵尸
    do_work();
    _exit(0);
}
waitpid(pid, NULL, 0);       // 原始父进程只回收"中间父进程"这一个

排查与清理命令

# 步骤1：查看僵尸进程（STAT 为 Z）
ps aux | awk '$8=="Z"' 

# 步骤2：统计僵尸数量
ps aux | awk '{print $8}' | grep -c Z

# 步骤3：僵尸无法直接 kill（它已死），只能杀/重启其父进程让其被 init 收养后回收
# 先找僵尸的父进程 PPID
ps -o pid,ppid,stat,comm -C <僵尸进程名>
# 再重启父进程（如父进程是业务程序，发 SIGTERM 让其优雅退出）
kill -15 <父进程PPID>

⚠️ 新手必踩的坑： kill -9 杀不掉僵尸进程——僵尸已经死了，kill 的目标是活体。唯一解法是让它的父进程去 wait，或者杀掉父进程让 init 接管回收。所以预防僵尸的关键永远是"父进程必须回收子进程"，而不是事后强杀。

十三、常用排查命令

13.1 用生活类比先建立直觉

服务器像一栋大楼，排查命令就是你的"巡检工具箱"：

• 端口占用排查：看哪间办公室（端口）被哪个公司（进程）占着，防止冲突。
• CPU 负载：看电梯（CPU）排队的人多不多，load average 就是"过去 1/5/15 分钟平均排队长度"。
• 内存占用：看仓库（内存）还剩多少货位，不够了就得往地下车库（swap）堆。
• 发信号：向某个公司（进程）广播"下班"（SIGTERM）或"立刻清场"（SIGKILL）。

13.2 工程要点

查看端口占用

# 方法1：lsof 查看谁占用某端口（-i 指定网络，-P 不解析端口名，-n 不解析主机名）
lsof -i :8080 -P -n
# 输出：COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
#       myapp   1234 root   3u  IPv4  12345      0t0  TCP *:8080 (LISTEN)

# 方法2：netstat 查看所有监听端口（-t TCP -u UDP -n 数字 -l 监听 -p 进程）
netstat -tunlp | grep 8080

# 方法3：ss（现代推荐，比 netstat 快，来自 iproute2）
ss -tlnp | grep 8080        # -t TCP -l 监听 -n 数字 -p 进程
ss -tunlp                   # 查看全部 TCP/UDP 监听端口

查看 CPU 负载

# 步骤1：uptime 看 load average（1/5/15 分钟平均就绪+运行队列长度）
uptime
# 输出：load average: 1.05, 0.90, 0.80
# 解读：单核机器 load=1 表示刚好满载；4 核机器 load=4 才满。超过核数即排队

# 步骤2：top 实时看（%Cpu 行：us 用户 / sy 系统 / id 空闲 / wa IO等待）
top
# 按 P 按 CPU 排序，按 M 按内存排序，按 1 展开所有核

# 步骤3：查看 CPU 核数（load average 要结合核数解读）
nproc

查看内存占用

# 步骤1：free 看整体内存（-h 人类可读）
free -h
# 输出：              total  used   free   shared  buff/cache  available
#       Mem:          7.7Gi  2.1Gi  3.2Gi   120Mi      2.4Gi      5.0Gi
# 关注 available 列：真正可用的内存（含可回收的 cache）

# 步骤2：top 里看各进程内存占比（RES 常驻集，%MEM 占比）
top -o %MEM        # 按内存占用降序

# 步骤3：查看某进程详细内存映射
pmap -x 12345

向进程发送信号

# 步骤1：kill 按 PID 发信号（默认 SIGTERM=15，建议先礼后兵）
kill 12345
# 步骤2：kill -9 强制（SIGKILL，内核直接杀，不给清理机会，慎用）
kill -9 12345

# 步骤3：killall 按进程名发信号（同名多个进程一起发）
killall -15 nginx

# 步骤4：pkill 按模式匹配发信号（支持正则，更灵活）
pkill -15 -f "myapp.*worker"

# 步骤5：查看所有信号编号
kill -l

SIGTERM vs SIGKILL 区别：

graph LR
    P[进程] -->|收到 SIGTERM| H[执行 atexit/defer
关连接/存盘]
    H --> EXIT[优雅退出]
    P -->|收到 SIGKILL| KILL[内核直接回收
不执行任何清理]
    KILL --> DEAD[强制死亡]

⚠️ 新手必踩的坑： 生产环境永远先 kill -15 再等几秒，确认没退才 kill -9。SIGKILL 会跳过所有清理（数据库连接不关、临时文件不删、文件锁不释放），可能导致下次启动数据损坏。Docker 的 docker stop、K8s 的 terminationGracePeriodSeconds 默认都是先 SIGTERM 等待宽限期再 SIGKILL，程序要监听 SIGTERM 做优雅退出。

十四、Git：merge 与 rebase

14.1 用生活类比先建立直觉

你和同事在两条平行的分支上改同一份文档：

• merge（合并）：像把两份修改"装订成一本合订本"——保留两人在各自分支上的所有历史，并在汇合处贴一张"合并说明"标签。历史是真实发生过的样子，有分叉也有汇合，但看起来像藤蔓缠绕。
• rebase（变基）：像把你后来的修改"撕下来，重新贴到同事最新进度的后面"——让你的提交看起来像是"在最新主干上顺次写出来的"。历史变成一条直线，干净好读，但改写了提交的基底（父节点），原本的提交哈希变了。

核心区别一句话：merge 保留真实历史（不改写），rebase 改写历史（更线性整洁）。

gitGraph
    commit id: "C0"
    commit id: "C1" tag: "main"
    branch feature
    checkout feature
    commit id: "F1"
    commit id: "F2"
    checkout main
    commit id: "M1"
    merge feature id: "MERGE" tag: "merge后"

上面是 merge 的效果（出现一个合并节点 MERGE）。rebase 则是把 F1、F2 “挪"到 M1 之后，线性排列，不生成合并节点。

14.2 工程要点

merge 与 rebase 对比

使用顺序与场景

# 场景A：功能分支开发完，合入主干（用 merge，保留真实历史）
git checkout main
git merge feature          # 生成合并提交，feature 的历史完整保留
# 若想保留"合并提交"这个节点（即使 fast-forward 可行也强制建节点）：
git merge --no-ff feature  # --no-ff 禁用快进，便于回溯"哪次合入了功能X"

# 场景B：本地 feature 落后于 main，先 rebase 到最新再合，保持历史线性
git checkout feature
git fetch origin
git rebase origin/main     # 把 feature 的提交"重放"到 main 最新之后
# rebase 遇到冲突：解决 → git add → git rebase --continue，重复直到完成
git checkout main
git merge feature          # 此时通常是 fast-forward，主干一条直线

# 场景C：已推送的提交不要 rebase！否则他人历史错位
# ❌ 错误：git push --force 推覆盖已被别人拉取的 rebase 结果
# ✅ 若必须强推自己的远程分支：git push --force-with-lease（更安全）

–no-ff 的作用

graph LR
    subgraph 普通merge_可能快进
        A1[C0] --> A2[C1] --> A3[F1] --> A4[F2]
    end
    subgraph --no-ff_merge_保留节点
        B1[C0] --> B2[C1]
        B2 --> B3[F1]
        B2 --> B4[M节点
显式合并提交]
        B3 --> B4
        B4 --> B5[F2重放]
    end

--no-ff 即使能快进（feature 基于 main 最新），也强制生成一个合并提交节点，让"这次合入了一个功能"在历史上清清楚楚，方便日后 git revert 整体回退某个功能。

冲突解决流程

# 步骤1：rebase 或 merge 时产生冲突，Git 会标记冲突文件
# 文件内出现：
# <<<<<<< HEAD（当前分支内容）
# 代码A
# =======
# 代码B
# >>>>>>> feature（ incoming 分支内容）

# 步骤2：手动编辑文件，保留正确代码，删除 <<< === >>> 标记

# 步骤3（merge 场景）：解决完所有冲突后
git add <冲突文件>
git commit              # 完成合并提交

# 步骤3（rebase 场景）：解决单个提交冲突后
git add <冲突文件>
git rebase --continue   # 继续重放后续提交；想放弃则 git rebase --abort

# 步骤4：合并后用 mergetool 可视化（可选）
git mergetool

⚠️ 新手必踩的坑： 绝不对已经推送到远程、且别人可能基于它工作的分支做 rebase + 强推——这会改写公共历史，导致队友 pull 时冲突满天飞。黄金法则：本地未推送的提交随便 rebase 整理；要合入共享分支用 merge（或 rebase 自己的分支后再 merge 进主干）。强推至少用 --force-with-lease 而非 --force，避免覆盖他人新提交。

十五、物理内存与虚拟内存的区别

15.1 用生活类比先建立直觉

把内存想象成一栋公寓楼：

• 物理内存是真实的楼房本身——每一间房间（内存芯片上的存储单元）有固定的门牌号（物理地址 0x0000 ~ 0xFFFFFFFF…）。如果所有进程都直接住进真实房间，就会互相串门、抢房间，甚至把别人的东西扔出去。
• 虚拟内存是物业公司给每位住户发的"虚拟门牌本”——每个进程都以为自己独占整栋楼（拥有从 0 到 4GB/128TB 的完整地址空间），但它手里的地址（虚拟地址）不是真的房间号。要进房间时，得先查"物业登记表"（页表，由 MMU 硬件翻译），登记表把虚拟门牌映射到真实房间。

核心区别一句话：物理内存是硬件真实存在的存储，虚拟内存是操作系统为每个进程虚构的、连续且独立的地址视图。好处有三：① 进程之间隔离（你看不到我的房间）；② 程序视角内存"无限"（可超过物理内存，配合 swap 把不用的页面寄存到磁盘）；③ 共享库只需加载一份物理内存，多个进程虚拟映射到同一处。

graph LR
    subgraph 进程A_虚拟地址空间
        VA1[0x1000 代码]
        VA2[0x2000 堆]
    end
    subgraph 进程B_虚拟地址空间
        VB1[0x1000 代码]
        VB2[0x2000 堆]
    end
    MMU[MMU
页表翻译]
    RAM[(物理内存
真实存储单元)]
    VA1 --> MMU
    VA2 --> MMU
    VB1 --> MMU
    VB2 --> MMU
    MMU -->|不同映射| RAM

桥接： 从"公寓楼门牌"到"虚拟内存"——虚拟地址经 MMU+页表翻译成物理地址，每个进程一套独立页表所以互相隔离。理解了这个映射机制，我们再来看 32 位进程的地址空间到底是怎么排布的。

15.2 工程要点

# 步骤1：查看进程的虚拟地址空间布局（maps 文件记录每个区域的起止与权限）
cat /proc/self/maps
# 输出示例（每行：起始-结束 权限 偏移 设备:inode 映射文件）：
# 00400000-00452000 r-xp 00000000 08:01 123456  /usr/bin/cat   # 代码段 只读执行
# 00651000-00672000 rw-p 00051000 08:01 123456  /usr/bin/cat   # 数据段 读写
# 7f...-7f...       rw-p 00000000 00:00 0       [heap]         # 堆
# 7f...-7f...       rw-p 00000000 00:00 0       [stack]        # 栈

# 步骤2：用 free 看物理内存与交换区真实情况（-h 人类可读）
free -h
# 输出：              total   used   free  shared  buff/cache  available
#       Mem:         7.7Gi  2.1Gi  3.2Gi  120Mi      2.4Gi      5.0Gi

# 步骤3：看进程的虚拟内存大小（VSZ）与物理常驻（RSS）
ps -o pid,comm,vsz,rss -p $$
# VSZ = 虚拟内存大小（含未实际分配/换出的），RSS = 实际占用的物理页

⚠️ 新手必踩的坑： VSZ（虚拟内存）经常比 RSS（物理内存）大几十倍，这不代表真的吃了那么多内存——虚拟地址空间里大量区域只是"预留"或"映射了文件"，并没有对应物理页。判断内存压力要看 RSS / available，别被 VSZ 吓到。

十六、Linux 32 位进程地址空间分布

16.1 用生活类比先建立直觉

把 32 位进程的 4GB 虚拟地址空间（2^32 = 4GB）想象成一条从 0 号房到 4GB 号房的长廊：

• 低地址（0 ~ 约 3GB）是"住户区"，归用户态程序使用：一进门是代码段（放程序指令）、接着是数据段（全局变量）、再往上是堆（动态 malloc 往上长）、最底部是栈（函数调用从顶往下长）。
• 高地址（约 3GB ~ 4GB）是"物业办公区"，归内核使用（内核空间）。用户程序不能直接进，要办事得通过"办事窗口"（系统调用）让内核代劳。

为什么是 3:1 划分？因为 32 位下 4GB 太紧张，默认把 3GB 留给用户、1GB 留给内核（也可配置 2:2）。64 位则宽松得多（用户空间 128TB，内核 128TB），所以"地址空间不够用"在 64 位基本消失。

graph LR
    subgraph 4GB虚拟地址空间_从低到高
        C[0x00000000
代码段.text]
        D[数据段.data/.bss]
        H[堆 heap
向高地址增长]
        U[... 空闲 ...]
        S[栈 stack
向低地址增长]
        E[0xC0000000
用户/内核分界线]
        K[内核空间
0xC0000000~0xFFFFFFFF]
    end
    C --> D --> H --> U --> S --> E --> K

桥接： 从"长廊分区"到"地址空间布局"——低 3GB 用户态、高 1GB 内核态，堆向上长、栈向下长，中间留空。理解了布局，再看程序运行时到底要在用户态和内核态之间来回切换多少次。

16.2 工程要点

# 步骤1：查看 32 位程序的地址分布（在 32 位环境或加 -m32 编译）
cat /proc/self/maps | head
# 可见用户区最高约到 0xbfffffff，其上是 [vsyscall]/内核映射

# 步骤2：用 size 命令看代码/数据段大小（链接视图）
size /bin/ls
# 输出：   text    data     bss     dec     hex filename
#         123456   12345    6789   142590   22c3e /bin/ls
# text=代码段, data=已初始化数据, bss=未初始化数据（不占文件但占内存）

# 步骤3：观察栈和堆的位置（程序内打印）
cat > /tmp/addr.c <<'EOF'
#include <stdio.h>
#include <stdlib.h>
int g;                      // 全局未初始化 → BSS 段
int main(){
    int l;                  // 局部变量 → 栈
    int *p = malloc(8);     // 堆分配
    printf("代码区~%p 数据区~%p 堆~%p 栈~%p\n",
           (void*)main, (void*)&g, (void*)p, (void*)&l);
    return 0;
}
EOF
gcc -m32 /tmp/addr.c -o /tmp/addr && /tmp/addr
# 典型输出：代码(低) < 数据 < 堆 < 栈(高)，且都在 0xC0000000 以下

⚠️ 新手必踩的坑： 32 位进程最多只能用到约 3GB 用户地址空间，单个进程即使物理内存有 64GB 也无法突破。这也是为什么大内存 Java/Redis 服务必须用 64 位。栈和堆"相向而行"，如果两者在中间相遇（堆涨太快或栈太深）就会"栈溢出/内存耗尽"。

十七、用户态与内核态的区别

17.1 用生活类比先建立直觉

把 CPU 的特权级别想象成大楼的权限卡：

• **用户态（Ring 3）**是普通访客区——你能在自己的办公室（用户空间）里走动、算账，但不能碰配电房、金库（硬件、内核数据结构）。想动这些，必须由"授权员工"（内核）代操作。
• **内核态（Ring 0）**是管理员权限——能直接操作 CPU、内存、磁盘控制器、网卡。所有硬件操作只能在内核态进行。

程序平时在用户态跑（速度快、权限小）。一旦需要"办硬件的事"（读文件、收网络包、创建进程），就必须通过**系统调用（syscall）**这个"办事窗口"：保存现场 → 切到内核态 → 内核替你干活 → 切回用户态 → 恢复现场。切换有成本（要换栈、保存寄存器），所以频繁 syscall 会拖慢性能。

graph TB
    U[用户态程序
Ring 3] -->|系统调用 syscall| TRAP[陷入内核
保存上下文]
    TRAP --> K[内核态
Ring 0 执行硬件操作]
    K -->|返回| RET[恢复上下文
回到用户态]
    RET --> U

桥接： 从"权限卡"到"用户态/内核态"——用户态不能直接碰硬件，任何 I/O 都要经 syscall 陷入内核态。理解了这个边界，再看内核是用哪些数据结构管理"海量文件"的。

17.2 工程要点

# 步骤1：用 strace 跟踪一个命令的系统调用（看清用户态↔内核态往返）
strace -f -e trace=network,read,write ls 2>&1 | head
# 输出会显示大量 read/write/open 等 syscall，每个都是一次陷入内核

# 步骤2：统计某进程系统调用次数（syscall 频率高说明用户/内核切换频繁）
strace -c cat /etc/hostname 2>&1 | tail -20
# % time / calls / errors 等列，calls 即 syscall 总次数

# 步骤3：查看 CPU 在用户态/内核态的占比（us 与 sy）
top -b -n1 | head -3
# %Cpu(s):  5.0 us,  2.0 sy  →  sy 高说明大量时间花在内核态（如频繁 I/O）

⚠️ 新手必踩的坑： sy（system）CPU 占比高，往往意味着程序在做大量系统调用（频繁 read/write/网络收发），而不是在做计算。优化方向常是"减少 syscall 次数"——比如用缓冲 I/O 一次性读大块代替逐字节读、用 splice/sendfile 做零拷贝。这也正是高性能网络框架（如 Go netpoller）要尽量减少陷入内核的原因。

十八、Linux 文件系统管理数据结构：inode、dentry、superblock、ext4 / B+树索引、VFS 抽象层

18.1 用生活类比先建立直觉

把文件系统想象成一栋带档案室的大楼：

• **superblock（超级块）**是整栋楼的"建筑图纸"——记录文件系统类型、总容量、已用/空闲块数、inode 总数等全局信息。图纸丢了，整栋楼就乱套（文件系统损坏）。
• **inode（索引节点）**是每件物品的"电子档案卡"——记录文件的大小、权限、时间戳、数据块指针（文件内容存在哪些磁盘块上）。注意：inode 里没有文件名！一个文件对应一个 inode。
• **dentry（目录项）**是"房间号→物品名"的对照表——把文件名（/home/foo.txt）映射到对应的 inode 号。目录本身也是文件，其内容就是一张"文件名→inode 号"的表。这就是为什么"硬链接"只是多建一条 dentry 指向同一 inode。
• **VFS（虚拟文件系统）**是大楼的"统一前台"——无论底层是 ext4、xfs 还是 tmpfs，应用程序都通过同一套 open/read/write 接口访问，VFS 负责翻译成具体文件系统的实现。就像无论顺丰还是京东，你都用同一个寄件 App。

graph TB
    SB[superblock
全局图纸:容量/inode总数]
    DIR[/home/ 目录文件
存 dentry 表/]
    D1[dentry: foo.txt → inode 42]
    D2[dentry: bar.txt → inode 42]
    INODE[inode 42
权限/大小/数据块指针]
    BLOCKS[数据块
文件真实内容]
    VFS[VFS 抽象层
统一 open/read/write]
    APP[应用程序]
    APP --> VFS
    VFS -->|ext4 实现| DIR
    DIR --> D1
    DIR --> D2
    D1 --> INODE
    D2 --> INODE
    INODE --> BLOCKS
    SB -.管理.-> INODE

桥接： 从"档案室"到"文件系统"——superblock 管全局、inode 存元数据、dentry 把名字连到 inode、VFS 屏蔽底层差异。理解 inode 后，我们就能回答一个经典面试题：rm 删了文件，磁盘空间真的释放了吗？

18.2 工程要点

# 步骤1：查看文件的 inode 号（ls -i）
ls -li /etc/hostname
# 输出首列即 inode 号，如 123456

# 步骤2：查看 inode 磁盘布局信息（dumpe2fs，需 root，针对 ext 系列）
dumpe2fs -h /dev/sda1 2>/dev/null | grep -i "inode count\|block count"
# 显示 inode 总数与块总数

# 步骤3：stat 看 inode 里的元数据（不含文件名）
stat /etc/hostname
# 输出：Size / Inode / Links(硬链接数) / 三个时间戳

# 步骤4：ext4 的 extent/B+树 索引——用 filefrag 看文件数据块如何组织
filefrag -v /var/log/syslog
# 显示文件的逻辑块 → 物理块映射，ext4 用 extent 树（B+树变种）减少元数据

# 步骤5：查看 VFS 挂载的文件系统类型（验证 VFS 抽象）
cat /proc/mounts | head
# ext4 / proc / tmpfs / overlay 等共存，应用无感知

⚠️ 新手必踩的坑： df 报"磁盘满了"但 du 找不出大文件？常见原因之一是 inode 耗尽（大量小文件把 inode 用完，磁盘块还有剩）。用 df -i 看 inode 使用率可定位。另一个坑：删了大文件但 df 空间不释放——往往是有进程还打开着这个文件（见下一章）。

十九、rm 返回成功是否代表文件真的被删除

19.1 用生活类比先建立直觉

把文件删除想象成图书馆退书：

• rm 命令本质上不是"碎纸"，而是"把书名从目录卡片（dentry）上划掉"，并把这个书名对应的档案卡（inode）的引用计数减 1。
• 如果还有别人借着这本书（硬链接存在，或某进程正打开着这个文件的描述符），引用计数减到 0 之前，书（磁盘数据块）不会真的被清走——只是目录里查不到它了。
• 只有当引用计数降到 0，且没有任何进程打开着它，内核才把 inode 标记为空闲、把数据块归还给空闲列表。此时空间才真正释放。

所以经典问题来了：rm 返回成功 ≠ 磁盘空间立刻腾出。如果有个正在写日志的进程还握着被删文件的描述符，数据仍持续写入那些"已删除"的块，直到进程关闭 fd 或退出，空间才释放。这也是"删了日志但磁盘还是满"的真正原因。

graph TB
    RM[rm 文件名] --> UNLINK[unlink 删除 dentry]
    UNLINK --> DEC[inode 引用计数 -1]
    DEC -->|计数>0| HOLD[空间不释放
仍有硬链接/打开的fd]
    DEC -->|计数==0 且无打开fd| FREE[真正释放数据块
空间回收]
    DEC -->|计数==0 但有打开fd| HOLD2[进程仍写入
直到关闭fd才释放]
    HOLD2 --> FREE

桥接： 从"图书馆退书"到"unlink 引用计数"——rm 只减引用计数，真正的空间释放要等计数归零且无人持有 fd。理解了这点，下面我们用命令和代码验证。

19.2 工程要点

# 步骤1：制造"已删除但空间不释放"的场景
# 终端A：持续往文件写（模拟日志进程握着 fd）
( while true; do echo "log line" >> /tmp/big.log; sleep 0.1; done ) &
WRITER=$!

# 步骤2：另一个终端查看磁盘占用
df -h /tmp

# 步骤3：删除文件（rm 成功返回），但 writer 仍持有 fd → 空间不释放
rm -f /tmp/big.log
df -h /tmp     # 发现 Used 没降！因为 big.log 还在被 writer 写入

# 步骤4：找出"删了但仍被占用"的文件（lsof +L1，+L1 表示链接数为 0）
lsof +L1 | grep deleted
# 输出：COMMAND PID USER FD ... NAME ... (deleted)  ← 已 unlink 但 fd 仍打开

# 步骤5：杀掉 writer，fd 关闭，空间才真正释放
kill $WRITER
df -h /tmp     # 现在 Used 下降了

# 步骤6：验证硬链接计数的作用（删一个硬链接，另一个还能读）
echo "data" > /tmp/orig.txt
ln /tmp/orig.txt /tmp/link.txt      # 硬链接，inode 引用计数=2
rm /tmp/orig.txt                    # 计数减为1，文件内容仍在 link.txt
cat /tmp/link.txt                   # 仍能读到 data

// Go 演示：unlink 后文件描述符仍可继续读写（POSIX 语义）
package main

import (
    "fmt"
    "os"
)

func main() {
    f, _ := os.Create("/tmp/demo.txt")
    f.WriteString("hello before unlink\n") // 步骤1：写入内容

    os.Remove("/tmp/demo.txt")            // 步骤2：unlink（rm 的底层）
    // 此时目录里已查不到 demo.txt，但 f 仍有效！

    f.WriteString("hello after unlink\n") // 步骤3：仍可通过 fd 写入
    f.Seek(0, 0)
    buf := make([]byte, 100)
    n, _ := f.Read(buf)
    fmt.Printf("仍能读到:%q\n", buf[:n]) // 输出包含两行内容

    f.Close()                             // 步骤4：关闭 fd，引用计数归0，空间才释放
    fmt.Println("close 后数据块才真正归还")
}

⚠️ 新手必踩的坑： 线上磁盘 100% 但 rm 了大日志后仍不降，第一反应不是再删，而是 lsof +L1 | grep deleted 找到"僵尸占用"的进程，重启/重载它（让日志轮转 reopen 文件）即可释放。盲目 rm 反而让空间永远卡在被进程 hold 住的状态。日志场景务必配合 logrotate 的 copytruncate 或让程序支持重新打开文件。

二十、操作系统内存分配过程：brk / mmap、buddy system、slab 分配器、TLB 简引

20.1 用生活类比先建立直觉

把内存分配想象成两个尺度的仓库管理：

• 应用层向内核"批发"内存：有两种方式。
  • brk/sbrk：把堆的"边界线"往上推一格——适合连续、逐步增长的堆分配（glibc malloc 对小块用 brk）。
  • mmap：直接"租一整间独立仓库"（匿名映射页），用完整体退还。适合大块内存（通常 >128KB）或加载共享库。
• 内核拿到物理页后，怎么细分给进程？ 用 buddy system（伙伴系统）：把空闲物理页按 2 的幂（1、2、4、8…页）分组成块，分配时拆、释放时合并"伙伴"，避免外部碎片。就像发整包 A4 纸，要半包就拆一包。
• 更细的对象（内核里的 task_struct、inode 等小结构）怎么办？ 用 slab 分配器：为每种常用对象建一个"预制件缓存"，分配/释放只是从缓存取/还，免去反复初始化，且减少内部碎片。就像工地旁堆好的标准砖，随用随取。
• **TLB（快表）**是地址翻译的"速查小抄"——CPU 把最近用过的"虚拟页→物理页"映射存在 TLB 里，下次不用翻页表（慢）。进程切换换了页表，TLB 就失效（又要重查），这正是进程切换比线程慢的原因之一（呼应第十章）。

graph TB
    APP[用户程序 malloc] --> GLIBC[glibc malloc]
    GLIBC -->|小块/连续| BRK[brk 推堆边界]
    GLIBC -->|大块| MMAP[mmap 匿名映射]
    BRK --> K[内核]
    MMAP --> K[内核]
    K --> BUDDY[buddy system
物理页 2^n 块管理]
    BUDDY --> SLAB[slab 分配器
内核小对象缓存]
    SLAB --> OBJ[内核对象 task_struct/inode...]
    MMU[每次访问] --> TLB{TLB 命中?}
    TLB -->|是| FAST[直接得物理地址]
    TLB -->|否| PAGE[查页表→更新TLB]

桥接： 从"仓库管理"到"内存分配层次"——用户 malloc 最终走 brk/mmap 向内核要页，内核用 buddy 管物理页、slab 管小对象，TLB 加速地址翻译。理解分配层次后，我们看看一个进程启动时到底会吃下哪些资源、又受什么限制。

20.2 工程要点

# 步骤1：用 strace 观察 malloc 大块时走 mmap（而非 brk）
strace -e trace=mmap,brk cat /etc/hostname 2>&1 | head
# 会看到 mmap(NULL, ...) 用于加载共享库和堆扩展

# 步骤2：查看进程的堆/映射区域（brk 区域即 [heap]）
cat /proc/self/maps | grep -E "heap|stack"

# 步骤3：查看内核 slab 缓存占用（slabtop）
sudo slabtop -o | head -15
# 显示各对象（如 inode_cache、dentry）的活跃/总对象数，占多少内存

# 步骤4：查看 buddy 系统当前空闲页分布（/proc/buddyinfo）
cat /proc/buddyinfo
# 每列对应 2^order 页的空闲块数量，反映物理内存碎片程度

# 步骤5：查看页大小与内核保留内存
getconf PAGESIZE                  # 通常 4096 = 4KB 页
cat /proc/sys/vm/min_free_kbytes # 内核保留的最小空闲内存

⚠️ 新手必踩的坑： “内存泄漏"不一定立刻 OOM——glibc 的 malloc 在释放小块时可能不把内存归还给操作系统（只是标记空闲，留在进程堆里复用）。所以 RSS 居高不下但程序已"释放”，往往是 allocator 行为，不一定是真泄漏。要区分：用 pprof/valgrind 看分配点，而非只看 RSS。

二十一、Linux 进程启动占用的资源及限制：fd、内存、线程数、ulimit、cgroup

21.1 用生活类比先建立直觉

把一个进程启动想象成一家公司开张领资源：

• 文件描述符（fd）：公司领的"窗口"数量。每个打开的文件、socket、管道都占一个 fd。默认上限通常 1024，高并发服务（如 Nginx、Redis）动辄要几万，不够就 Too many open files。
• 内存：公司租的"办公场地"。包括代码、堆（动态分配）、栈（每个线程 8MB 默认）、共享库。
• 线程数：公司雇的"员工"数。线程数受地址空间（每线程栈）和内核限制约束。
• ulimit：公司所在的"写字楼管理规约"——单个进程/用户的资源上限（fd 数、栈大小、核心转储、进程数等），由 shell/limits.conf 设置，只约束当前 session，不跨进程累积。
• cgroup（控制组）：整栋楼（容器/系统）的"总配额闸刀"——Docker/K8s 正是用它给容器限 CPU/内存。它比 ulimit 更硬：超了直接 OOM kill 或限流，且作用于一组进程。

一句话：ulimit 管"单用户单进程"的软上限，cgroup 管"一组进程"的硬配额（容器基石）。

graph TB
    PROC[进程启动] --> FD[fd 表
默认上限 1024]
    PROC --> MEM[内存
堆/栈/共享库]
    PROC --> THR[线程数
受栈与 pid_max 约束]
    FD -.受.-> UL[ulimit
用户级软上限]
    MEM -.受.-> CG[cgroup
容器硬配额]
    THR -.受.-> UL
    CG --> DOCKER[Docker/K8s limits]

桥接： 从"公司开张"到"资源限制"——fd/内存/线程各有上限，ulimit 是用户级软约束，cgroup 是容器级硬约束。了解限制后，我们自然要问：那一台服务器到底能扛多少并发连接？

21.2 工程要点

# 步骤1：查看当前 shell 的 ulimit 各项限制
ulimit -a
# 关注：open files(-n) 默认1024、max user processes(-u)、stack size(-s) 8192KB

# 步骤2：临时提高 fd 上限（仅当前 session）
ulimit -n 65535

# 步骤3：永久配置（/etc/security/limits.conf）
# *    soft    nofile    65535
# *    hard    nofile    65535
# *    soft    nproc     65535

# 步骤4：查看某进程实际用的 fd 数
ls /proc/12345/fd | wc -l

# 步骤5：查看 cgroup 对容器的内存限制（在容器内执行）
cat /sys/fs/cgroup/memory.max 2>/dev/null || cat /sys/fs/cgroup/memory/memory.limit_in_bytes

# 步骤6：查看系统级进程数/线程数上限
cat /proc/sys/kernel/pid_max          # 系统总 PID 上限（如 32768 / 4194304）
cat /proc/sys/kernel/threads-max      # 系统总线程数上限

# 步骤7：查看单进程可创建的近似线程数（可用内存 / 每线程栈 8MB）
echo "scale=0; $(free -b | awk '/Mem:/ {print $7}') / (8*1024*1024)" | bc

⚠️ 新手必踩的坑： 改了 ulimit -n 65535 却没用？常见两个原因：① 配置写在 limits.conf 但 PAM 没启用 pam_limits（sshd/服务管理器要配）；② systemd 服务用 LimitNOFILE= 覆盖，ulimit 对它无效。容器里更要看 cgroup，因为 ulimit 在容器里常被忽略，真正卡你的是 memory.max / K8s resources.limits。

二十二、共享内存的并发冲突与保护

22.1 用生活类比先建立直觉

回到"两栋楼开公共窗户"（共享内存）的场景：双方直接看同一块空间，最快但毫无保护——如果两个人都同时往窗口塞东西、或者一人写一半另一人就来读，数据就乱套（数据竞争 / data race）。

保护手段就像给这扇窗户装不同的"门禁"：

• 互斥锁（mutex）：一把只能一人进的锁，进去得等里面的人出来。简单，但粒度粗（整个区间互斥）。
• 信号量（semaphore）：带计数器的门禁，允许 N 个人同时进（如缓冲池最多 10 个槽）。适合"限制并发数"。
• 原子操作（atomic）：不装门，而是规定"写这个格子时谁都别插手，一步写完"（CPU 级别的不可中断指令，如 CAS）。适合单个变量的无锁计数。
• 文件锁（file lock / flock）：跨进程、甚至跨机器（分布式锁）的"门禁"，适合不同程序共享同一个文件/共享内存对象。
• 无锁 ring buffer（环形缓冲）：最精巧的门禁——一个写指针、一个读指针，生产者只动写指针、消费者只动读指针，两者永不互相锁，靠内存屏障保证可见性，实现高性能无锁队列（常见于日志、网络包收发）。

graph TB
    subgraph 共享内存区
        RB[ring buffer
buf[0..N-1]]
        WP[write_idx 生产者维护]
        RP[read_idx 消费者维护]
    end
    PROD[生产者] -->|原子加 write_idx| WP
    CONS[消费者] -->|原子加 read_idx| RP
    PROD --> RB
    CONS --> RB
    WP -.内存屏障.-> RP

桥接： 从"公共窗户门禁"到"并发保护"——锁/信号量/原子/文件锁各有适用粒度，ring buffer 用双指针实现无锁高并发。下面用 Go 代码演示原子操作与互斥锁，并指出 -race 如何抓数据竞争。

22.2 工程要点

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

// ===== 方式1：互斥锁保护共享计数器 =====
func withMutex() {
    var mu sync.Mutex
    var counter int64
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            mu.Lock()         // 步骤1：进入临界区前加锁
            counter++         // 步骤2：安全修改共享变量
            mu.Unlock()       // 步骤3：退出临界区解锁
        }()
    }
    wg.Wait()
    fmt.Println("mutex result:", counter) // 恒等于 1000
}

// ===== 方式2：原子操作（无锁，单变量最快）=====
func withAtomic() {
    var counter int64
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            atomic.AddInt64(&counter, 1) // 步骤1：CPU 级不可中断的自增
        }()
    }
    wg.Wait()
    fmt.Println("atomic result:", counter) // 恒等于 1000
}

// ===== 方式3（反面）：不加保护 → 数据竞争，用 go run -race 抓到 =====
func withRace() {
    var counter int64
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter++ // ❌ 无保护：多 goroutine 同时读写，结果不确定
        }()
    }
    wg.Wait()
    fmt.Println("race result (错误):", counter)
}

func main() {
    withMutex()
    withAtomic()
    // withRace() // 取消注释并用 `go run -race` 运行，会报告 DATA RACE
}

# 步骤1：用 -race 检测数据竞争（Go 内置竞态检测器）
go run -race main.go
# 若触发 withRace，会打印 "WARNING: DATA RACE" 并给出两个 goroutine 的栈

# 步骤2：文件锁示例（flock，跨进程互斥）
# 终端A：flock -x /tmp/lockfile -c 'sleep 30; echo A done'  # 拿独占锁睡30秒
# 终端B：flock -x /tmp/lockfile -c 'echo B got lock'         # 会阻塞直到A释放

⚠️ 新手必踩的坑： 共享内存 + 裸指针并发写是未定义行为，可能偶尔"看起来对"却随机出错，最难调。原则：① 能用 channel 就别用共享内存（Go 哲学）；② 非用不可时，单变量用 atomic，复合操作用 mutex，跨进程用 flock/信号量；③ 永远用 -race 跑测试抓竞争。ring buffer 虽快但实现易错，生产优先用成熟库或标准库的 channel 替代。

二十三、一台 Linux 服务器最多能支持多少个 client 同时连接

23.1 用生活类比先建立直觉

把服务器想象成一家有固定电话总机的大公司：

• 每个打进来的客户（client）占用一条电话线路（fd/socket）。公司能同时接多少电话，首先受"总机插口数量"（文件描述符上限）限制。
• 但是！光有插口还不够——如果两个客户用的是同一根外线+同一分机号，总机分不清谁是谁（靠"五元组"区分连接：源 IP、源端口、目的 IP、目的端口、协议）。五元组不同才算不同连接。
• 端口范围的误区：很多人以为"目的端口 65535 个所以最多 65535 连接"。错！那是服务端监听端口固定，客户端来自不同 IP、不同源端口，五元组里后四项是变化的，所以数量远不止端口数。
• 真正的天花板是：fd 上限 × 可用内存（每个连接占用内核缓冲区几 KB~几 MB） × CPU（能否及时处理） 三者共同决定。理论上一台 64 位机器、调高 ulimit、几十 GB 内存，可轻松支撑百万级并发连接（C10M）。

graph TB
    C1[client A: IP1:port1] --> SRV[服务器 :8080]
    C2[client B: IP2:port2] --> SRV
    C3[client C: IP1:port3] --> SRV
    SRV --> FD[每个连接占 1 个 fd
受 nofile 上限约束]
    SRV --> MEM[每个连接占内核缓冲区
受内存约束]
    SRV --> CPU[事件循环处理
受 CPU 约束]
    FD --> LIMIT[瓶颈: ulimit -n / fs.file-max]
    MEM --> LIMIT2[瓶颈: 内存 / cgroup]

桥接： 从"电话总机"到"并发连接数"——连接由五元组唯一标识，不是端口数；上限由 fd、内存、CPU 共同决定。下面我们看调参示例，把一台普通服务器推到百万连接。

23.2 工程要点

# 步骤1：全局文件句柄上限（系统级，所有进程共享）
cat /proc/sys/fs/file-max          # 如 9223372036854775807（很大）
# 调大（临时）：sysctl -w fs.file-max=1000000

# 步骤2：单进程 fd 上限（ulimit -n，前面章节已讲）
ulimit -n                          # 默认 1024，需调到 100000+

# 步骤3：查看当前已用文件句柄数
cat /proc/sys/fs/file-nr
# 三列：已分配 / 已分配未用 / 上限

# 步骤4：TCP 端口范围（客户端源端口池，影响单机作为客户端的连接数）
cat /proc/sys/net/ipv4/ip_local_port_range   # 如 32768 60999 → 约 2.8 万源端口

# 步骤5：单 socket 内存开销相关参数
cat /proc/sys/net/core/rmem_max    # 接收缓冲区上限
cat /proc/sys/net/core/wmem_max    # 发送缓冲区上限
# 每个 TCP 连接默认占用 rmem_default+wmem_default，约几十 KB

# 步骤6：用 Go 起一个能接受海量连接的回声服务器（演示单进程扛连接）
cat > /tmp/echo_server.go <<'EOF'
package main

import (
    "net"
    "os"
    "runtime"
    "sync/atomic"
    "time"
)

var conns int64

func main() {
    ln, err := net.Listen("tcp", ":8080")
    if err != nil {
        panic(err)
    }
    go func() { // 每 5 秒打印当前连接数
        for {
            runtime.GC()
            println("当前连接数:", atomic.LoadInt64(&conns))
            time.Sleep(5 * time.Second)
        }
    }()
    for {
        c, err := ln.Accept()
        if err != nil {
            os.Exit(1)
        }
        atomic.AddInt64(&conns, 1)
        go func(conn net.Conn) { // 每连接一个 goroutine（Go 轻量）
            buf := make([]byte, 1024)
            for {
                n, e := conn.Read(buf)
                if e != nil {
                    atomic.AddInt64(&conns, -1)
                    conn.Close()
                    return
                }
                conn.Write(buf[:n]) // 回声
            }
        }(c)
    }
}
EOF
# 调高 ulimit -n 后运行：ulimit -n 1000000 && go run /tmp/echo_server.go
# 用压测工具（如 wrk / vegeta / 自定义客户端）即可观察到十万级连接

估算公式（速算）：

• 可用连接数 ≈ min(单进程 fd 上限, 内存 / 每连接内存)
• 例：内存 16GB，每连接约 10KB（含缓冲区与内核结构） → 理论约 160 万连接；再受 fd 上限（调到 100 万）约束 → 实际约 100 万。
• CPU 维度：事件驱动（epoll/io_uring）下单核可处理数万~十万连接事件；Go 的 netpoller 基于 epoll，百万连接下 goroutine 内存才是主要开销（每个约 8KB 栈，可调小）。

⚠️ 新手必踩的坑： ① “端口只有 65535 所以最多 65535 连接"是最大误区——那是服务端端口，客户端五元组变化让连接数远超端口数。② 连接数上不去先看 ulimit -n 和 fs.file-max，再看内存。③ 别忘了 TIME_WAIT 状态会占用本地端口（服务端主动关闭时），高并发短连接要开 net.ipv4.tcp_tw_reuse 或改用长连接。④ 容器里真正卡你的是 cgroup 内存上限，不是 ulimit。

二十四、自测题与动手练习

自测题

1. 进程和线程在资源开销上的根本区别是什么？ 为什么创建一个进程比创建一个线程慢得多？fork() 的写时复制（COW）机制在其中起了什么作用？

2. Docker 的三大核心技术分别解决什么问题？ 如果只有 Namespace 没有 Cgroups 会怎样？如果只有 Cgroups 没有 Namespace 会怎样？

3. Dockerfile 中为什么要把 COPY go.mod go.sum 放在 COPY 源码之前？ Docker 的层缓存机制是如何工作的？如果 go.sum 文件变了但 go.mod 没变，go mod download 这一层会重新执行吗？

4. livenessProbe 和 readinessProbe 的失败行为有什么不同？ 对于一个需要 30 秒启动的 JVM 应用，如果不配置 startupProbe 会发生什么？应该怎样配置三个探针？

5. Pod CPU 线性增长，内存正常，最先应该排查什么？ 描述你的排查步骤。如果 goroutine 数量没有增长，接下来排查哪些方向？

动手练习

1. 多阶段 Dockerfile 实战： 编写一个 Go HTTP 服务的多阶段 Dockerfile，要求：builder 阶段使用 golang:1.22-alpine，runtime 阶段使用 alpine:3.19，最终镜像小于 20MB。对比单阶段构建和多阶段构建的镜像体积差异，用 docker history 查看每层的大小分布。

2. K8s 滚动更新与回滚： 用 kind 或 minikube 创建本地集群，部署一个 Deployment（3 副本）+ ClusterIP Service。触发滚动更新（kubectl set image），用 kubectl rollout status 观察更新过程。然后执行回滚操作（kubectl rollout undo），验证 Pod 恢复到旧版本。用 kubectl rollout history 查看版本历史。

3. goroutine 泄露定位与修复： 编写一个 Go 程序，在 HTTP handler 中故意泄露 goroutine（使用无缓冲 channel）。启用 pprof，用 go tool pprof 采集 goroutine 信息，用 top 命令找到泄露位置。然后用 context.WithTimeout 修复泄露，验证修复后 goroutine 数量稳定在固定值不再增长。提交修复前后的 pprof 截图。

新增自测题（覆盖第六、七、八章）

6. Linux 开机启动链是什么？systemd 时代与传统 runlevel 的对应关系如何？ 为什么 PID=1 进程如此关键？如果它退出会发生什么？

7. Docker 容器与虚拟机在隔离粒度、启动速度、资源占用上有何本质区别？ 为什么容器共享内核既是优点（轻量）也是缺点（隔离弱）？半虚拟化（paravirtualization）又是什么？

8. 死锁的四个必要条件是什么？ 给出两种实际工程中破坏死锁的方法。进程切换为什么比线程切换慢得多（从 TLB 角度解释）？

9. 虚拟内存、分页、分段的区别是什么？ 页面替换算法（LRU/FIFO/Clock）各自解决什么问题？硬链接和软链接的本质区别又是什么？

新增自测题（覆盖第九~十四章）

10. 线上服务报错，如何只用 grep + awk 在几 GB 日志里快速定位 Top 3 报错类型及其出现次数？ 请写出组合命令，并说明 -E、-c、uniq -c、sort -rn 各自的作用。为什么 tail -f | grep 管道可能不及时刷出错误？

11. 僵尸进程和孤儿进程分别是怎么产生的？哪个真正有害、为什么？ 父进程不回收子进程会有什么后果？给出两种避免僵尸进程的工程手段（wait/waitpid 与 fork 两次），并解释为什么 kill -9 杀不掉僵尸进程。

12. Git 的 merge 与 rebase 本质区别是什么？ 为什么"已推送到远程的分支不要随意 rebase”？--no-ff 解决了什么可读性/可回退问题？请画（或描述）rebase 后主干历史为什么是一条直线而无合并节点。

新增自测题（覆盖第十五~二十三章）

13. 物理内存和虚拟内存的区别是什么？为什么 32 位进程最大只能用约 3GB 用户空间？ 用"公寓楼门牌"类比解释 MMU+页表的作用，并说明为什么 VSZ 远大于 RSS 不代表内存泄漏、判断内存压力应该看哪个指标。

14. rm 删除一个正在被进程写入的日志文件后，为什么 df 显示磁盘空间没有释放？ 解释 unlink 的引用计数机制，给出用 lsof +L1 定位"已删除但仍被占用"文件、并通过重启进程释放空间的方法。硬链接的存在会如何影响删除行为？

15. 一台 Linux 服务器到底能支持多少 client 同时连接？为什么"端口只有 65535"的说法是错误的？ 说明五元组如何唯一标识一条连接，以及 fd 上限、内存、CPU 三者如何共同决定并发上限，并给出调高 ulimit -n 与 fs.file-max 的示例。容器环境下真正卡住连接数的是 ulimit 还是 cgroup？

新增动手练习

4. 跨平台容器体验： 在 macOS 或 Windows 上安装 Docker Desktop，理解它"内嵌 Linux 虚拟机"的本质（用 docker version 查看 Server 端内核信息）。再用 docker volume prune 清理一次孤儿卷，观察磁盘释放效果。

5. 死锁复现与避免： 用 Go 写两个 goroutine，分别先锁 A 再锁 B、先锁 B 再锁 A，制造死锁（用 -race 检测并观察 hang 住）。然后改成"统一加锁顺序"或使用 sync.TryLock 超时退出，验证死锁被消除。

二十五、本章小结

本章沿着"操作系统基础 → 容器技术 → 容器编排 → 故障排查“的脉络，系统讲解了从 Linux 进程到 K8s Pod 的完整知识链路：

1. Linux 进程与线程是理解容器的基础：进程是资源分配的基本单位（独立地址空间/文件描述符表/信号处理），线程是 CPU 调度的基本单位（共享进程资源，独立栈/寄存器/PC）。fork/exec/wait 三板斧是进程管理的核心——fork 用写时复制（COW）降低创建开销，exec 加载新程序，wait 回收子进程。线程三种实现方式从用户级到内核级再到 LWP，Go 的 goroutine 属于用户级线程，由 GMP 模型调度到少量内核线程上。

2. Docker = Namespace + Cgroups + UnionFS：Namespace 隔离视图让容器看到"自己的世界”（PID/网络/挂载/UTS/IPC/User 六大隔离维度），Cgroups 画资源红线（CPU/内存/IO 限制），UnionFS 分层叠加让镜像可复用。docker exec 是进入容器的推荐方式（启动新进程，不影响主进程），docker attach 共享主进程 IO（Ctrl+C 会杀掉容器）。

3. 多阶段 Dockerfile 是生产级标配：builder 阶段编译（golang 镜像含编译器约 350MB），runtime 阶段只放二进制（alpine 约 7MB），最终镜像可压到 15-20MB。依赖缓存优化的核心原则是"变化频率低的放前面"——先 COPY go.mod/go.sum → go mod download（缓存层）→ 再 COPY 源码 → go build。.dockerignore 排除 .git/测试文件/编译产物，加速构建并避免密钥泄露。

4. K8s 通过声明式 API 管理容器生命周期：Master（API Server/etcd/Scheduler/Controller Manager）负责全局决策，Node（kubelet/kube-proxy/containerd）负责执行。Pod 是最小调度单位，一个或多个紧密耦合的容器共享网络和存储。健康检查三件套各司其职：livenessProbe 失败重启容器、readinessProbe 失败摘除流量、startupProbe 保护慢启动。Deployment 管理副本集并支持滚动更新与回滚，Service 提供固定访问入口（ClusterIP/NodePort/LoadBalancer），Ingress 做七层路由。

5. CPU 线性增长排查用 pprof 系统化定位：五大常见根因——goroutine 泄露、闭包引用未释放、全局 map 只增不减、time.After/ticker 未 Stop、连接未关闭。排查决策树从"goroutine 是否增长"开始逐层缩小范围，用 go tool pprof 采集 goroutine 和 CPU profile，通过火焰图定位热点函数。修复后建立 Prometheus 告警规则（CPU 使用率阈值 + goroutine 数量监控 + CPU 上升趋势检测），在问题演变成事故前主动发现。