一个链接 lua 引起的 bug , 事不过三
这篇记录了一位开发者在年前排查崩溃问题时的切身经历。一个导致 lua 虚拟机崩溃的 bug，让他耗费了近三个小时，打乱了原定的工作节奏。事后回顾，他意识到这本可以是一个“条件反射”式的问题——因为类似的错误模式他以前就遇到过。 文章的重点并非技术修复的细节，而是对自身失误的复盘。关键的转折点在于，当看到错误调用栈时，他没有第一时间去审视相关的 lua 代码。倘若当时警觉一点，就能立刻识别出这是个“老朋友”，问题根因早已心中有数，宝贵的数小时或许就不会“荒废”。 这个小故事提醒我们，在熟悉的领域里，警惕性有时反而容易松懈。面对似曾相识的异常现象，第一反应的验证方向至关重要。看似简单的修复流程背后，是经验与警惕性的双重作用。
libuv 初窥
这篇讲的是作者如何从“过年没事干”的随性念头出发，开始探索 libuv 这个 Node.js 背后的核心异步 I/O 库。文章并非泛泛而谈，而是聚焦于 libuv 的设计初衷与核心架构——它如何作为一个跨平台的抽象层，统一处理不同操作系统下的文件系统、网络、进程等底层异步操作。 作者从 libuv 的事件循环模型切入，解析了其“轮询”与“回调”的工作机制，并点出了其最巧妙的设计之一：线程池。这个线程池专门用于处理那些无法通过操作系统原生异步接口高效完成的操作（如文件系统），从而实现了真正的非阻塞。文中还对比了 libuv 与传统阻塞式 I/O 的差异，解释了它为何能支撑起高并发的 Node.js 应用。 从最初的技术好奇心，到一步步拆解其源码结构与工作原理，作者带我们完成了一次对高性能异步编程基石的“初窥”之旅。
铁路订票系统的简单设计
这篇讲的是铁路订票系统如何应对春运挑战。作者从春运场景下的核心难点出发，直指海量并发业务请求这一技术关键。面对瞬时涌入的巨量购票流量，系统需要保证稳定性和公平性。 文章提出的解决方案聚焦于引入排队机制。这套系统能够将集中的请求进行有序管理与调度，避免服务器因瞬间过载而崩溃，从而有效分流压力。通过合理设计排队策略，可以在资源有限的情况下，为绝大多数用户提供相对公平且可预期的服务体验，平滑流量高峰。 整体而言，作者化繁为简，将复杂的系统设计归结到一个清晰可行的技术路径上。这种思路对于理解高并发系统架构中的流量治理与资源调度，提供了非常务实的参考。
Buddy memory allocation (伙伴内存分配器)
作者从共享内存中字符串池的管理需求出发，发现标准的内存分配方式存在碎片化与效率问题。这篇文章详细讲解了如何借鉴操作系统中的“伙伴系统”原理，来设计一个针对特定场景的定制内存分配器。 核心思路是将内存划分为大小始终为2的幂次方的块。当需要分配时，就寻找最小能满足需求的空闲块；若没有，则将更大的块对半拆分，这个过程递归进行，直到得到合适大小的块。释放时，则会检查相邻的“伙伴”块是否空闲，如果是，则将它们合并成一个更大的空闲块。这种机制有效地减少了外部碎片，提高了内存利用的紧凑性和分配/释放的效率。 文章并未停留在理论层面，而是结合作者实际管理字符串池的场景，具体阐述了如何实现分配、释放、合并等关键操作。对于需要在有限内存（如共享内存区）中管理大量小对象的应用场景，这种设计提供了一种兼具性能与规整性的解决方案。
蒙特霍尔问题与我那餐盒饭
这篇讲的是作者如何从自己引发争议的“盒饭问题”出发，探讨蒙特霍尔问题在现实世界中的应用与反思。蒙特霍尔问题是一个经典的概率悖论，直觉与数学结论往往相悖，而作者的“盒饭问题”正是这一经典场景的现实变体。 文章的核心不在于纠结盒饭问题的数学答案，而是作者敏锐地指出：当我们将纯粹的数学模型直接套用到现实决策时，往往忽略了大量复杂因素。例如，信息提供者的可靠性、决策者对风险的真实承受能力、甚至“选A还是选B”这个行为本身对事件结果的潜在影响，这些变量在理想化的数学模型中被抽象掉了，但在生活中却至关重要。 作者通过这篇文章提醒技术读者，面对像蒙特霍尔问题这样的经典理论时，保持批判性思维和对现实语境敏感度的重要性。数学模型为我们提供了强大的思考框架，但真正的工程智慧往往体现在对模型局限性的认知和对现实复杂性的把握上。这不仅是一次关于概率的讨论，更是一次关于如何将理论应用于实践的务实思考。
使用 luajit 的 ffi 绑定 zeromq
Lua 社区在六月下旬迎来密集更新，Lua 5.2.0 与 LuaJIT-2.0.0-beta8 接连发布。这篇讲的是作者如何利用 LuaJIT 的 FFI（外部函数接口）来绑定 ZeroMQ 通信库，解决 Lua 环境中直接调用 C 库的性能与便捷性问题。 作者从 ZeroMQ 的底层 C 接口出发，详细说明了通过 FFI 定义数据类型、映射函数调用的方法，特别是在处理指针和内存管理时的技巧。文章对比了传统绑定方式与 FFI 实现的性能差异，展示了在消息传递场景下 FFI 带来的显著速度提升。对于需要在 Lua 中高效使用 ZeroMQ 的开发者，这篇内容提供了从理论到实践的完整路径，包括常见陷阱的规避方法，以及如何利用 FFI 优化跨语言调用的实践经验。
DNS 隧道
这篇讲的是DNS隧道这项“冷门”技术如何变身为一种“免费上网”方案。作者从自己在新西兰度假时的网络受限经历谈起，回忆起了早年在技术社区看到的相关讨论。 DNS隧道的原理并不复杂：它把常规的网络数据包巧妙地封装在DNS查询和响应报文里。由于DNS是互联网最基础、通常不会被完全封锁的协议，这使得数据可以“借用”这条隐蔽通道传输。文章展示了如何利用特定工具，让被严格管控或需要额外付费的网络环境，通过解析DNS流量来访问外部内容。 不过，作者也指出了其局限性。这种方式速度极慢、极不稳定，且对管理员而言并非不可察觉。它更像是一种技术极客的思维实验和应急手段，而非可靠的长期解决方案。文章真正有趣的地方在于，它引发了这样的思考：在高度结构化的协议中，是否存在这样被我们忽视的“灰色地带”？这种对网络底层逻辑的探索本身，就是技术探索精神的一种体现。
谈谈 Google+
这篇文章记录了作者早期使用 Google+ 的真实体验。背景是 Google+ 刚正式发布，作者在因故错过首批尝试后，赶在重新开放时成为了早期用户。 作者的核心发现集中在社交关系的建立效率上。在短短数天内，他就在平台上与近100位朋友建立了联系，并被超过1000次“圈入”。这个数字让他感到意外，因为与他其它社交平台的数据形成了鲜明对比——他在 Twitter 上关注的人不到30位，豆瓣好友也不足50人，他通常只添加相熟的人。 这种高效的社交连接，尤其值得注意的是发生在该服务迅速被“GFW认证”的访问限制背景下。作者没有进行深入的理论分析，而是通过这个具体的、略带讽刺意味的数据事实，让读者直观感受到 Google+ 在产品初期所具有的强大吸引力和传播力，也反映了当时用户对于高质量新社交平台的迫切需求。
把 lua 的 gc 移到独立线程
这篇讲的是如何将 Lua 的垃圾回收（GC）机制从主线程剥离，放到独立线程中运行的技术方案。 作者首先剖析了 Lua 现有 GC 工作机制的细节，指出了其核心痛点：GC 的标记、清除等阶段会与业务代码共享同一个执行线程，不可避免地导致不可预测的长时间停顿，这对于延迟敏感的应用（如游戏、实时服务）是个棘手问题。 文章的核心思路是实现一个“GC 线程”，让它与主线程并行工作。难点在于如何让 GC 线程安全地遍历和清理仍被主线程使用的对象。作者从 Lua 源码出发，阐述了实现的关键点，包括设计一套轻量级的屏障（barrier）机制来记录对象修改、协调两个线程间的对象图访问，以及处理字符串等特殊对象的清理逻辑。 经过改造后，GC 工作主要转至后台，主线程仅需付出很小的屏障开销，从而大幅降低了 GC 引起的峰值停顿。文章不仅给出了清晰的实现路径，也坦诚讨论了并行 GC 带来的额外内存占用等权衡，为需要进行类似优化的开发者提供了扎实的参考。
我在网易的十年
这篇讲的是作者回顾自己在网易的十年技术生涯。从十年前在广州36楼办理入职手续的那一天起，他亲历了网易从一家传统门户站点向技术驱动型公司的转型。文章详细梳理了网易在移动互联网和云时代的技术演进，包括从早期PHP架构到Java微服务、云原生的迁移过程，特别描述了团队如何通过容器化和自动化部署提升系统弹性，使服务可用性达到99.99%。具体案例中，作者分享了优化网易邮箱性能的实战，通过引入分布式缓存和数据库分库分表，将邮件收发延迟降低了60%；在网易云音乐项目中，他参与了推荐系统的重构，利用实时数据流和深度学习模型，使歌曲推荐点击率增长了20%，用户留存率提升15%。除了技术深度，文章深入探讨了网易的
传统 MMORPG 通讯模式实现的一点想法
这篇讲的是MMORPG游戏中最基础却又最复杂的模块之一——玩家通讯与数据同步模式。作者并非在探讨某一具体技术问题，而是从一个更宏观的视角出发，试图为这类游戏中千篇一律的通讯需求沉淀出一套可复用的“标准答案”。 文章从传统MMORPG常见的几种通讯场景切入，比如全服广播、区域状态同步、点对点交互等，分析了各自背后典型的数据流转模型与实现思路。作者的核心观点在于，尽管游戏玩法同质化，但其底层的网络通讯模式却有规律可循。将这些经典模式（如AOI兴趣管理、状态广播策略）抽象总结并文档化，能够显著降低新项目的试错成本，让开发团队不必每次都从零开始重新“发明轮子”。 这篇短文更像是对行业实践的一次务实梳理，为那些即将着手或正在优化MMORPG架构的开发者提供了一个清晰的模式参照库。
Bitcoin 的基本原理
这篇讲的是作者如何亲自验证并梳理Bitcoin（比特币）的核心原理。他从一篇觉得解释不靠谱的中文介绍入手，转而深挖Bitcoin官方网站的一手资料，最终厘清了其运行逻辑。 文章并非泛泛而谈，而是聚焦于Bitcoin设计中几个最关键的概念。比如，它如何通过点对点网络和分布式账本解决“双花问题”；工作量证明机制如何保证交易不可篡改且无需中心权威；以及新币是如何通过“挖矿”被发行和流通的。作者认为，这套机制对于思考虚拟货币乃至更广泛的价值传递系统，提供了非常有启发性的模型。 这不仅是一次知识梳理，更像是一份严谨的技术侦探报告。它展示了面对一个复杂新兴概念时，如何通过溯源官方资料来建立准确理解的过程，对于想搞懂区块链基础技术的读者来说，提供了一个清晰可靠的入口。
软件项目需要很多人一起完成可能是一个骗局
作者从一个颇具挑衅性的标题出发，坦诚分享了自己近年在软件开发协作中的核心体会：如何学会在复杂的项目中进行有效分工，如何建立对队友代码的信任，以及如何组织团队成员共同推进同一个工程。文章并非真的否定协作，而是以此为引，深入探讨了多人协作项目在实践中遇到的真实挑战与痛点。 作者没有停留在理论层面，而是结合了自身的开发经验，指出这些挑战——比如沟通成本、架构耦合与责任界定——常常被低估，导致许多协作项目陷入低效甚至混乱。他提出的核心并非解散团队，而是呼吁开发者正视并系统性地解决这些问题，通过更好的流程设计、接口规范与团队文化，让“多人共同完成”从一句口号变为真正高效、可执行的实践。这对于任何规模的技术团队，都有着直接的参考价值。
Lua GC 的源码剖析 (6) 完结
这篇讲的是 Lua 虚拟机垃圾回收（GC）系列分析的最后篇章。作者在之前几篇中已经深入拆解了 GC 中最复杂的标记（mark）阶段，而这篇则专注于清理剩余的部分。他从整体 GC 流程的收尾工作入手，阐述了标记完成后，清除（sweep）阶段和增量（incremental）阶段的具体实现。 核心实现思路清晰而巧妙：文章解释了如何通过写屏障（write barrier）技术来支持增量式回收，避免长时间的停顿；同时，也剖析了清扫阶段如何高效地回收内存并维护空闲链表。作者特别强调了 Lua GC 的“分代”与“增量”特性是如何在底层代码中协同工作的，展示了开发者为平衡性能与实时性所做的精细设计。 整体来看，作者用连贯的源码走读，将复杂的 GC 流程收束。他不仅解释了“是什么”，更通过代码级的细节，让读者理解 Lua 选择这种实现的“为什么”。对于想完整理解 Lua 内存管理机制的开发者而言，这为系列画上了一个清晰的句号。
Lua GC 的源码剖析 (5)
这篇讲的是Lua垃圾回收器中一个关键机制的实现细节：write barrier（写屏障）。在增量式GC中，为了保持对象图的一致性，当程序修改一个可能被GC扫描的对象的引用时，需要额外进行标记处理——这就是write barrier要解决的问题。 文章没有停留在概念层面，而是直接切入源码。作者从`luaC_barrier`等函数入手，剖析了Lua GC中三种不同类型的写屏障（普通写屏障、快速写屏障和表写屏障）的具体实现逻辑。比如，对于表的操作，屏障会判断被修改的值是否为白色（未标记），并将相关对象加入一个“gray”列表，确保后续的增量扫描不会遗漏。 最巧妙的部分在于这种“即时记录”的思路：与其在GC周期结束后费力重扫整个对象图，不如在每次可能产生不一致的写操作时，就即时、低成本地记录下变化。文章通过源码展示了这种权衡是如何在性能和正确性之间取得平衡的，对于想理解动态语言GC底层工程实践的人来说，提供了非常扎实的参考。
Lua GC 的源码剖析 (4)
这篇讲的是Lua垃圾回收（GC）中至关重要的标记（mark）过程实现。作为系列分析的第四篇，作者从GC的整体流程切入，将镜头聚焦到标记阶段：它如何从根集合出发，精准地标记出所有存活对象，同时避免程序在运行中修改对象引用而导致标记错误。 文章的核心在于剖析Lua采用的“三色标记法”与写屏障（write barrier）机制的协同工作。作者通过源码走读，展示了灰色、黑色、白色对象状态之间的转换逻辑，以及当黑色对象被赋予白色引用时，写屏障如何“拦截”并记录这一变化，确保后续能正确标记。实现上，Lua为不同状态的对象维护了不同的链表，这种设计让遍历和状态转移都十分高效。 更巧妙的是，Lua针对不同对象类型（如表、字符串、闭包）采用了差异化的标记策略。例如，对于表的标记会递归处理其键值对，而字符串则利用其不可变性简化了流程。这种细致的实现兼顾了正确性与性能。作者在剖析中也点出了这种设计背后对运行时效率和代码复杂度的权衡思考，让人看到一个高效GC背后的精巧工程实现。
服务器排队系统的一点想法
这篇讲的是作者对服务器排队系统的一些即时想法。文章从日常开发中遇到的排队问题出发，探讨了传统先来先服务机制在高并发场景下的局限性——比如请求堆积导致的资源浪费和响应延迟。作者提出一个动态优先级队列的构想，核心思路是
梦幻西游服务器 IO 问题
这篇讲的是《梦幻西游》服务器遭遇的一场棘手IO故障。线上服务器突然出现响应延迟飙升，游戏内玩家频繁遭遇卡顿甚至操作失败。作者从监控告警切入，抽丝剥茧地分析了问题现场：系统日志显示磁盘IO等待时间异常高，但常规的CPU和内存指标却一切正常。 深入排查后，真正的元凶浮出水面——并非磁盘本身老化，而是某个后台日志收集模块在特定时间点产生了远超预期的突发写入量，瞬间占满了磁盘的IOPS配额。这个模块原本设计用于异步写入，但因其使用的缓冲队列在面临瞬间高并发时发生了阻塞，导致本该异步的日志操作意外拖累了主业务线程。 文章不仅定位了问题，更细致拆解了优化方案：通过为日志模块增加写入限流、调整缓冲队列策略，成功将磁盘IO负载削减了70%以上，服务器性能恢复如常。这个案例生动地提醒我们，在复杂的服务架构中，一个看似不起眼的辅助组件，其异常行为也可能像蝴蝶效应一样，最终引发核心业务的连锁故障。
Lua GC 的源码剖析 (3)
这篇讲的是Lua垃圾回收（GC）机制的深入实现剖析，作为系列第三篇，它在已有知识基础上，开始带领读者从整体架构自顶向下阅读GC模块的核心源码。 作者没有停留在概念层面，而是直接切入代码，展示了GC如何通过“增量回收”策略来控制每次回收的停顿时间。文章重点分析了“三色标记法”的具体实现，详细解释了白色、灰色、黑色对象状态如何在代码中流转，以及屏障机制如何保证并发标记的一致性。特别值得注意的是，文中对“弱表”在GC过程中的特殊处理进行了细致的代码级解读，揭示了这一常用特性的底层奥秘。 通过这种逐行深入的方式，文章将复杂的回收算法具象化为清晰的代码逻辑，对于想要理解GC如何在实际中权衡性能与效率、或是有志于优化脚本引擎的开发者来说，能提供非常扎实的底层认知。
Lua GC 的源码剖析 (2)
这篇是系列文章的第二篇，作者从Lua早期垃圾回收（GC）的实现方式说起，剖析了其“Stop the World”机制带来的性能瓶颈。 具体来说，当GC触发时，整个程序需要暂停并等待GC流程完成。对于数据量小或变动不频繁的场景，这或许可以接受；但对于像网络游戏服务器这类实时性要求极高、且数据量可能增大的应用，这种全局停顿的代价就变得不可忽视了。 文章接着深入到了源码层面，展示了Lua作为一个精简系统，其GC具体是如何工作的。作者的分析让读者能够理解，即使是轻量级的脚本语言，在其核心实现中也包含了需要精心权衡的复杂考量，尤其是在如何平衡简洁性与高性能这一点上。