这些年积累了不少笔记资料，大致分三类：

1. 看到好的资料内容，随手就保存下来。

2. 在公司研发时记录下来的各种笔记资料。

3. 自己的知识学习心得，慢慢整理成了现在的博客。

保存下来的资料内容和公司资料，很多早就积了灰；反倒是博客里的内容，还会经常翻看、经常维护。

不过这些大多是零散的「机械知识」，彼此之间很难建立有机的链路。最近就想着，是不是该找个知识库好好管起来。下载了黑曜石（Obsidian）体验了一下，感觉不太好上手——与其迁就别人的设计，不如自己撸一个：挑出自己最常用的功能实现，还能在这个基础上随心所欲地做个性化。

于是借助神器 Claude Code，前后花了两个星期左右，初见成效——现在已经能日常使用了，体验下来还挺不错。

最近维护了几个 Go 后台系统，涉及到几种长连接 websocket 读写并发模型，简单回顾和归纳一下：

1. 单读协程 + 加锁直写：每连接 1 个 goroutine，写通过锁串行化。
2. 读写双协程 + channel：每连接 2 个 goroutine，写收敛到单协程，天然带背压。
3. 事件驱动（gnet / reactor）：没有 “每连接协程”，少量 event-loop 用 epoll 管全部连接。

Claude code 神器啊！基于 “先问后做” 原则，用它做项目，快一个月几乎没有手动写过代码。从业多年，曾无数次想象过行业的发展，就是未曾想到过，编程工具如今发展到如此智能的地步，感觉 AI 已经快速走在解放人类双手的路上了。

尽管 AI 发展迅速，它也会像人一样犯错：修复一个 bug，却引入几个新 bug，但是只要你输入的需求文档思路清晰，实现步骤有条理，阐述逻辑严谨，cc 就会实现得非常好。

cc 支持接入不同厂商的大模型，而模型之间的解决问题能力往往天差地别。所以条件允许的话，请务必选用最好的大模型，最好的大模型，最好的大模型 …… 重要的事情说三遍！！！

Claude code（后面简称 cc）

项目是一个基于 gnet 的事件驱动长连接网关，核心网络模型是 reactor + epoll，少量 event-loop 管理大量连接。

用户在不断增长过程中，出现了内存占用持续异常上涨现象。

为了定位和修复，给服务增加了 pprof 端口（6060），通过 heap profile 对比分析，锁定了泄漏源头。

再由 pprof 数据反查业务代码，定位到 gnet 的 Peek() / Next() / Discard() API 使用不当，最终彻底修复。

近期将博客迁移至阿里云 Docker 环境后，网站出现流量异常问题。

经排查，瓶颈主要集中于图片资源与服务端缓存配置。通过一系列针对性优化，页面首次加载流量由 7 MB 显著优化至 500KB 左右，性能得到大幅提升。

本文结合 Linux 5.0.1 内核源码，浅析 Linux 进程管理中的完全公平调度器（CFS）工作原理。

最近接手的一个 Linux C++ 项目，编译速度把我折腾得怀疑人生。

—— 编译经过优化，源代码一行未改，全编译时间硬是从 半个小时 缩短到 3 分钟 ！！！（OMG，此处省略一万字…）

划重点，三板斧：

1. 多核并行编译： make -j N
2. 编译缓存工具： ccache
3. 分布式编译工具：distcc

谷歌验证码 采用基于共享密钥的动态验证机制。服务端与客户端使用相同的密钥，并据此分别生成匹配的动态验证码以完成校验。

尽管共享密钥本身并非绝对安全，但由于它仅在初次设置时低频次传输，且作为二次验证使用，因此仍能为核心账户安全提供一道坚实有效的屏障。

一致性哈希是后端系统中解决数据路由与负载均衡问题的关键技术。理解其工作原理，对于设计高扩展、高可用的分布式系统至关重要。本文将介绍其算法思想与经典应用场景。

最近阅读了 C++ 智能指针的部分实现源码，简单总结和记录一下 std::share_ptr/std::weak_ptr 内部结构和工作原理。

很多朋友以为 Redis 是单线程程序，事实上它是 多进程 + 多线程 混合并发模型，这样能利用多核优势，提高性能。

• 子进程持久化：重写 aof 文件 / 保存 rdb 文件。
• 多线程：主线程 + 后台线程 + 新增网络 IO 线程（Redis 6.0）。

通过 wireshark 抓取 HTTPS 包，理解 TLS 1.2 安全通信协议的握手流程。

重点理解几个点：

1. TLS 握手流程：通过 wireshark 抓取 HTTPS 包理解。
2. 协商加密：双方通过 ECDHE 椭圆曲线的密钥交换算法，协商出共享的 会话密钥 进行内容对称加密通信，避免传输会话密钥被中间人窃取。
3. CA 证书：证书用来验证服务端的合法性。证书类似于身份证，可以证明某人是某人，当然身份证可以伪造，一般人可能识别不出来，但是国家相关部门可以验证你的身份合法性。同理，服务端可以通过 CA 证书识别自身身份，客户端接收服务端发送的证书，并通过 证书链 验证该证书，以此确认服务端身份。

