Linux】 性能调优实战：内核参数优化技巧

---

【Linux 性能调优实战：内核参数优化技巧】

摘要

在现代IT基础架构中，Linux 操作系统是驱动绝大多数高性能应用（如Web服务器、数据库、大数据平台和容器集群）的核心。然而，默认的 Linux 内核配置是为了"通用性"而设计的，它试图在各种不同的硬件和工作负载之间找到一个平衡点。对于追求极致性能的特定应用场景，这种"一刀切"的配置往往会成为性能瓶颈。

本文是一篇深入的实战指南，旨在揭开 Linux 内核参数调优的神秘面纱。我们将跳出"复制粘贴"网络上零散配置的层面，深入探讨 为什么 以及 如何 通过 /proc/sys 文件系统和 sysctl 工具来优化关键的内核子系统------特别是内存管理（VM）和网络堆栈（Net）。文章将详细解析 vm.dirty_ratio、net.core.somaxconn 和 net.ipv4.tcp_tw_reuse 等核心参数背后的工作原理，并通过一个高并发Web服务器的实战案例，向您展示如何系统性地诊断问题、应用调优并验证结果。

---

目录

1. 引言：为什么内核调优至关重要？
2. [基础：sysctl 与 /proc/sys 的交互世界](#基础：sysctl 与 /proc/sys 的交互世界)
   • 2.1 /proc/sys：内核的运行时配置窗口
   • 2.2 sysctl：更优雅的配置工具
   • 2.3 临时修改 vs 永久生效
3. 核心战场（一）：内存（VM）参数调优
   • 3.1 vm.swappiness：重新定义"交换"的意义
   • 3.2 vm.dirty_background_ratio / vm.dirty_ratio：I/O 风暴的"制造者"
   • 3.3 现代解法：vm.dirty_background_bytes / vm.dirty_bytes
   • 3.4 vm.overcommit_memory：内存"超售"策略
   • 3.5 vm.vfs_cache_pressure：VFS 缓存的"回收压力"
4. 核心战场（二）：网络（Net）参数调优
   • 4.1 net.core.somaxconn & net.ipv4.tcp_max_syn_backlog：高并发的"接待"能力
   • 4.2 net.ipv4.tcp_tw_reuse & net.ipv4.tcp_fin_timeout：管理 TIME_WAIT 状态
   • 4.3 警惕！net.ipv4.tcp_tw_recycle 的陷阱
   • 4.4 TCP 缓冲区：net.core.*mem* 与 net.ipv4.tcp_*mem*
5. 核心战场（三）：文件系统与进程限制
   • 5.1 fs.file-max：系统级文件句柄
   • 5.2 fs.nr_open 与 ulimit：进程级文件句柄
6. [实战演练：优化一台高并发 Web 服务器](#实战演练：优化一台高并发 Web 服务器)
   • 6.1 场景描述与问题诊断
   • 6.2 调优策略与执行
   • 6.3 验证结果
7. 调优的哲学：超越"最佳实践"
8. 总结
9. 相关链接

---

1. 引言：为什么内核调优至关重要？

Linux 内核是一个极其复杂和精密的软件，它管理着所有的硬件资源，并为上层应用提供服务。性能调优的本质，就是根据我们的特定工作负载（Workload），调整内核的资源管理策略，使其行为更符合我们的预期。

例如，一个处理海量小文件读写的NFS服务器，其对 VFS (Virtual File System) 缓存的需求与一个运行内存数据库（如 Redis）的服务器截然不同。前者可能希望内核尽可能多地缓存 dentry 和 inode，而后者则希望内核尽量减少交换（Swap）行为，并允许应用程序（Redis）"超售"内存。

不进行调优，我们可能面临：

• I/O 性能抖动：在大量写操作时，系统突然卡顿，I/O-Wait 飙升。
• 网络连接瓶颈：在高并发请求下，出现大量连接超时或"connection refused"。
• 内存资源浪费：系统明明有大量空闲内存，却频繁发生 Swap，导致性能急剧下降。
• 资源耗尽：出现"Too many open files"等错误，导致服务中断。

内核参数调优，就是我们手中的"手术刀"，允许我们精确地调整内核行为，榨干硬件的最后一丝性能。本文将带您深入了解这把"手术刀"的使用方法。

2. 基础：sysctl 与 /proc/sys 的交互世界

在 Linux 中，内核参数绝大多数都通过一个特殊的虚拟文件系统 /proc/sys 暴露给用户空间。

2.1 /proc/sys：内核的运行时配置窗口

/proc/sys 目录下的文件结构与内核的子系统相对应：

• vm：与内存管理（Virtual Memory）相关。
• net：与网络堆栈相关。
• fs：与文件系统相关。
• kernel：与内核核心功能相关（如 PID、消息队列等）。

我们可以像操作普通文件一样读写它们。例如，查看当前系统的 swappiness 值：

$ cat /proc/sys/vm/swappiness
60

这种文件路径的表示法（如 vm.swappiness）与 sysctl 工具中的参数名（vm.swappiness）是直接对应的。

2.2 sysctl：更优雅的配置工具

sysctl 命令提供了一个更方便的接口来与 /proc/sys 交互。

• 查看单个参数 ：

  $ sysctl vm.swappiness
  vm.swappiness = 60

• 查看所有参数 ：

  $ sysctl -a

• 模糊查询参数 ：

  $ sysctl -a | grep dirty
  vm.dirty_background_ratio = 10
  vm.dirty_ratio = 20
  ...

• 临时修改参数 ：

  $ sudo sysctl -w vm.swappiness=10
  vm.swappiness = 10

  或者使用 echo（不推荐，sysctl -w 是标准做法）：

  $ echo 10 | sudo tee /proc/sys/vm/swappiness

2.3 临时修改 vs 永久生效

使用 sysctl -w 或 echo 进行的修改是临时的，系统重启后会丢失。

要使配置永久生效，需要修改配置文件：

1. 主配置文件 ：/etc/sysctl.conf
2. 配置目录（推荐） ：/etc/sysctl.d/

推荐的做法是在 /etc/sysctl.d/ 目录下创建一个新的配置文件，例如 99-custom-tuning.conf。sysctl 服务启动时会按字母顺序加载 .conf 文件，数字越大，优先级越高。

步骤如下：

1. 创建并编辑文件：

   $ sudo nano /etc/sysctl.d/99-custom-tuning.conf

2. 在文件中添加参数（使用 sysctl 的点分格式）：

   # My Custom Tuning
   vm.swappiness = 10
   vm.dirty_ratio = 10

3. 保存文件后，使用 sysctl 命令加载配置使其立即生效：

   $ sudo sysctl -p /etc/sysctl.d/99-custom-tuning.conf
   # 或者加载所有配置
   $ sudo sysctl -p

3. 核心战场（一）：内存（VM）参数调优

内存是性能的基石。内核在内存管理上的策略直接影响了应用的稳定性和响应速度。

3.1 vm.swappiness：重新定义"交换"的意义

• 参数 ：vm.swappiness

• 范围：0 - 100（默认值通常为 60）

• 含义：这个值定义了内核使用交换空间（Swap）的积极程度。

  • 值越高（如 60）：内核会更积极地将"不活跃"的匿名内存页（Application Memory）换出到磁盘，以便为文件系统缓存（Page Cache）腾出更多空间。
  • 值越低（如 1 或 10）：内核会尽量避免使用 Swap，除非物理内存（RAM）即将耗尽。
  • 值为 0：在 3.5 内核后，0 表示只有在 OOM (Out Of Memory) 发生时才使用 Swap。在 3.5 之前，0 也会禁用 Swap。

• 调优建议：

  • 对于数据库、缓存（Redis/Memcached）等服务器 ：磁盘 I/O 远慢于内存。一旦发生 Swap，性能将急剧下降。推荐设置为 1 或 10，告诉内核"非到万不得已，不要 Swap"。
  • 对于桌面系统 ：默认的 60 是合理的，它倾向于缓存文件（如打开的程序、文档），保持系统响应的流畅性。

# /etc/sysctl.d/99-custom-tuning.conf
# 尽量避免使用 Swap，保留给紧急情况
vm.swappiness = 1

3.2 vm.dirty_background_ratio / vm.dirty_ratio：I/O 风暴的"制造者"

这是 Linux 性能调优中最重要、也最容易被误解的参数之一。

• 背景：脏页（Dirty Pages）

  当应用程序写入文件时，Linux 为了速度，会先把数据写入内存（Page Cache）并将其标记为"脏页"，然后告诉应用程序"写入完成了"。内核的 pdflush（或现代内核中的 flusher）线程会稍后在后台将这些脏页"刷"到磁盘上。

• 参数含义：

  • vm.dirty_background_ratio（默认 10%）：当脏页占总内存的百分比达到 这个值时，flusher 线程开始在后台异步刷盘。
  • vm.dirty_ratio（默认 20%）：当脏页占总内存的百分比达到 这个值时，系统认为脏页太多了。此时，所有 产生新 I/O 的进程（例如执行 write() 的应用）将被阻塞，强制它们先同步刷盘，直到脏页比例降到该阈值以下。

• 问题所在 ：

  在拥有大内存（如 128GB, 256GB）的现代服务器上，默认的百分比会带来灾难。

  • 场景 ：一台 128GB 内存的服务器，vm.dirty_ratio = 20%。
  • 计算 ：128GB * 20% = 25.6GB。
  • 后果 ：系统会允许 25.6GB 的数据堆积在内存中。当这个阈值被触发时，内核会突然尝试将 25.6GB 的数据写入磁盘。如果磁盘（特别是机械硬盘或慢速SSD）无法承受这种突发流量，系统会瞬间"卡死"，iowait 飙升，所有应用停止响应。这就是常见的"I/O 毛刺"或"性能抖动"。

3.3 现代解法：vm.dirty_background_bytes / vm.dirty_bytes

从 RHEL 6/CentOS 6 开始（内核 2.6.32+），引入了基于绝对字节数的控制，这远比百分比更科学。

• vm.dirty_background_bytes：后台开始刷盘的字节数。

• vm.dirty_bytes：阻塞进程的字节数。

• 调优建议 ：

  在内存大于 4GB 的系统上，强烈建议 使用 bytes 替代 ratio。（注：同时设置 bytes 和 ratio 时，bytes 会覆盖 ratio）。

  • 设置一个合理的、磁盘能承受的突发值，例如：
  • vm.dirty_background_bytes = 512MB (536870912)
  • vm.dirty_bytes = 1GB (1073741824)
  • 这样，系统会在脏页达到 512MB 时开始后台平滑刷盘，在达到 1GB 时才会（短暂地）阻塞应用，确保 I/O 始终是平滑的，而不是"积蓄-爆发"模式。

# /etc/sysctl.d/99-custom-tuning.conf
# 使用绝对字节数控制脏页，避免大内存下的 I/O 风暴
vm.dirty_background_bytes = 536870912
vm.dirty_bytes = 1073741824

3.4 vm.overcommit_memory：内存"超售"策略

• 参数 ：vm.overcommit_memory

• 含义：控制内核如何处理内存分配请求。

  • 0（默认）：启发式。内核会"猜测"是否有足够的内存。如果请求明显过大，会拒绝。
  • 1（超售） ：永远允许。内核总是同意应用程序的内存申请（如 malloc），即使物理内存已经不足。这是基于一个假设：应用申请的内存（如 malloc）不一定会马上使用（Touch）。
  • 2（不超售） ：严格控制。内核会拒绝超过 (Swap + RAM * vm.overcommit_ratio / 100) 的内存申请。

• 调优建议：

  • Redis ：Redis 在执行 BGSAVE（后台快照）时会 fork() 一个子进程。fork() 使用写时复制（Copy-on-Write），父子进程共享内存。如果此时 vm.overcommit_memory = 0，内核"猜测"fork() 需要一倍的内存（尽管实际不需要），可能会拒绝 fork()，导致 Redis 备份失败。

  • 因此，对于 Redis 服务器，必须设置 ：

    vm.overcommit_memory = 1

3.5 vm.vfs_cache_pressure：VFS 缓存的"回收压力"

• 参数 ：vm.vfs_cache_pressure (默认 100)

• 含义 ：控制内核回收 dentry（目录项）和 inode（索引节点）缓存的倾向。

  • > 100 ：内核更倾向于回收 VFS 缓存（dentry / inode）。
  • < 100：内核更倾向于保留 VFS 缓存，转而回收 Page Cache。
  • = 100：平衡。

• 调优建议：

  • 场景：如果你的系统有海量的小文件（例如 Web 缓存、邮件服务器），VFS 缓存会非常大。
  • 调优 ：如果系统内存紧张，但你希望保留 Page Cache（文件内容缓存），可以适当提高 此值（如 150）。如果系统有大量内存，且小文件访问频繁，可以降低此值（如 50），让 VFS 缓存更久地保留在内存中。

4. 核心战场（二）：网络（Net）参数调优

对于网络密集型应用（Nginx, HAProxy, API Gateway），网络堆栈的调优至关重要。

4.1 net.core.somaxconn & net.ipv4.tcp_max_syn_backlog：高并发的"接待"能力

在高并发场景下，应用（如 Nginx）调用 listen(fd, backlog) 来监听端口。这个 backlog 涉及两个内核队列：

1. SYN 队列（半连接队列） ：存储已收到 SYN、但尚未收到 ACK 的连接（SYN_RCVD 状态）。

   • 内核参数 ：net.ipv4.tcp_max_syn_backlog (默认 1024 或更低)

2. Accept 队列（全连接队列） ：存储已完成三次握手、等待应用调用 accept() 来取走的连接（ESTABLISHED 状态）。

   • 内核参数 ：net.core.somaxconn (默认 128)

• 问题所在 ：

  默认值（128 和 1024）在高并发下（如每秒上万请求）显然太低了。

  • somaxconn (128) 过低，会导致 Accept 队列溢出。即使服务器性能足够，新连接也会被内核拒绝（connection refused），客户端表现为连接失败。
  • tcp_max_syn_backlog 过低，在面临 SYN 攻击或高并发握手时，SYN 队列溢出，新 SYN 包被丢弃。

• 调优建议 ：

  对于高并发 Web 服务器，大幅提高这两个值。

  # /etc/sysctl.d/99-custom-tuning.conf
  # 允许系统排队的最大半连接数
  net.ipv4.tcp_max_syn_backlog = 65535
  # 允许应用 accept() 的最大全连接队列
  net.core.somaxconn = 65535

  重要提示 ：net.core.somaxconn 只是定义了上限 。应用程序（如 Nginx、Redis）在 listen() 时必须指定一个同样大的 backlog 值才能真正生效。例如 Nginx 的 listen 80 backlog=65535;。

4.2 net.ipv4.tcp_tw_reuse & net.ipv4.tcp_fin_timeout：管理 TIME_WAIT 状态

• 背景：TIME_WAIT

  TCP 连接主动关闭方会进入 TIME_WAIT 状态，等待 2*MSL（Maximum Segment Lifetime，通常为 60 秒到 120 秒）。这是为了确保"迷路"的报文在网络中消失，防止旧连接的数据干扰新连接。

• 问题 ：

  在高并发短连接（如 API 调用）的服务器上，会产生海量的 TIME_WAIT 状态。netstat -n | grep TIME_WAIT | wc -l 可能显示几万个。

  每个 TIME_WAIT 状态会占用一个端口（和少量内存）。当端口（默认 32768-61000）耗尽时，新连接将无法建立。

• 调优建议：

  1. net.ipv4.tcp_fin_timeout (默认 60s)
     • 含义：控制孤儿连接（FIN-WAIT-2）的超时时间。
     • 建议 ：可以适当调低至 30，以更快地释放资源。
  2. net.ipv4.tcp_tw_reuse (默认 0 - 关闭)
     • 含义 ：设置为 1 时，允许内核在**建立新连接（作为客户端）**时，复用 TIME_WAIT 状态的 socket，前提是协议栈确认安全（基于时间戳）。
     • 建议 ：对于频繁对外发起 连接的服务器（例如爬虫、代理服务器、调用下游 API 的微服务），这是一个安全且有效的优化。

# /etc/sysctl.d/99-custom-tuning.conf
# 开启 TIME_WAIT 复用，仅对出站连接有效
net.ipv4.tcp_tw_reuse = 1
# 减少 FIN-WAIT-2 状态的超时时间
net.ipv4.tcp_fin_timeout = 30

4.3 警惕！net.ipv4.tcp_tw_recycle 的陷阱

• net.ipv4.tcp_tw_recycle (默认 0 - 关闭)
• 历史 ：这个参数曾经被（错误地）推荐用来快速回收 TIME_WAIT。
• 严重警告 ：永远不要在现代内核上将其设置为 1。
• 原因 ：tcp_tw_recycle 依赖于 TCP 时间戳（timestamps）来判断连接的"新旧"。但是，当客户端位于 NAT（网络地址转换） 之后时（例如，多个用户通过同一个公司出口 IP 访问），NAT 设备不会转换 TCP 时间戳。服务器会收到来自同一个 IP、但时间戳"回退"的包，导致服务器错误地丢弃这些"合法"的包。
• 后果：客户端（尤其是手机端和大型局域网用户）将无法连接到你的服务器。
• 现状 ：在 Linux 内核 4.12 之后，tcp_tw_recycle 默认已被移除。但在 RHEL/CentOS 6/7 中仍然存在，切勿开启 。tcp_tw_reuse 已经足够安全和有效。

4.4 TCP 缓冲区：net.core.*mem* 与 net.ipv4.tcp_*mem*

• 含义：控制 TCP Socket 的发送（Write）和接收（Read）缓冲区大小。

• 参数：

  • net.core.wmem_default / rmem_default：默认缓冲区大小。
  • net.core.wmem_max / rmem_max：最大缓冲区大小。
  • net.ipv4.tcp_wmem / tcp_rmem：[min, default, max] 自动调整范围。

• BDP (Bandwidth-Delay Product) ：

  优化的关键是匹配 BDP = 带宽 * 延迟。

  • 场景：10Gbps 带宽，中美延迟 200ms。
  • 计算 ：BDP = (10 * 1024 * 1024 * 1024 / 8) * 0.2s ≈ 268MB。
  • 含义：为了在这种长肥网络（LFN）上跑满带宽，你需要 268MB 的缓冲区。

• 调优建议 ：

  对于常规的数据中心内部 （低延迟）或互联网 （高延迟但带宽受限）应用，默认值通常足够。

  只有在特定的大带宽、高延迟链路上（如跨国数据复制），才需要根据 BDP 大幅调高 net.core.rmem_max 和 wmem_max。

5. 核心战场（三）：文件系统与进程限制

5.1 fs.file-max：系统级文件句柄

• 含义：系统（内核）层面能打开的文件句柄总数上限。
• 查看 ：cat /proc/sys/fs/file-max
• 调优：这个值通常默认很大（如几百万）。如果你的应用（如 Nginx、Kafka）需要同时处理几十万个连接（每个连接=一个 socket=一个文件句柄），确保这个值足够大。

# /etc/sysctl.d/99-custom-tuning.conf
# 设置系统级最大文件句柄数
fs.file-max = 2000000

5.2 fs.nr_open 与 ulimit：进程级文件句柄

• fs.nr_open（内核 2.6.25+）：

  • 含义 ：单个进程 可以打开的文件句柄数上限。ulimit -n（nofile）的值不能超过这个系统上限。
  • 调优：默认值（1048576）通常足够。

• ulimit (limits.conf) ：
  fs.file-max 和 fs.nr_open 只是内核的天花板 。进程实际能打开的句柄数由 ulimit (PAM limits) 限制。

  • 问题 ：默认的 ulimit -n（soft
    limit）通常是 1024，这对于 Web 服务器来说太低了。
  • 解决 ：修改 /etc/security/limits.conf，允许特定用户或所有用户（*）打开更多文件。

# /etc/security/limits.conf
# 允许 nginx 用户打开 655350 个文件
nginx soft nofile 655350
nginx hard nofile 655350

# 允许 root 用户（如果服务以 root 启动再降权）
root soft nofile 655350
root hard nofile 655350

修改后，需要重新登录或重启服务才能生效。

6. 实战演练：优化一台高并发 Web 服务器

6.1 场景描述与问题诊断

• 系统：Nginx (proxy) + PHP-FPM (backend)，128GB 内存，SSD 磁盘。
• 问题 ：
  1. 高并发下连接失败 ：ab 压力测试时，出现 "apr_socket_recv: Connection reset by peer" 或 "connection refused"。
  2. I/O 抖动 ：系统运行平稳，但每隔几分钟，vmstat 显示 wa (I/O Wait) 突然飙升，服务响应时间变长。
  3. TIME_WAIT 过多 ：netstat -n | grep TIME_WAIT | wc -l 显示有 30000+ 个连接。

6.2 调优策略与执行

1. 创建 sysctl 配置文件 /etc/sysctl.d/99-web-server.conf：

# 1. 解决 I/O 抖动 (vm.dirty_ratio 导致)
# 128GB 内存，默认 20% = 25.6GB，灾难！
# 改用 bytes，平滑刷盘
vm.dirty_background_bytes = 536870912  # 512MB
vm.dirty_bytes = 1073741824          # 1GB

# 2. 内存与 Swap
# Web 服务器不应 Swap
vm.swappiness = 1

# 3. 解决高并发连接失败 (队列溢出)
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# 4. 解决 TIME_WAIT 过多
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
# 再次强调：不要开启 tcp_tw_recycle!

# 5. 增加端口范围（可选，但有益）
net.ipv4.ip_local_port_range = 1024 65535

# 6. 增加系统文件句柄
fs.file-max = 2000000

2. 加载配置：

$ sudo sysctl -p /etc/sysctl.d/99-web-server.conf

3. 修改 limits.conf：

# /etc/security/limits.conf
* soft nofile 655350
* hard nofile 655350

（* 通配符适用于所有用户，生产环境建议指定用户 nginx 或 www-data）

4. 修改 Nginx 配置：

# /etc/nginx/nginx.conf
worker_processes auto;
# 匹配 ulimit
worker_rlimit_nofile 655350;

events {
    worker_connections 65536; # 单个 worker 最大连接数
    multi_accept on;
}

# /etc/nginx/sites-available/default
server {
    # 匹配 somaxconn
    listen 80 default_server backlog=65535;
    ...
}

5. 重启服务：

重启 Nginx 和 PHP-FPM（或重启服务器使 limits.conf 生效）。

6.3 验证结果

1. I/O 抖动 ：持续观察 vmstat 1，wa 列应保持在低位，不再出现周期性尖峰。
2. 连接失败 ：重新运行 ab 或 wrk 高并发压力测试，"connection refused" 错误消失。
3. TIME_WAIT ：netstat 观察 TIME_WAIT 数量，虽然仍然存在（正常），但不应再成为瓶颈。

7. 调优的哲学：超越"最佳实践"

请记住，不存在"万能的"或"最佳的"内核配置。网上流传的"Linux 优化大全"往往是特定场景的产物。

调优的正确哲学是：

1. 理解你的工作负载：你的应用是 I/O 密集型？网络密集型？读多写少？短连接还是长连接？
2. 建立监控基线 ：在调优之前 ，使用 vmstat, iostat, sar, netstat, ss 以及 Prometheus/Grafana 等工具，收集系统在"正常"和"高负载"下的性能数据。
3. 一次只改一件事 ：不要一次性应用 20 个参数。一次只修改一组相关的参数（例如，只调整 dirty_bytes）。
4. 测量、修改、再测量：修改后，在相同的负载下重新测试，对比关键指标（QPS、延迟、错误率），确认调优是正向的、负向的还是无效的。
5. 理解参数的含义 ：不要修改你不理解的参数。错误的调优（如 tcp_tw_recycle）比不调优更糟糕。

8. 总结

Linux 内核调优是一项系统性工程，它介于科学与艺术之间。通过 sysctl 提供的接口，我们能够深入到操作系统的"五脏六腑"。

本文我们深入探讨了内存管理（swappiness, dirty_bytes）和网络堆栈（somaxconn, TIME_WAIT）中的关键参数，它们是影响高性能服务最常见的瓶颈点。通过一个实战案例，我们演示了如何将理论知识应用于实践，解决真实世界中的性能问题。

掌握这些工具和概念，您将不再满足于默认配置，而是能够根据具体需求，打造出真正高性能、高稳定性的 Linux 系统。

---

9. 相关链接

1. Kernel.org - /proc/sys/ Documentation (Linux 内核官方文档，最权威的参数说明)

2. 可疑链接已删除\] (红帽官方的调优指南，非常系统和深入)

3. TCP/IP tuning for scalability (Linux 内核文档中关于网络扩展性的调优)
4. "The USE Method" (by Brendan Gregg) (一种系统性的性能问题诊断方法：Utilization, Saturation, Errors)

✨ 坚持用 清晰易懂的图解 + 代码语言， 让每个知识点都 简单直观 ！

🚀 个人主页 ：不呆头 · CSDN

🌱 代码仓库 ：不呆头 · Gitee

📌 专栏系列 ：

• 📖 《C语言》
• 🧩 《数据结构》
• 💡 《C++》
• 🐧 《Linux》

💬 座右铭 ： "不患无位，患所以立。"