Tips of Linux C programming
这篇文章分享了Linux内核和GNU C中一些不那么为人所知却非常实用的编程技巧。作者从链表的非常规定义讲起，展示了如何将链表节点嵌入到数据结构中，并利用`container_of`宏从节点地址反推出宿主结构体，这种方法比传统教科书定义更灵活优雅。 随后，文章深入到编译器与硬件层面：介绍了用`likely`/`unlikely`宏提示编译器优化分支预测，减少流水线冲刷；演示了通过内联汇编和`lock`指令前缀实现原子加法，保证多处理器环境下的数据一致性；还探讨了GNU C特有的零长度数组特性，用于在运行时动态分配结构体尾部的变长数组。最后，简短提到了三目运算符`a = x ? : y`这种简洁的省略写法。 这些技巧都源自真实的内核开发或GCC特性，能帮助C程序员写出更高效、更地道的代码。文章穿插了关键的代码片段和原理剖析，对希望提升底层编程技巧的读者很有启发。
libev ev_io源码分析
这篇深入分析了libev事件库中负责I/O事件监听的ev_io组件。作者从项目实践中的疑问出发，首先梳理了libev的核心抽象：所有watcher的基类`ev_watcher`，以及统一管理所有watcher状态的`ev_loop`结构。 文章重点剖析了ev_io的实现机制。它解释了ev_io如何“继承”`ev_watcher_list`以实现链表管理，并与一个名为`ANFD`的结构（用于映射文件描述符与事件链表）协同工作。对ev_io最关键的几个操作——添加、执行回调和删除——进行了流程拆解。 例如，添加watcher时并非立即调用`epoll_ctl`，而是先记录到一个待处理队列中，在下次循环的`epoll_wait`前才批量修改内核事件，这是一个精巧的优化。唤醒与回调过程则展示了如何根据epoll返回的结果，从事件链表中找到匹配的watcher并触发其回调函数。 整体来看，这篇文章清晰地展示了libev如何用简洁的C结构实现高效的事件驱动模型，对于想理解事件循环底层机制，特别是I/O多路复用与应用层封装之间交互的开发者来说，提供了很好的实现视角。
使用gdb调试运行时的程序小技巧
这篇讲的是开发者用GDB调试正在运行的程序时，那些常常让人头疼的场景和作者摸索出的实用解法。文章开门见山，直指三个高频痛点：如何在不中断服务的情况下探查程序状态、如何高效地批量查看变量和Core文件、以及如何“透视”链表或树这类复杂数据结构。 作者没有停留在理论，而是给出了一套完整的“武器库”。针对第一个场景，他分享了一个精巧的`runstack.sh`脚本，通过一行命令就能附加到目标进程，查看甚至修改全局变量的值，而无需重启服务。对于需要批量操作的场景，他展示了如何编写GDB脚本（.gdb文件）来一次性执行多个调试命令，以及如何改造脚本来快速分析多个Core文件的堆栈，快速归类问题。文章还附上了完整的测试代码和用例，从编译到执行，手把手演示效果。 这些技巧源于对Systemtap等工具复杂性的规避，和对生产环境调试需求的深刻理解。作者提供的不仅是几个命令，更是一套结合了Shell与GDB的轻量级工作流，能帮助开发者在复杂的线上环境中更安全、更高效地定位和解决问题。
近期Imgsrc一处内存泄露问题的查找和解决
这篇讲的是作者在维护 imgsrc 服务时，如何定位并解决一处顽固的内存泄露问题。 问题最初表现为服务的内存占用在持续缓慢增长，但业务逻辑本身似乎并无大碍。经过一番深入排查，作者将矛头指向了底层广泛使用的 ImageMagick 图像处理库，最终确认泄露根源正是该库自身的一个 bug。由于影响范围可能较广，作者认为有必要将这次“踩坑”经历记录下来。 文章详细叙述了从现象观察、怀疑对象筛选到最终锁定库级别 bug 的完整排查思路。对于同样需要处理大量图像、并可能依赖 ImageMagick 的技术团队而言，这篇分享提供了一个清晰的故障排查范例：当上层代码看似无误时，问题有时就藏在底层依赖之中。作者通过解决一个具体的技术痛点，为同行们排除了潜在的隐患。
Transfer 2.0 介绍
这篇讲的是 Transfer 2.0 的全面升级，作者从实时
linux异步IO编程实例分析
这篇讲的是Linux Native AIO（异步IO）在Direct IO场景下的编程实例。作者从Direct IO绕过系统页缓存、直接与磁盘交互的特点出发，点明了在这种模式下引入异步机制的必要性——因为同步IO模型会因等待磁盘操作而导致线程阻塞，影响性能。 文章核心在于对比，它揭示了异步IO与传统同步IO在处理磁盘请求时的关键差异：同步模型下应用线程必须等待IO完成，而异步模型允许内核在后台处理数据传输，应用则能立即继续执行或处理其他任务。这种机制在需要高吞吐、低延迟的数据库或存储系统中尤为适用。 作者进一步将聚焦于Linux Native AIO的具体实现，分析其编程接口与内核工作原理。内容不仅解释了“为何需要”，更深入到“如何实现”，通过实例探讨了如何配置和使用AIO接口来真正提升磁盘访问的并发性能，避免了同步调用带来的瓶颈。
硬件虚拟化技术浅析
这篇讲的是硬件虚拟化技术的入门解析，作者从虚拟化技术的发展脉络和核心目标出发，系统梳理了CPU、内存、I/O等关键模块的虚拟化实现路径。文章重点对比了全虚拟化与半虚拟化两种主流技术方案：全虚拟化通过Hypervisor拦截和模拟特权指令，无需修改客户机操作系统，兼容性强但性能开销相对较大；半虚拟化则通过修改客户机内核，将部分敏感操作直接交由Hypervisor处理，实现了更优的性能，但需要操作系统配合。 作者进一步剖析了两种方案在Xen、KVM等主流Hypervisor中的具体体现与演进。文章指出，技术选型往往需要在兼容性、性能与实现复杂度之间权衡，例如云服务器场景下KVM因其与Linux内核的深度集成而成为主流选择，而对老旧系统的兼容则可能仍需全虚拟化方案支撑。这篇解析为理解现代云计算和数据中心底层基础设施提供了一个清晰的技术框架。
关于squid请求源服务器的响应中带Vary头
这篇讲的是 Squid 缓存代理在处理源服务器响应时，一个可能被忽略但至关重要的细节——Vary 响应头，特别是针对内容协商场景。 文章从实际问题出发：当源服务器返回的响应中缺少了关键的 “Vary: Accept-Encoding” 头部时，会发生什么？作者深入剖析了这个问题，指出 Vary 头是 HTTP 缓存正确性的基石。它告诉缓存（如 Squid）：“这个资源的不同变体是基于请求的哪个字段来区分的”。对于 `Accept-Encoding`，它意味着不同的压缩格式（如 gzip, br）对应不同的响应体。 如果缺失这个头，Squid 可能会错误地将一个压缩版本缓存，并直接提供给不支持压缩的客户端，导致乱码或渲染错误。文章清晰地梳理了从问题现象（如客户端接收到乱码）到根因（缓存了不匹配的变体）的完整逻辑链，并给出了具体的排查方向和配置建议，例如如何通过 `Vary` 头或 `Cache-Control` 来引导 Squid 的行为。 对于使用 Squid 或任何反向代理的开发者来说，这是一个典型的缓存陷阱。文章的价值在于将抽象的 HTTP 规范落地到具体的故障场景，提醒大家在架构涉及内容协商时，务必关注并正确设置 Vary 头，以确保缓存的准确性。
libeio源码分析 – 主流程
这篇源码分析文章聚焦于 libeio 这个高性能异步 I/O 库的主流程，带我们深入其内核。作者没有泛泛而谈，而是直接拆解了从初始化、到请求提交、事件循环处理，再到回调执行的完整路径，清晰地勾勒出一个异步任务从诞生到完成的生命周期。 文章的核心亮点在于对 libeio 如何实现“异步”的剖析。它并非通过复杂的多线程，而是巧妙地利用事件循环和 epoll/kqueue 等系统调用，将 I/O 操作与回调解耦。作者具体分析了 eio_submit、eio_poll 等关键函数，揭示了请求队列的管理、工作线程的调度以及如何最小化系统调用开销等实现细节。这些内容让读者能直观感受到，一个优秀的异步库是如何在底层将复杂的并发问题，转化为一个高效、有序的事件驱动流程。 读完这篇文章，你不仅能理解 libeio 的内部工作机制，更能领会事件驱动模型在 I/O 密集型场景中的精妙设计思想，对编写高性能网络应用大有裨益。
linux后端服务程序之信号处理
这篇讲的是Linux后端开发中一个看似基础但至关重要的知识点：信号处理。作者从“信号是什么”切入，指出它本质上是进程间的软件中断，其核心特征在于异步性——事件何时发生，进程无从预知。 文章的重点，落在了如何为需要7x24小时不间断服务的后台守护进程（daemon）正确处理信号上。因为一旦处理不当，进程可能意外退出或陷入无法响应的状态，直接影响服务稳定性。 作者没有停留在概念科普，而是直接关联到实际开发场景，解释了为什么守护程序必须对信号建立一套严谨的响应机制。对于编写健壮的Linux服务程序而言，理解并妥善处理这些异步事件，是避免线上隐形故障、保障服务长稳运行的关键一步。