emacs改变人生
这是一篇典型的个人观点与经验分享类文章。作者从自己从vim转向Emacs的经历出发，坦承标题“改变人生”带有夸张成分，但通过深入学习的过程，他重新诠释了“装逼”的正面内涵：即一种持续钻研、不安于现状的“折腾”精神。 作者详细描述了Emacs入门时面临的配置复杂、快捷键繁多等挑战，并以此引申出核心观点：在知识高度细分的现代社会，精深比泛学更重要。他认为，Emacs所代表的“折腾”过程——不断挖掘疑问、动手解决问题、打造个性化工作流——正是培养这种专精能力的体现。这种精神能带来持续的新鲜感，避免固步自封。 文章进一步将这种个人技能的学习，与理解世界运行的法则联系起来。作者以科技企业家多为程序员出身为例，指出通过编程（如同配置Emacs）制定规则的过程，也是构建个人认知系统、理解万物法则的方式。最终，文章以呼吁“不要放弃挣扎”收尾，将技术学习提升到了人生态度的层面。
linux内核研究笔记(一）内存管理 – page介绍
这篇讲的是 Linux 内核内存管理中最基础的数据结构——`struct page`。作者以一名服务器程序员的视角，从对“虚拟内存”的好奇出发，深入内核底层，剖析了物理内存管理的核心。 文章首先展示了 `page` 结构体的关键字段，并指出它是内核描述物理内存页的最小单元。核心在于，这片物理页在不同场景下被赋予不同角色：作为页缓存（`mapping` 域）加速文件IO，作为私有数据（`private` 域）用于缓冲或交换，或作为页表映射支撑用户空间的 `malloc`。 作者进一步通过宏定义，解释了页帧号（pfn）与 `page` 指针、物理地址、内核逻辑地址之间的转换机制。比如 `pfn_to_page` 本质上是操作全局数组 `mem_map`，巧妙地将连续的物理内存抽象为可索引的对象。文章还厘清了“内核逻辑地址”与“内核虚拟地址”的区别，并点明在 x86_32 架构下 `PAGE_OFFSET` 的由来。 理解 `page` 结构是窥探内核如何管理伙伴系统、slab分配器乃至整个虚拟内存系统的钥匙。这篇笔记从最底层的数据结构切入，为后续理解更复杂的内存管理机制打下了坚实基础。
做一个不喊爸不喊妈的程序员
作者从亲身经历的项目攻坚阶段出发，聊了聊程序员解决问题能力的几个层级。在无休止的加班、不合理的版本发布和各种“扯淡想法”的挤压下，他观察到面对BUG时，同事们的行为可以粗略分为四类：从最基础的“出现异常立刻汇报”，到“描述清晰文字”，再到“分析日志并推测”，直至最高阶的“尝试自己修复并验证”。他认为前两种本质上是在将问题转移给上级或同事，看似省力或“有益于项目”，实则会阻碍个人追踪能力与自信心的成长，并可能在团队中形成不良的依赖效应。 文章的核心观点并非强调技术细节，而是指向一种职业态度：倡导程序员在遇到问题时，首先应尽力独立分析与解决，而非习惯性“向上求助”。在当今强调工程效能与个人Owner意识的背景下，这种“不喊爸不喊妈”的独立解决问题的精神，或许是比单纯的技术积累更基础、也更关键的职业素养。
进程上下文切换 – 残酷的性能杀手（下）
这篇讲的是进程上下文切换如何成为性能杀手的实测篇。作者从自己开源的并发网络库chaos中选取task_service模块，通过编译宏控制，对比了pthread条件变量、sleep、pipe、socketpair、eventfd以及boost::io_service这几种线程间通信机制的实际表现。 测试数据清晰展示了不同机制的CS/s（每秒上下文切换次数）和整体耗时：pthread条件变量切换高达60万次且最慢，而eventfd的切换次数低至200次，效率遥遥领先。有趣的是，boost::io_service的CS也高达75万次，但整体效率却比pthread模型更好，作者推测这与其内部高效的队列实现有关。 结论很直接：上下文切换次数与程序运行效率基本呈反比，减少CS是优化后台服务性能时必须考量的关键因素。文章用硬核的实测数据说话，为开发者选择并发模型提供了切实参考。
总结一下遇到过的网络同步IO导致服务阻塞的问题
这篇讲的是作者在工作中亲身遭遇的两个因同步IO引发服务阻塞的典型问题。第一个场景是fri_svr服务需要向第三方平台（如人人、Facebook）批量拉取用户数据，由于整个HTTP请求/响应周期过长（1s-10s），当并发请求量升高时，按user_id哈希分配的专用线程队列会发生堆积，直接导致服务内存暴涨并无法及时响应前端。 第二个场景则发生在使用ICE同步RPC的数据服务上。作者发现，某个线程队列中只要有一个任务（对应某个用户的请求）被意外阻塞，后续同队列的所有任务都会被拖累，导致部分用户响应延迟几分钟。而哈希到其他队列的用户则不受影响。 为了解决问题，作者将线程模型从“一个线程对应一个队列”调整为传统的线程池（多线程对应一个队列），从而避免了单点阻塞的连锁反应。但核心挑战在于保证同一用户（拥有相同owner）任务的执行顺序。作者设计了一个线程安全的数据结构：内部维护任务队列和一个KV表来记录每个owner是否正在被处理。任务被取出时，会检查并锁定owner状态，从而确保后续任务不会被乱序执行。 作者最后也指出，这种方案会引入额外的check/set开销与线程竞争。如果任务都是执行时间可控的CPU密集型任务，那么最初的一对一线程队列模型可能仍是更优选择。
进程上下文切换 – 残酷的性能杀手（上）
这篇讲的是服务器性能优化中一个容易被忽视却影响巨大的维度——进程上下文切换。作者从实际观察出发，指出许多团队将优化精力集中在减少内存拷贝和IO次数上，这些固然重要，但上下文切换带来的开销与Cache Line同步问题，同样在无声地侵蚀着高性能服务器的效率。文章将这个话题拆解为上下两篇，本篇先聚焦于“上下文切换”这个核心。它像一个冷静的诊断者，提醒我们：当系统频繁地在不同进程或线程间切换时，CPU不仅要保存和恢复寄存器、程序计数器等现场，其宝贵的缓存也可能被频繁刷新，导致处理真实任务的时间被大量消耗。对于追求极致吞吐与低延迟的服务而言，这种“切换税”是必须正视并精细度量的关键成本。
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()`函数的使用注意事项也做了实用提示。整体来看，这是一份从理论到实践的清晰指南，能帮助你在不同项目需求下快速选择最合适的“时间工具”。
多核环境下cache line的测试
这篇讲的是作者从一个关于数组内部链表的内存池技术题目出发，对CPU cache，特别是cache line，进行的探索和测试。文章首先点明了这种数据结构的优势——通过保持地址连续来提升缓存命中率，非常直观。 作者指出，对程序员来说，CPU高速缓存本是一个透明部件，我们通常无法直接干预其操作。但正因了解其工作特点，我们可以通过特定的代码优化，让程序更好地利用它。 文章的核心价值在于，作者并未止步于理论。他深入到多核环境下，对cache line进行了实际的测试与分析。这为理解在复杂硬件场景下，数据如何影响缓存行为提供了第一手的观察。 通过这次从实际问题到硬件原理的挖掘，作者将抽象的缓存概念落地，展示了如何从日常编程细节中洞察底层性能的关键。