本文结合 Linux 5.0.1 内核源码，浅析 Linux 进程管理中的完全公平调度器（CFS）工作机制。
最近接手的一个 Linux C++ 项目，编译速度把我折腾得怀疑人生。
—— 编译经过优化，源代码一行未改，全编译时间硬是从 半个小时 缩短到 3 分钟 ！！！（OMG，此处省略一万字…）
划重点，三板斧：
一致性哈希算法，是后端比较常用的一种数据路由策略。本文介绍一下它的算法原理，以及使用场景。
最近阅读了 C++ 智能指针的部分实现源码，简单总结和记录一下 std::share_ptr/std::weak_ptr 内部结构和工作原理。
很多朋友以为 Redis 是单线程程序，事实上它是 多进程 + 多线程 混合并发模型。
本文使用的 Redis 版本：6.0.20。
通过 wireshark 抓取 HTTPS 包，理解 TLS 1.2 安全通信协议的握手流程。
重点理解几个点：
会话密钥 进行内容对称加密通信，避免传输会话密钥被中间人窃取。证书链 验证该证书，以此确认服务端身份。本文通过测试和结合 std::vector::emplace_back 实现源码，去理解它的功能和作用。
QT 的信号与槽技术，是一种用于对象间通信的机制。它允许一个对象发出一个信号，而其他对象可以通过连接到该信号的槽来接收并处理该信号。
本文将通过调试走读 QT (5.14.2) 信号与槽开源源码，理解它的工作原理。
C++ 有什么推荐的线程池库吗？…
最近翻阅侯捷先生的两本书：（翻译）《深度探索 C++ 对象模型》 和 《C++ 虚拟与多态》，获益良多。
要理解多态的工作原理，得理解这几个知识点的关系：虚函数、虚函数表、虚函数指针、以及对象的 内存布局。
std::sort 是标准库里比较经典的算法，它是一个复合排序，结合了几种算法的优点。
走读 Linux（5.0.1）源码，理解 TCP 网络数据接收和读取工作流程（NAPI）。
要搞清楚数据的接收和读取流程，需要梳理这几个角色之间的关系：网卡（本文：e1000），主存，CPU，网卡驱动，内核，应用程序。
本章整理了一下服务端 tcp 的第三次握手和 epoll 内核的等待唤醒工作流程。
做服务端多年，但是学习 linux 内核才一年多，深入研究源码后，解决了我之前的很多疑惑。
前段时间在回答知乎问题时，顺便做了个小结，现在把自己的回答整理了一下搬到这里。
学习流程：熟练使用应用层接口 -> 理解工作原理 -> 搭建内核调试环境 -> 画图串联知识点 -> 解决问题。
如题，主要搭建 linux 内核的调试环境。
qemu 模拟器运行 linux，然后通过 gdb 调试 linux 内核源码。
前段时间曾出过两个视频，比较粗糙，最近重新整理了一下环境搭建流程，还加入了网桥搭建流程，可以调试 linux 内核虚拟网卡的驱动部分源码。
SO_REUSEPORT (reuseport) 是网络的一个选项设置，它能开启内核功能：网络链接分配 内核负载均衡。
该功能允许多个进程/线程 bind/listen 相同的 IP/PORT，提升了新链接的分配性能。
nginx 开启 reuseport 功能后，性能有立竿见影的提升，我们结合 tcp 协议分析 nginx 的 reuseport 功能。
reuseport 也是内核解决 惊群问题 的优秀方案。
每个进程可以 bind/listen 相同的 IP/PORT，相当于每个进程拥有独立的 listen socket 的完全队列，避免了共享 listen socket 的资源争抢，提升了并发的吞吐。
内核通过哈希算法，将新链接相对均衡地分配到各个开启了 reuseport 属性的进程，所以资源的负载均衡得到解决。
惊群比较抽象，类似于抢红包 😁。它多出现在高性能的多进程/多线程服务中，例如：nginx。
探索惊群 系列文章将深入 Linux (5.0.1) 内核，透过 多进程模型 去剖析惊群现象、惊群原理、惊群的解决方案。
Linux 操作系统，为了避免用户程序非法操作设备资源，需要限制进程的操作权限，这样内核为用户程序提供了一组交互的接口，用户程序通过这组接口进行 系统调用。
本文将会通过调试方式，从用户程序到内核，理解一下系统调用的工作流程。
文章 Linux 内核源码基于 Linux 5.0.1。
走读网络协议栈 tcp 的内核源码（Linux - 5.0.1 下载）。通过 Linux 内核源码理解 tcp 三次握手状态变化。
因为我走读的是 Linux 5.0.1 源码，与旧版的 Linux 3.x 系列比较，新版的三次握手的状态已经发生改变，这个需要注意一下。
最近项目增加了一个模块，在 Centos 系统压测，进程一直不释放内存。因为新增代码量不多，经过排查，发现 stl + glibc 这个经典组合竟然有问题，见鬼了！
通过调试和查阅 glibc 源码，好不容易才搞明白它 “泄漏” 的原因：内存碎片！
碎片将大块的空闲连续内存块割裂，导致空闲内存块没有达到返还系统的阈值，内存回收失败！
深层原因：glibc 内部内存池管理空闲内存的策略问题，ptmalloc2 内存池的 fast bins 快速缓存和 top chunk 内存返还系统的特点导致。
协程“栈”空间，有独立栈和共享栈，重点理解一下协程共享栈。
文章主要对 tcp 通信进行 epoll 源码走读。
Linux 源码：Linux 5.7 版本。epoll 核心源码：eventpoll.h / eventpoll.c。
搭建 epoll 内核调试环境视频：vscode + gdb 远程调试 linux (EPOLL) 内核源码
即时通讯，消息有多种类型，单聊，群聊等等。
群组聊天消息管理比较麻烦，因为涉及到多个用户，尤其是千人群组，1 个人发送消息，999 个人接收，数据库针对每个用户存储一条记录吗？这个量级的数据存储是十分恐怖的，所以消息的存储策略显得十分重要。