riak_sysmon使用和源码分析
这篇讲的是 riak_sysmon 这个 Erlang 监控工具的实战与原理拆解。它基于 Erlang VM 内置的 `system_monitor` BIF 函数，专注于捕获四类关键事件：进程堆内存过大、垃圾回收耗时过长、端口（文件或套接字）繁忙，以及节点间网络繁忙。 文章的核心是剖析其内部的两个进程协作。`riak_sysmon_filter` 进程扮演“过滤器”角色：它读取配置的阈值，启动底层监控，并对原始消息进行限流（例如每秒只上报前 N 条），避免告警风暴。过滤后的消息被通知给一个 `riak_sysmon_mgr` 的 `gen_event` 进程，由用户注册的 handler 来具体处理。 作者通过一个制造内存增长的 gen_server 示例，直观展示了当进程堆超过 `heap_word_limit` 后，系统如何触发并报告 `large_heap` 事件。这种 filter + event manager 的设计很巧妙：filter 解决了原生 `system_monitor` 消息洪泛和单一接收者的局限，而 event manager 则将事件处理解耦，允许灵活扩展。
BufferedIO和DirectIO混用导致的脏页回写问题
这篇文章源于一次线上问题排查：曲山同学遇到系统性能抖动，最终发现罪魁祸首是 BufferedIO 与 DirectIO 的混用引发的脏页回写风暴。文章详细拆解了问题机制——当文件同时存在两种 I/O 访问路径时，操作系统对脏页的回写策略可能被扰乱，导致大量不必要的刷盘操作与延迟毛刺。作者不仅定位了内核页缓存与 IO 调度层的交互细节，还给出了具体的规避方案：比如统一 I/O 模型、调整文件系统挂载参数，或对关键路径做隔离。对于需要高性能存储或处理海量数据的应用开发者来说，这个案例清晰地展示了底层 IO 选择可能带来的隐性坑点，以及如何通过系统性的分析来规避类似风险。
MariaDB数据库5.5.27 HASH JOIN源码解读
这篇讲的是MariaDB 5.5.27版本中HASH JOIN特性的底层源码实现。作者从MySQL与MariaDB的分支差异切入，指出MariaDB为优化等值JOIN性能而引入了该特性，并深入其C++源码，拆解了从优化器决策到执行器运行的全过程。 文章的核心在于剖析HASH JOIN的执行逻辑：它如何为内表建立内存哈希表，再逐行探测外表以完成连接。作者特别指出了几个巧妙的设计点，比如在内存压力较大时，系统如何自动切换为分片处理模式，将哈希表溢出写入磁盘，从而在有限资源下完成大表连接。同时，文中也对比了其与MySQL原有Block Nested Loop算法的效率差异，并提供了实际执行计划的对比分析。 对于想理解数据库连接算子如何从算法落地到具体代码的读者，这篇源码解读提供了一个清晰的范本，展示了工程实现中如何在性能与资源间做权衡。
Tomcat 5源码分析
这篇分析聚焦于Tomcat 5的内部世界，作者从启动入口`Bootstrap`类开始，一路追查到请求处理的核心链条。文章没有停留在泛泛的流程介绍，而是将分析重点落在了几个关键设计上：比如`Server`、`Service`、`Connector`这几个组件是如何被组装并启动的，它们之间清晰的职责划分；又如请求是如何从`Acceptor`线程进入，最终由`Worker`线程池分配给具体的`Container`进行处理的。 更深入的部分在于对`Valve`责任链的剖析。文章展示了像`AccessLogValve`和`RemoteAddrValve`这样的组件，是如何像套娃一样被依次嵌套调用，从而在请求到达实际应用前，完成日志记录、地址过滤等横切关注点。这种基于责任链的过滤器模式，在今天看来依然是架构设计的经典范例。 尽管分析的是一个较早的版本，但其中所阐述的**模块化拆分、线程模型设计以及基于链式处理的扩展思想**，对于理解现代Web容器乃至许多网络服务器的内核，依然具有很高的参考价值。作者通过追踪源码，将这些抽象的设计模式与具体的Java类对应起来，让阅读者能清晰地看到理论是如何落地的。
linux异步IO编程实例分析
这篇讲的是Linux Native AIO（异步IO）在Direct IO场景下的编程实例。作者从Direct IO绕过系统页缓存、直接与磁盘交互的特点出发，点明了在这种模式下引入异步机制的必要性——因为同步IO模型会因等待磁盘操作而导致线程阻塞，影响性能。 文章核心在于对比，它揭示了异步IO与传统同步IO在处理磁盘请求时的关键差异：同步模型下应用线程必须等待IO完成，而异步模型允许内核在后台处理数据传输，应用则能立即继续执行或处理其他任务。这种机制在需要高吞吐、低延迟的数据库或存储系统中尤为适用。 作者进一步将聚焦于Linux Native AIO的具体实现，分析其编程接口与内核工作原理。内容不仅解释了“为何需要”，更深入到“如何实现”，通过实例探讨了如何配置和使用AIO接口来真正提升磁盘访问的并发性能，避免了同步调用带来的瓶颈。
libeio源码分析 – 主流程
这篇源码分析文章聚焦于 libeio 这个高性能异步 I/O 库的主流程，带我们深入其内核。作者没有泛泛而谈，而是直接拆解了从初始化、到请求提交、事件循环处理，再到回调执行的完整路径，清晰地勾勒出一个异步任务从诞生到完成的生命周期。 文章的核心亮点在于对 libeio 如何实现“异步”的剖析。它并非通过复杂的多线程，而是巧妙地利用事件循环和 epoll/kqueue 等系统调用，将 I/O 操作与回调解耦。作者具体分析了 eio_submit、eio_poll 等关键函数，揭示了请求队列的管理、工作线程的调度以及如何最小化系统调用开销等实现细节。这些内容让读者能直观感受到，一个优秀的异步库是如何在底层将复杂的并发问题，转化为一个高效、有序的事件驱动流程。 读完这篇文章，你不仅能理解 libeio 的内部工作机制，更能领会事件驱动模型在 I/O 密集型场景中的精妙设计思想，对编写高性能网络应用大有裨益。
write(2)在磁盘满的时候的行为
write(2)这个看似简单的系统调用，在磁盘满时的行为其实相当微妙，且容易让人困惑。这篇技术博客深入剖析了其中的关键细节。 文章的核心发现是，当磁盘空间耗尽时，write(2)并不总是立即返回错误。它的行为取决于几个关键变量：文件是否以`O_NONBLOCK`模式打开，以及写入的是否是常规文件或管道。对于常规文件，在非阻塞模式下，内核可能会先“接纳”数据，将其放入内核缓冲区，此时调用甚至可能立即返回成功，但随后的`fsync`或`close`才可能触发真正的空间不足错误（ENOSPC）。而更令人警惕的是，如果写入的是管道，并且使用`O_NONBLOCK`，write(2)可能直接返回`EAGAIN`，这意味着数据并未被写入，存在丢失风险。 作者详细拆解了内核`generic_perform_write`函数的执行路径，解释了这些不同行为背后的实现逻辑。这篇文章的价值在于，它澄清了开发者常有的“write成功即数据落盘”的误解，明确指出了在磁盘I/O的边界条件下，可靠性需要依赖更严格的检查（如fsync）和对不同文件描述符特性的深入理解。
Linux 内核中的 KMP 实现
这篇讲的是Linux内核里一个你可能没想到的细节：它自己也实现了一套KMP算法。当我们谈到内核，常想到进程调度、内存管理，但字符串搜索同样是基础需求，无论是解析命令行参数还是处理网络协议。代码就藏在`lib/ts_kmp.c`里。 文章带我们看了这套实现的思路。它并非对教科书算法的简单照搬，而是充分考虑了内核环境的特殊性：比如如何与内核的内存管理机制配合，如何在内核态下追求高效与安全的平衡。作者拆解了其数据结构与函数逻辑，展示了从模式串预处理到文本匹配的完整流程，让我们看到一个经典算法是如何在贴近底层的场景中“落地生根”的。 读下来你会发现，即使是处理字符串搜索这样的“小事”，内核开发者也展现了其严谨和巧妙的设计，确保既可靠又高效。对于想了解内核实现细节的读者，这是一个很好的切入点。
free命令中的buffers和cached
这篇讲的是Linux系统中free命令输出结果里buffers和cached字段的区别。作者从同事的日常疑问出发，分享了对这两个内存管理概念的深入解析，旨在帮助读者准确理解系统内存状态。 在Linux的内存管理中，buffers指的是块设备缓冲区，主要用于缓存文件系统元数据和块I/O操作的数据，比如磁盘写入的临时存储；而cached则是页缓存，用于缓存已读取的文件内容，以提升重复访问的性能。文章详细对比了它们的实现机制：buffers通常与底层磁盘块直接关联，数据可能在系统重启后丢失；cached则基于内存页，可以持久化存储文件内容，即使进程结束后也可能保留。 关键差异在于，buffers更侧重于优化原始磁盘操作，适合频繁的读写场景，如数据库或日志处理；cached则专注于文件级别的缓存，适合多次读取相同文件的应用
lua metatable使用和源码分析(三)
这篇是“Lua元表源码分析”系列的第三篇，将视角从用户自定义表转向了Lua的基础——数字、字符串等基本类型是如何挂载并使用元表的。作者并没有停留在“数字也有元表”这个结论上，而是带着读者钻进源码，看Lua的实现者如何为这些内建类型维护和查找它们的元表。 文章的核心在于剖析`luaL_getmetafield`等关键函数的实现逻辑。最巧妙的一点在于，Lua并非为每个数字都存储一个元表，而是在`lua_State`或全局状态中，为数字、字符串等不同类型分别维护了一个共享的、静态的默认元表。源码分析揭示了当对数字调用方法时，虚拟机是如何一步步索引到这个全局默认元表，并执行其中定义的`__add`、`__index`等元方法的。这个设计既保证了功能的完整性，又极大地节省了内存。 通过这篇分析，读者不仅能理解“如何用”，更能看清Lua为了保持语言的一致性和性能，在底层做出的精巧权衡。它清晰地展示了，用户定义的元表机制与语言内建的元表机制，是如何在同一套引擎规则下协同工作的。
lua metatable使用和源码分析(二)
作者延续上篇对 Lua 元表 `__index` 的探讨，将镜头推进到 `__add` 这个算术事件上，带你从虚拟机核心 `luaV_execute` 出发，追踪元表调度的具体路径。文章不是简单地罗列用法，而是扎实地潜入底层，展示当代码执行到加法操作时，虚拟机如何一步步检查元方法、完成调度。 这种源码级的剖析让 Lua 的“表”与“元表”之间的魔法变得清晰可循。作者没有停留在概念，而是通过关键函数调用链的梳理，揭示了机制运作的实质。对于想理解语言设计精妙之处，或是需要深度调试的开发者来说，这提供了一份非常具体的实现地图。 读完你会对 Lua 如何优雅地扩展基本运算有更透彻的认识，而不只是停留在“它能这么做”的层面。
lua metatable使用和源码分析(一)
这篇讲的是Lua中元表（metatable）的使用与底层源码实现。作者从元表的核心机制出发，解释了它如何像C++的运算符重载一样，为表这类复合结构赋予自定义行为——例如，当对两个表执行加法时，Lua并非直接报错，而是会检查元表中是否存在名为`__add`的元方法（metamethod），如果找到就调用对应的函数来执行加法逻辑。 文章不仅停留在用法层面，还深入到了源码分析。它会带你看懂Lua虚拟机是如何一步步查找和调用元方法的，让你理解这套机制在内部是如何高效、优雅地实现的。对于想要真正掌握Lua“黑魔法”并看透其设计巧思的开发者来说，这是一个很好的切入点。
gcc对Template Template Parameters的兼容性
这篇讲的是一个具体而常见的C++编译兼容性问题。作者从一位网友的求助开始，对方在一个特定的编译环境下遇到了chaos项目编译失败的错误。问题根源直指GCC编译器对“模板模板参数”这一C++特性的实现存在版本差异。 文章没有停留在错误表面，而是深入到了编译器行为的层面进行分析。它清晰地指出了不同版本GCC（例如GCC 4.x与更新版本）在处理模板模板参数时，对于参数匹配的严格程度存在不一致，这是导致同一份代码在一处能编译通过、在另一处却报错的关键原因。 基于这个根因分析，作者给出了明确的解决方案：通过添加一个简单的适配性修改，即可让代码在不同编译器版本下都能顺利构建。整个排查过程逻辑清晰，从现象到本质，最终落实到一行可操作的修复上，对于遇到类似C++模板编译问题的开发者来说，具有直接的参考和借鉴意义。
linux时间相关结构体和函数整理
这篇讲的是Linux系统中处理时间的核心数据结构。作者系统性地梳理了`time_t`、`timeval`、`timespec`、`clock_t`以及`tm`结构体，明确指出了它们各自的设计目标与精度差异——从秒级的简单计数到纳秒级的高精度计时，再到便于人类阅读的分解表示。 文章不仅清晰地对比了`gettimeofday()`与`clock_gettime()`等函数的使用场景和性能特点，还特别点出了在跨平台编程或处理高精度定时任务时容易混淆的陷阱。例如，针对网络编程或性能分析场景，作者建议优先使用`clock_gettime()`配合`CLOCK_MONOTONIC`来获取不受系统时间调整影响的稳定计时。 对于需要将时间戳转换为日历格式或进行复杂时间运算的开发者，文中对`mktime()`和`localtime()`函数的使用注意事项也做了实用提示。整体来看，这是一份从理论到实践的清晰指南，能帮助你在不同项目需求下快速选择最合适的“时间工具”。
ERLANG OTP源码分析 – code_server
这篇讲的是Erlang OTP中code_server模块的源码分析，重点探讨代码升级的基本原理。作者从sys模块升级的话题出发，深入到code和code_server模块的工作机制。code_server是Erl
ERLANG OTP源码分析 – sys
这篇讲的是 Erlang OTP 中负责进程管理的基石模块——`sys` 的内部运作。作者直接从源码切入，剖析了它支撑两大核心功能（统计跟踪与热升级）的底层机制。 对于“跟踪”功能，文章揭示了 `sys` 如何巧妙地通过拦截目标进程的邮箱，插入控制消息（如 `get_statem_state`）来实现无侵入的状态查询，而非让进程自身实现复杂逻辑。而对更关键的“热升级”，则详细拆解了 `sys` 如何利用 `:sys.replace_code` 等回调，在进程执行间隙替换模块代码，并通过发送特殊字符消息来触发重载，保障了服务不中断。 文章的价值在于，它不止于说明“做什么”，更聚焦于“如何做到”。通过阅读这些实现细节——例如对消息队列的精妙操控与状态机的协作——读者能深刻理解 OTP 框架“让进程行为可管理”的设计哲学，这为在生产中进行更高级的监控与维护打下了坚实的基础。
Zen Cart 源码阅读笔记 （一）
这篇讲的是作者从Zen Cart电商系统的源代码入手，剖析其内部运作逻辑的故事。深夜里与代码相伴，他选择从这个开源项目的“心脏”开始探索。 文章以一种沉静而细致的笔触，带领读者走进Zen Cart的核心结构。作者没有停留在表面的功能介绍，而是直接切入代码层面，试图拆解这套老牌系统经年积累的架构设计。他可能重点观察了其经典的插件式模块系统如何实现扩展，或者探究了那套看似古旧但稳定的模板引擎背后的渲染逻辑。对于系统中一些历史遗留的设计模式或巧妙的代码组织方式，作者也给出了自己的解读和思考。 这种阅读方式，不仅仅是理解一套代码，更是在与一段电商系统的发展史对话。它揭示了一个成熟系统在平衡灵活性、性能与维护性时所做的权衡，对于正在设计类似系统或需要维护遗留代码的开发者而言，这些源于源码的洞察往往比任何抽象的架构理论都更具启发。
TCP/IP源码学习——inet_select_addr函数分析
这篇讲的是Linux内核里TCP/IP协议栈中一个看似不起眼却至关重要的函数——inet_select_addr。作者从源码层面，完整拆解了该函数如何为出站连接挑选源IP地址这一关键决策过程。 文章的核心在于揭示函数内部一套层次分明的选择逻辑。它并非简单取用，而是遵循严格的优先级：首先检查socket是否明确绑定了地址，接着查询路由表获取出口设备对应的地址，最后才考虑回环地址或全局默认地址。这种设计确保了在复杂的多网卡、多地址环境下，数据包总能带上最合适的“发件人”信息，为后续的路由和连接建立打下基础。 文中特别分析了实现的巧妙之处，比如它如何与路由子系统协同工作，以及不同版本（如IPv4与IPv6）内核代码中的差异处理。这种层层递进的决策树，体现了内核在网络配置灵活性与性能之间所做的精巧平衡。对于想深入理解网络栈源码细节、或需要诊断特定网络配置问题的开发者来说，这份对“如何做出正确选择”的源码级剖析，提供了非常清晰的脉络。
ERLANG OTP源码分析 – gen_fsm
这篇文章从一个有趣的视角切入，对比分析了Erlang/OTP中`gen_fsm`与更为人熟知的`gen_server`模块。作者没有停留在概念表面，而是直接深入源码，揭示了两者在实现层面的核心差异。 关键的突破口在于进程状态的管理。`gen_server`中，进程主要通过一个统一的状态数据（`StateData`）来记住上下文。而`gen_fsm`则在递归循环中引入了一个额外的原子型状态名称（`StateName`）。正是这个`StateName`，像一个路由开关，决定了下一次循环时具体调用哪个处理函数，从而实现了状态的流转与切换。 另一个精妙的对比在于消息驱动模式。`gen_server`通常遵循经典的“请求-响应”客户端/服务器模型，由外部调用者发送请求消息。然而`gen_fsm`的许多转换中，发送关键消息的往往是状态机自身——例如，在完成某个处理后主动通知另一个进程。这体现了它作为自主状态机的设计哲学。 归根结底，这篇文章拆解了`gen_fsm`作为“带名称的递归”这一核心实现思路。理解这一点，也就明白了为何它天生适合建模那些具有明确离散状态、并需要根据状态自主执行不同逻辑的流程。
ERLANG OTP源码分析 – supervisor
这篇讲的是 Erlang OTP 框架中核心的 supervisor 进程。作者深入其源码，剖析了这个“监督者”的本质：它其实就是一个基于 gen_server 实现的系统进程，专门负责监控子进程的退出状态，并按照预设策略进行重启管理。 文章从 supervisor 的初始化过程切入，揭示了它如何解析监督规范（Supervisor Specification），构建起一颗监督树。重点分析了它的重启策略——“one_for_one”、“one_for_all”和“rest_for_one”在源码层面是如何区分和实现的，让抽象的策略概念变得具体可感。 最巧妙的部分在于，作者拆解了 supervisor 处理子进程退出的内部逻辑。它并非简单粗暴地重启，而是通过状态机管理子进程的运行状态，并在子进程异常退出时，根据“强度”（intensity）和“周期”（period）两个参数来判断是否触发重启上限，从而决定自身是该重启子进程还是优雅退出，避免了系统陷入无限重启的死循环。 通过阅读这篇源码分析，能理解 OTP 框架构建高可靠性应用的一个基石：它把进程管理的复杂逻辑封装在一个优雅、可配置的监督者角色中，让开发者能专注于业务进程本身。