QT 的信号与槽技术，是一种用于对象间通信的机制。它允许一个对象发出一个信号，而其他对象可以通过连接到该信号的槽来接收并处理该信号。

本文将通过调试走读 QT (5.14.2) 信号与槽开源源码，理解它的工作原理。

C++ 有什么推荐的线程池库吗？…

最近翻阅侯捷先生的两本书：（翻译）《深度探索 C++ 对象模型》 和 《C++ 虚拟与多态》，获益良多。

要理解多态的工作原理，得理解这几个知识点的关系：虚函数、虚函数表、虚函数指针、以及对象的 内存布局。

• 深入探索 C++ 多态 ① - 虚函数调用链路
• 深入探索 C++ 多态 ② - 继承关系
• 深入探索 C++ 多态 ③ - 虚析构
• 深入探索 C++ 多态 ④ - 模板静态多态

std::sort 是标准库里比较经典的算法，它是一个复合排序，结合了几种算法的优点。

走读 Linux（5.0.1）源码，理解 TCP 网络数据接收和读取工作流程（NAPI）。

要搞清楚数据的接收和读取流程，需要梳理这几个角色之间的关系：网卡（本文：e1000），主存，CPU，网卡驱动，内核，应用程序。

本章整理了一下服务端 tcp 的第三次握手和 epoll 内核的等待唤醒工作流程。

惊群比较抽象，类似于抢红包 😁。它多出现在高性能的多进程/多线程服务中，例如：nginx。

探索惊群 系列文章将深入 Linux (5.0.1) 内核，透过 多进程模型 去剖析惊群现象、惊群原理、惊群的解决方案。

1. 探索惊群 ①（★）
2. 探索惊群 ② - accept
3. 探索惊群 ③ - nginx 惊群现象
4. 探索惊群 ④ - nginx - accept_mutex
5. 探索惊群 ⑤ - nginx - NGX_EXCLUSIVE_EVENT
6. 探索惊群 ⑥ - nginx - reuseport
7. 探索惊群 ⑦ - 文件描述符透传

走读网络协议栈 tcp 的内核源码（Linux - 5.0.1 下载）。通过 Linux 内核源码理解 tcp 三次握手状态变化。

因为我走读的是 Linux 5.0.1 源码，与旧版的 Linux 3.x 系列比较，新版的三次握手的状态已经发生改变，这个需要注意一下。

im - 即时通讯，支持功能：文字 + 音视频 + 文件传输。分布式服务架构，支持海量用户。

最近项目增加了一个模块，在 Centos 系统压测，进程一直不释放内存。因为新增代码量不多，经过排查，发现 stl + glibc 这个经典组合竟然有问题，见鬼了！

通过调试和查阅 glibc 源码，好不容易才搞明白它 “泄漏” 的原因：内存碎片！

碎片将大块的空闲连续内存块割裂，导致空闲内存块没有达到返还系统的阈值，内存回收失败！

深层原因：glibc 内部内存池管理空闲内存的策略问题，ptmalloc2 内存池的 fast bins 快速缓存和 top chunk 内存返还系统的特点导致。

co_kimserver 是笔者基于协程库 libco 开发的一个支持分布式微服务的高性能 TCP 网络通信框架。

详细请查看：github 。

协程“栈”空间，有独立栈和共享栈，重点理解一下协程共享栈。

火焰图是一种基于 SVG 格式的矢量图，由 Linux perf 性能分析工具采集的采样数据生成。它通过将软件在系统中的运行行为采样数据转化为图形化展示，为性能分析提供直观的可视化结果。

走读 Linux 内核源码（5.0.1），理解 epoll 的 lt / et 模式区别：

1. 两个模式，事件通知方式不同，lt 持续通知直到处理事件完毕，et 一般只通知一次，不管事件是否处理完毕。
2. et 模式，可以使得就绪队列上的新的就绪事件能被快速处理。
3. et 模式，可以避免共享 “epoll fd” 场景下，发生类似 惊群问题。

epoll 详细信息参考《[epoll 源码走读] epoll 实现原理》。

Nginx 内存池 (ngx_palloc.c) 专为优化小内存操作而设计。它通过将多次细碎的内存申请汇聚为少量批次请求，减少了与操作系统底层分配器的直接交互，以此提升整体性能。

该内存池作为一种轻量级实现，其小内存分配器采用了 下次适配 算法。该算法从上次成功分配的地址开始线性扫描，并选择第一个足够大的空闲内存块。这种策略旨在减少搜索开销，并利用缓存局部性原理。

即时通讯，消息有多种类型，单聊，群聊等等。

群组聊天消息管理比较麻烦，因为涉及到多个用户，尤其是千人群组，1 个人发送消息，999 个人接收，数据库针对每个用户存储一条记录吗？这个量级的数据存储是十分恐怖的，所以消息的存储策略显得十分重要。

客户端 <–> 文件服务器代理 <–> FDFS