共 37 篇相关文章
Skynet 随 Lua 5.5.0 正式发布完成了版本升级。Skynet 维护的定制版 Lua 核心特性是允许跨虚拟机共享函数原型，以此节省服务初始化时间和内存。实现此功能的关键难点在于正确处理短字符串内部化（interning）与外部导入原型中字符串的共存问题，该问题通过专门的补丁解决，副产品是支持了跨虚拟机共享只读常量表（可通过 skynet.sharetable 使用）。然而，鉴于 Lua 5.5 引入的 external strings 特性已大幅提升字节码加载速度，建议新项目避免依赖该补丁功能，以降低维护成本。 Lua 5.5 基本兼容 5.4，大多数 Skynet 项目无需大改，但升级后务必充分测试，并使用 `make cleanall` 强制重新编译 Lua。此次升级带来了多项有益改进：新增 `global` 关键字有助于减少拼写错误；分代垃圾回收（GC）改为步进式执行，解决了过去处理大内存服务时的停顿问题；新的不定长参数语法 `...args` 允许以表格形式访问参数，能简化部分代码实现。
soluna 默认静态链接 Lua 虚拟机，导致无法直接外挂动态链接的 C 扩展，因为动态链接会引入多份 Lua 实现，引发运行时错误。根源在于 Lua 中全局空对象的静态引用机制：多份实现会生成多个空对象，运行时比较时出现不一致。虽然 Lua 5.4 后将空对象移入运行期结构以缓解问题，但作者仍强调应避免多份实现。Windows 平台因 DLL 必须编译时绑定所有符号，问题尤为突出。 为解决此问题，soluna 采用新方案：外部 C 扩展库链接代理模块 extlua.c，该模块不依赖 Lua 内部实现，而是利用 lua_getextraspace 宏注入 Lua C APIs。外部库需定义 extlua_init 入口函数，在其中调用 luaapi_init 注入 APIs，再通过 luaL_newlib 注册模块函数。soluna 的加载器通过创建临时虚拟机、传递 APIs 引用并复制入口表来完成动态加载。这种方法同时兼容动态库
文章以教程形式探讨了在Lua中定义类型的简洁方法，重点介绍了从基础到进阶的实现策略。首先，作者展示了通过table和元表设置来创建类型的基本方式，这种方法依赖Lua模块机制，适合快速定义独立类型。随后，文章深入讨论了封装class模块的高级方案，通过统一管理类型定义和实例化，提供类型名查找功能，增强了代码组织性。内容核心转向
这篇文章从一个 MMO 服务器压力测试的优化场景切入，探讨了当使用 A* 算法在一个巨大的三维网格（10MB 内存）中寻路时，如何解决初始化开销过大的矛盾。 实现者为避免每次调用都 memset 清零，采用在格点中记录版本号的技巧，实现了“用到时再判断”的惰性逻辑，但这依然需要全局保留这块内存。作者从更高层面指出，这本质上是一个用平坦内存空间模拟稀疏矩阵的权衡问题。 为此，他设计了一套惰性初始化的内存结构：以 64 字节（cacheline 大小）为单位划分内存，仅用一个二级标记树（总开销约 20KB）来记录哪些段落已被初始化。访问时检查标记，按需清零。这样，绝大多数未被访问的内存区域永远不会被初始化，将时间开销降至接近于零，同时空间代价极小。 文章结尾更提出了一个巧妙的延伸思路：对于这种障碍物静态且局部的寻路，与其在运行时寻路，不如用巨大的预计算空间将路径全部存储下来，实现 O(1) 查询。这为解决此类特定问题提供了不同的架构视角。
这篇讲的是开发者在构建跨平台游戏引擎时，如何巧妙解决一个操作系统级的线程调度矛盾。作者从 iOS 的一个严苛限制出发：系统要求窗口消息循环必须运行在主线程，否则程序可能被杀；而引擎为了隔离耗时的业务逻辑，又必须把窗口管理模块与用户主逻辑分到不同线程。 矛盾在于，用户的业务代码期望运行在 Lua 解释器启动时的主虚拟机（VM）中，窗口模块期望在独立线程，同时窗口模块还必须占据操作系统意义上的“主线程”。作者最初认为这无解，除非像 Skynet 那样深度定制 Lua 运行时，让 VM 能自由迁移。 真正的转机来自一个巧妙的 API 设计：`thread.fork`。它通常让 func1 在当前 VM，func2 在新建 VM 和线程上并行。但作者反其道而行，让 func1（用户主逻辑）在**新线程**上运行，而让 func2（窗口模块的新 VM）继续留在**当前线程**（即操作系统主线程）上执行。由于两者都通过 `pcall` 被限制在各自作用域内，用户代码完全感知不到自身线程已切换，而窗口模块则恰好满足了系统对主线程的要求。 这个方案的巧妙之处在于，没有去硬撼操作系统的规则，而是通过“偷梁换柱”——交换两个执行流所在线程的位置，让看似不可调和的约束在架构层得到了圆满解决。
这篇文章探讨的是 Paradox 游戏引擎背后一套独特的数据文件格式。作者从游戏开发实践出发，比较了游戏行业常见的 CSV/Excel 表格模式与软件领域的 JSON/XML 模式，指出它们在处理复杂树状结构数据时各有局限。 有趣的是，Paradox 的格式初看像 JSON，但作者在使用 lpeg 编写解析器时有了顿悟：其核心是嵌套的列表结构，这本质上是 Lisp 的思想。这种格式语法简洁（仅用大括号和等号键值对），却拥有比 JSON 和 CSV 更强的表达能力，能优雅地定义游戏事件、触发条件等复杂逻辑，同时保持了策划人员编辑友好的可能性。 文章通过《群星》中一段具体的游戏事件代码作为实例，展示了这种格式如何清晰地组织条件判断、效果执行等游戏逻辑。作者最终得出结论：Lisp 模式在简洁性与表达力之间找到了一个更好的平衡点，为游戏数据的组织提供了一种优于传统方案的思路。
这篇文章探讨了在 Unity3D 中嵌入 Lua 时，如何设计一个既简洁又完备的跨虚拟机交互方案。作者指出，市面上已有的许多方案存在过度繁琐或细节不完备的问题，他从 C/S 架构的通讯模型出发，提出了核心思路：将 Mono 与 Lua 间的交互抽象为一次“异地函数调用”。 这个方案的核心精巧之处在于，它不直接暴露 Lua 的 C API，而是通过一个中间层的 struct 来传递所有数据。调用函数和参数被编码进这个 struct，统一由一个 C 函数传递给 Lua 虚拟机。这种设计极大地提高了模块的内聚性，并严格控制了 Mono 和 Lua 两套异常机制的边界，防止异常泄漏。 文章还深入剖析了方案中最具挑战性的部分：两个虚拟机间的对象循环引用管理。作者详细讨论了如何利用 Lua 的弱表（weak table）和 ephemeron table 来检测仅被外部虚拟机引用的对象，并最终解除循环引用。同时，他也务实地建议，在多数项目中，保持清晰的单边引用关系（Lua 长期持有 C# 对象，C# 短期持有 Lua 对象）是更简单有效的做法。 基于这套理念，作者在周末实现了一个名为 sharplua 的轻量级方案。它提供了极简的 API：一个创建 Lua 虚拟机，两个核心的 CallFunction 和 GetFunction 用于双向调用，以及一个 CollectGarbage 用于管理跨语言对象的内存。整个实现代码开源，结构清晰，为希望自定义嵌入方案的开发者提供了一个干净的基础模板。
这篇讲的是如何在 Lua 虚拟机中，为缓存模块设计一个安全的冷数据落地机制。作者从一个实际 bug 讨论出发，详细分析了不同方案的演进。 文章最初提出一个基于时间戳的朴素方案，但发现其无法保证业务正在使用数据时，数据不会被错误地异步写回。随后，作者引入 Lua 弱表和 `__gc` 元方法进行改进，利用垃圾回收机制来判断数据是否“冷”。然而，这个方案存在一个微妙的“第三状态”漏洞：当对象被 GC 回收、但其 `__gc` 方法尚未将其“复活”到待处理表时，系统会短暂地失去对该数据的追踪，导致可能从数据库加载出旧版本的数据。 为解决这个并发与状态管理的核心难题，文章最终提出了基于元表代理的方案。通过让 cache 表存储代理对象，将真正的数据隔离在另一个全局表中，从而稳定了数据从缓存中移除的时机，并使冷数据落地流程可以清晰地通过集合差集来识别目标，避免了复杂的状态竞争问题。这实质上是用间接层换取了状态管理的清晰与安全。
这篇讲的是在C/C++宿主程序中嵌入Lua时，最容易被忽视的陷阱：如何正确处理Lua的异常（error）机制。文章指出，很多开发者会忽略C API调用可能抛出异常这一点，导致程序出现未定义行为甚至直接崩溃。 作者从基础讲起，强调所有可能出错的API调用（如lua_tostring）都应被lua_pcall或lua_resume保护起来。文章用一个创建虚拟机的简单代码示例，清晰地展示了即使luaL_openlibs也可能因未捕获异常而带来风险，并推荐将核心逻辑封装为lua_CFunction再通过lua_pcall调用。 进阶部分深入讨论了在C++或多语言环境（如Unity的mono）中，Lua的异常机制（基于longjmp/throw）与宿主语言异常系统（如C++ RAII、.NET CLR）的协同难题。文章警告，直接用宿主语言的异常处理（如C++的try-catch）去捕获Lua API异常会破坏虚拟机状态，因此必须精心设计接口，将Lua与宿主视为两个通过消息通信的独立运行时，而非共享异常上下文。 最后，文章提到了在C扩展中初始化对象字段、管理栈空间等实用技巧，并附上了作者为解决跨语言交互问题而编写的示范代码。全文聚焦于“正确性”而非性能，对于任何需要深度集成Lua的开发者来说，这是一份避开关键坑点的实用指南。
这篇文章讲的是如何用Varnish、Nginx和Lua脚本搭建一个网站降级系统，核心目标是在数据库等后端服务出现致命故障（如500错误）时，能自动切换到展示缓存的静态页面，从而维持最基本的浏览功能。 作者首先明确了降级方案的三个关键点：只提供基础浏览、数据为非登录状态、支持手动与自动触发。整个系统的存储层由Varnish承担，利用其内存缓存来平衡性能与资源。为了保持缓存数据的时效性，作者设计了一个异步更新机制：通过crond定时任务分析Nginx的access日志，提取出热门请求URL，再主动向Varnish发起请求以刷新对应缓存，从而减轻了主站的压力。 降级的触发与切换逻辑主要通过Nginx结合Lua脚本来实现。在Nginx中，通过Lua脚本检查一个共享内存字典中的降级状态标志。一旦进入降级模式，所有PHP动态请求会被重定向，直接从Varnish获取数据返回给用户。自动降级功能则通过监控后端健康状态来实现，例如，当后端监控脚本返回500错误时，Varnish和Nginx都能自动感知并进入降级状态；恢复正常后，系统也会自动切换回来。管理员还可以通过特定的接口进行手动降级操作。 文章详细给出了从Varnish安装、Lua脚本部署到Nginx配置修改的完整步骤，并提供了相关的配置文件和脚本下载。对于需要保障高可用性的Web服务，这套结合了缓存、负载与动态逻辑切换的降级方案，提供了一个清晰且可落地的实践参考。
这篇讲的是 skynet 框架中一个经典设计决策：为什么它的 netpack 库坚持使用 2 字节（最大 64KB）来表示 TCP 数据包长度，而不是更“灵活”的 4 字节。 作者从游戏客户端网络通信的实际场景出发，解释了这并非简单的技术限制，而是一种有意的引导。核心原因在于，在单个 TCP 连接中允许过大的数据包（比如 100KB）是一个糟糕的设计。这会在弱网环境下长时间阻塞整个通信信道，连带心跳包等需要及时响应的小数据包也被延迟，严重影响实时性。更进一步，4 字节的长度头还存在被恶意攻击耗尽服务器内存的安全风险。 因此，作者主张正确的做法不是放宽包长度限制，而是在“长度+内容”协议之上增加一层，将大数据块分片传输。这个设计看似“绕”，但它强制开发者去思考和解决数据传输的阻塞问题，最终能实现单个 TCP 连接承载多个逻辑信道的能力，比如区分高优先级的心跳/关键指令和低优先级的聊天信息或大文件分片。 所以，skynet 这个看似限制性的选择，其实是在用简洁的接口引导使用者构建更健壮、响应更及时的网络架构。
这篇文章从作者封装Hive socket库时遇到的一个具体问题切入：如何处理底层`poll` API产生的事件。直接注入回调函数虽然直接，但容易引发异常、重入等不可控问题，且会加剧C/Lua边界的性能负担。 作者提出的方案是将事件及数据一次性返回给Lua层处理。为优化此方案可能带来的GC压力，他采用了一个预先传入的消息队列（一个空的Lua table）作为接收结构。在C层，通过高效的`rawseti`操作将消息逐条写入这个结构，并巧妙地利用一个缓存池来复用存储每条消息参数的小table，从而在系统稳定后避免了临时构建大型Lua表。 文章最后，作者还附上了一段极简的Lua消息队列实现代码，展示了其优雅的实现思路。整体而言，文章分享了一个从具体问题出发，在性能与可控性间权衡并最终优化实现的技术决策过程。
这篇讲的是作者团队遇到服务器内存一夜暴增8G的紧急情况，通过快速自制的Lua内存快照工具定位泄露的故事。 问题出在一张地图的Lua State中，有对象持续生成却未释放引用。作者懒得搜索现有工具，自己用半天时间写了一个名为“snapshot”的开源库。它的巧妙之处在于：不对整个Lua State序列化，而是只记录table、thread等复杂对象间的引用关系，并且用C直接调用API遍历，避免了用Lua实现时“观察即改变”的干扰。 核心方法是对比两个时间点的快照，新增的内存和其引用链一目了然。工具返回的虽然是一堆指针和字符串，但足够定位到具体是哪行代码的哪个变量导致了泄露，比如示例中清晰地指向了dump.lua第7行的tmp和S1变量。 这个临时工具已经成功帮他们快速锁定了故障点，展示了在紧急问题下“轮子虽小但能快速解决问题”的实用主义思路。
这篇讲的是知名游戏服务器框架Skynet的C版本从零构建过程。作者在一个月内完成了框架开发，期间对多个模块进行了反复重构，最终将代码精简至仅六千余行C代码与一千余行Lua代码。文章透露出作者对代码质量与可维护性的坚持：在紧凑的篇幅内保持清晰结构，以期后续Bug能够被快速定位与修正。这种对“小而精”设计目标的追求，展现了作者对底层框架工程化的深刻理解——用精炼的代码承载高并发的服务框架，本身就是一项充满挑战的设计实践。
这篇是“Lua元表源码分析”系列的第三篇，将视角从用户自定义表转向了Lua的基础——数字、字符串等基本类型是如何挂载并使用元表的。作者并没有停留在“数字也有元表”这个结论上，而是带着读者钻进源码，看Lua的实现者如何为这些内建类型维护和查找它们的元表。 文章的核心在于剖析`luaL_getmetafield`等关键函数的实现逻辑。最巧妙的一点在于，Lua并非为每个数字都存储一个元表，而是在`lua_State`或全局状态中，为数字、字符串等不同类型分别维护了一个共享的、静态的默认元表。源码分析揭示了当对数字调用方法时，虚拟机是如何一步步索引到这个全局默认元表，并执行其中定义的`__add`、`__index`等元方法的。这个设计既保证了功能的完整性，又极大地节省了内存。 通过这篇分析，读者不仅能理解“如何用”，更能看清Lua为了保持语言的一致性和性能，在底层做出的精巧权衡。它清晰地展示了，用户定义的元表机制与语言内建的元表机制，是如何在同一套引擎规则下协同工作的。
作者延续上篇对 Lua 元表 `__index` 的探讨，将镜头推进到 `__add` 这个算术事件上，带你从虚拟机核心 `luaV_execute` 出发，追踪元表调度的具体路径。文章不是简单地罗列用法，而是扎实地潜入底层，展示当代码执行到加法操作时，虚拟机如何一步步检查元方法、完成调度。 这种源码级的剖析让 Lua 的“表”与“元表”之间的魔法变得清晰可循。作者没有停留在概念，而是通过关键函数调用链的梳理，揭示了机制运作的实质。对于想理解语言设计精妙之处，或是需要深度调试的开发者来说，这提供了一份非常具体的实现地图。 读完你会对 Lua 如何优雅地扩展基本运算有更透彻的认识，而不只是停留在“它能这么做”的层面。
这篇讲的是Lua中元表（metatable）的使用与底层源码实现。作者从元表的核心机制出发，解释了它如何像C++的运算符重载一样，为表这类复合结构赋予自定义行为——例如，当对两个表执行加法时，Lua并非直接报错，而是会检查元表中是否存在名为`__add`的元方法（metamethod），如果找到就调用对应的函数来执行加法逻辑。 文章不仅停留在用法层面，还深入到了源码分析。它会带你看懂Lua虚拟机是如何一步步查找和调用元方法的，让你理解这套机制在内部是如何高效、优雅地实现的。对于想要真正掌握Lua“黑魔法”并看透其设计巧思的开发者来说，这是一个很好的切入点。
这篇讲的是如何利用Nginx与Lua的结合打造极致性能的Web架构。作者从“天下武功，唯快不破”的理念切入，指出Nginx擅长高并发事件驱动，Lua则以轻量和高效著称，两者在速度基因上高度契合。 文章重点分析了这种组合的技术优势：通过在Nginx的请求处理管线中嵌入Lua脚本（通常借助OpenResty等集成方案），可以在不牺牲性能的前提下实现高度灵活的动态逻辑，例如实时流量管理、自定义认证或动态内容生成。关键实现思路在于利用LuaJIT的即时编译能力和Nginx的非阻塞I/O模型，将传统需要应用层完成的工作下沉到代理层执行，从而大幅减少上下文切换和网络开销。 这种架构特别适合需要高吞吐、低延迟且逻辑多变的场景，如API网关、微服务前置路由或A/B测试平台。实际部署中，它能在万级QPS下保持稳定响应，为需要兼顾性能与可扩展性的系统提供了一个务实的解决方案。
这篇文章介绍了一个叫ymd的新脚本语言，其名字来源于“Year-Month-Day”的缩写，暗示了它与结构化数据处理的紧密关联。 与追求通用性或高性能的传统脚本语言不同，ymd的设计哲学非常明确：它专为“数据处理”这一特定任务而生。作者从现实开发中大量重复的数据清洗、转换和聚合任务出发，剖析了通用语言（如Python、JavaScript）在处理表格或JSON等结构化数据时，虽然功能强大，但语法和库函数往往显得笨重和冗余。ymd的目标就是提供一个更简洁、更贴合数据处理心智模型的环境。 文章详细展示了ymd的核心特点：它拥有一个极简的语法核心，提供了大量针对数据列操作的内置谓词和管道式语法。这意味着你可以像用SQL一样，通过一连串清晰的步骤来描述数据变换流程，例如“筛选-分组-聚合”，而无需编写繁琐的循环和临时变量。此外，ymd对大数据集的惰性求值和内存优化也有特别考量。对于需要快速处理日志、CSV或API返回的JSON数据，又不想引入重型框架的开发者而言，ymd提供了一种更轻量、更专注的选择。
这篇文章从游戏策划的实际工作痛点出发——策划人员需要在表格中直接编写Lua脚本代码，却强烈要求使用中文变量名。由于Lua原生语法并不支持中文标识符，最初团队采用了一套拼音转换的“变通方案”，虽然能运行但增加了额外处理步骤。 为彻底解决问题，作者团队深入了Lua的编译流程，核心思路是修改词法分析阶段，使其能够正确识别和处理中文字符作为合法的标识符部分。文章详细剖析了如何扩展Lua的词法分析器，包括字符编码处理、识别规则调整等具体实现细节，最终让Lua能够原生支持中文变量名，使得策划人员可以直接在脚本中书写和阅读中文逻辑，大大提升了脚本的可读性和策划人员的工作效率。 这种从实际业务需求出发，通过底层技术改造解决语言限制的思路，对于其他面临类似本地化或易用性挑战的工具链开发，具有直接的参考价值。
