Objective-C 运行时的黑魔法之Swizzle
这篇讲的是Objective-C运行时里一项既强大又颇具风险的特性：Swizzle（方法交换）。作者从一个实际需求切入——如何在不改动项目原有代码结构的前提下，为应用中成百上千个UIButton的点击事件统一添加统计逻辑。 文章清晰地揭示了Swizzle的原理：Objective-C在调用方法时，依赖类的“调度表”通过selector查找对应的实现。我们可以在运行时替换这个映射关系，从而“偷天换日”。相比于创建子类或逐处修改代码的传统思路，这无疑是一劳永逸的“黑魔法”。 其核心实现也十分巧妙：通过`method_exchangeImplementations`交换两个selector对应的方法指针。文中以一段Swift示例代码具体展示了如何为UIButton扩展一个计数方法，并与原方法交换实现。最有趣的一点是，在替换方法中调用“自身”时，看似会死循环，实则因为实现已被交换，调用的恰是原始逻辑。 最后，文章还提醒了在Swift中应用Swizzle的注意事项，例如需要利用`initialize`方法触发交换，以及对纯Swift类需要使用`dynamic`修饰以启用动态派发。这既是一次对运行时机制的精彩剖析，也提供了解决特定工程难题的优雅范本。
行为树及其实现
这篇讲的是作者如何将游戏AI中的行为树概念落地为一段具体的C代码实现。文章从游戏开发中传统状态机的扩展性难题切入，引出了行为树作为解决方案的背景。 作者梳理了行为树的核心结构：由负责逻辑判断的中间节点（如顺序、优先级）和执行动作的叶子节点构成，并通过“黑板”机制在节点间共享数据。重点在于其实现部分——作者对比了800行的C++实现，认为其封装偏深，因此用约400行C代码，以组合而非继承的方式完成了一个更轻量的版本，并解释了核心API如创建节点、分支与执行tick的设计。 文章还透露了行为树在工业实践中往往依赖可视化编辑器生成JSON描述，为后续扩展埋下了引子。整体而言，这是一次从理论到轻量级代码的实践记录。
Scala的模式匹配
这篇讲的是作者在从Java转向Scala学习过程中的一个核心发现：模式匹配。作者对比了自己学习Haskell和Scala的体验，指出Scala的模式匹配对有Java背景的开发者非常直观友好。 文章的核心在于对比。作者首先用Haskell的阶乘和字符串翻译为例，说明模式匹配本质上是一种强大的“变化点”控制机制，比传统if-else更清晰地处理多条件分支。接着，他将这一概念平移到Scala，展示了它不仅可以匹配值，还能匹配类型、拆解数据结构（如List）以及复杂的构造器组合。 更深入的对比在于设计范式。文章指出，传统的面向对象多态将行为内聚于类中，新增类型容易，但扩展接口（新增行为）则很麻烦。而模式匹配将核心逻辑抽离到函数中，使得新增一种数据类型（如一个新的树节点）需要修改所有匹配函数，但新增一种操作（如先序遍历）只需增加一个新函数。这清晰地揭示了两者在开闭原则应用上的不同侧重，帮助读者理解何时该选择哪种范式。 作者最后通过二叉树遍历的例子，具体展示了模式匹配如何优雅地处理递归和结构化解构，并给出了从Java转向Scala的实用学习路径建议。
建立动态规划状态转移方程的练习
这篇文章通过LeetCode上的八个经典题目，生动演示了如何攻克动态规划中最核心的一步：建立状态转移方程。作者从自身的复习笔记出发，挑选了Word Break、Unique Paths、Edit Distance等覆盖字符串、网格、树结构等多个领域的典型问题，逐一拆解其思考过程。 文章的核心观点是，解动态规划题的本质在于“状态识别”和“状态转移方程建立”这两步。像循环与递归的选择、空间换时间的优化，都只是实现技巧而非核心。例如，在解“三角形最小路径和”时，关键在于定义从底层向上积累的最短路径值f(i, k)，并建立f(i, k) = min(下一层相邻状态) + 当前值的递推关系。对于“交错字符串”问题，则需定义f(i, j)表示两个子串前缀能否形成目标前缀，并据此建立逻辑或的转移方程。 作者没有停留在给出公式，而是试图还原每道题背后的状态定义逻辑。这种从具体例子提炼通用思考方法的叙述，让抽象的“建立方程”变得可触摸。对于正在学习动态规划的人来说，跟随这八个问题的思路走一遍，能有效训练如何从问题描述中提取状态，并找到状态之间递推关系的“感觉”。
Linux下互斥量加锁与解锁操作的C代码实现
这篇讲的是在多线程编程中如何安全地保护共享资源。作者从一个常见问题出发：当多个线程需要修改同一全局变量时，必须确保操作的原子性，否则容易引发不可预知的错误。 文章核心是演示一套完整的互斥量加锁与解锁C语言实现。作者没有停留在理论，而是直接给出了可运行的代码文件“LockAndUnlock.c”。其中，自定义的`MutexLock`函数封装了`pthread_mutex_timedlock`，并通过`gettimeofday`获取系统时间，巧妙地计算出带超时（5秒）的绝对等待时间，避免了线程可能被永久阻塞的风险。`MutexUnLock`函数则简洁地封装了解锁操作。 代码结构清晰，包含了宏定义、函数声明和完整的错误处理逻辑。文章最后还附上了在Linux下的具体编译命令（gcc -pthread）和运行结果，形成了一个从问题、方案到验证的闭环。对于需要在C程序中使用POSIX线程互斥机制的开发者来说，这套封装好的函数可以直接作为参考或API使用。
在Linux进行IO的正确姿势
很多C/C++程序员在做网络编程时，习惯使用封装好的库，却可能忽略了底层IO操作的一个常见陷阱。这篇文章指出，许多人对read()/write()函数的错误处理并不到位。 作者从一个典型的错误代码示例出发：检查返回值为-1或0就认为完成了处理。但这忽略了关键的errno判断，尤其是EINTR（系统中断）和EAGAIN（非阻塞IO暂无数据）这两种情况。文章进一步展示了，仅仅判断errno还不够，正确的姿势是将IO操作放在一个while循环中，以便在发生可恢复的中断时进行重试，而非直接退出。 文中强调，一个完善的IO处理逻辑必须能应对操作系统的瞬时状况，并结合了select/epoll等IO多路复用机制。最后，文章建议读者参考sim框架的开源代码，学习成熟的IO处理模式。
对象到数字 ID 的映射
这篇讲的是如何用一个高效的数据结构，为对象分配并管理短生命周期的数字 ID。 在像 skynet 这样的并行系统中，直接使用 C 指针来标识服务对象是危险的，容易引发悬垂指针、误释放等问题。因此，通常会用数字 ID 来间接引用。作者提出了一个具体的需求：既要快速映射，又希望尽量不复用已释放的 ID（避免误用），这与操作系统常见的文件句柄复用策略不同。 为了满足这个需求，核心方案是设计一张专门的哈希表。每次分配新 ID 时，在上次值的基础上递增，并检查哈希表中对应位置是否冲突，若冲突则继续递增。这保证了 key 永不冲突，让查询速度最快，且实现相对简洁。 更进一步，作者将这部分实现从 skynet 中抽离出来，做成了一个独立的开源库。文章详细介绍了其提供的 5 个 API（创建、销毁、分配、抓取、释放），并重点说明了为实现线程安全而采用的读写锁策略：对表的修改加写锁，而对 ID 的抓取和释放操作则加读锁，允许并发。这份实现还适配了 Windows 的原子操作。 整体上，这是一个解决特定工程问题的精巧数据结构，其实现思路（如不复用 ID 的哈希策略、引用计数与读写锁结合）对需要管理对象生命周期的系统设计很有参考价值。
java中文乱码解决之道（八）—–解决URL中文乱码问题
你是否在Java开发中，被URL传递中文参数时出现的“问号”乱码困扰过？这篇文章专门拆解这个棘手问题。作者指出，相比于表单提交，URL编码因涉及浏览器、操作系统和字符集等多种因素，情况更为复杂。核心解决思路是**主动控制编码**，避免浏览器“自由发挥”。 文章主要提供了两种实战方案。一是通过JavaScript前端编码，使用 `encodeURI` 等方法在请求发出前就对中文进行标准化处理，文章还详细对比了一次转码和二次转码在Java后台的解码方式差异。二是在服务端使用Filter过滤器，无论是直接设置请求编码格式，还是在过滤器中自动完成反编码并重新封装请求，都能有效拦截和处理乱码。每种方案都附有具体代码和配置示例，可直接复用。 无论你是正在排查此类问题，还是想从源头建立规范，文中这些经过验证的方法，能帮你一劳永逸地搞定URL中文乱码。
java中文乱码解决之道（七）—–JSP页面编码过程
这篇讲的是JSP页面开发中那个让人头疼的中文乱码问题，尤其是根源常常藏在JSP转换为Servlet的编码过程里。作者直接拆解了关键指令页中的两个编码参数：`pageEncoding`（JSP文件本身的编码）和`contentType`的`charset`（发送给客户端的编码）。 文章核心梳理了转换过程的三次编码“变阵”：第一次JVM编译.jsp文件时，会依据`pageEncoding`或默认编码来读取源码；第二次生成.class文件时，所有内容都被统一转换成Unicode，之前的编码设置在此阶段无效；第三次业务处理后输出到浏览器，则由`contentType`的`charset`决定解码方式，否则会退回默认的ISO-8859-1。 所以，中文乱码的伏笔其实在这几个阶段的配合中早已埋下。搞清楚每个阶段谁说了算，才能在实际开发中精准配置，避免字符“南辕北辙”。
java中文乱码解决之道（六）—–javaWeb中的编码解码
这篇深入分析了Java Web开发中最令人头疼的中文乱码问题，尤其聚焦于服务器与客户端交互的编码/解码链条。作者从用户发起请求的四种方式（URL直接访问、链接、表单GET/POST）切入，详细拆解了浏览器在编码URL路径和查询字符串时的差异——例如IE与Chrome/Firefox在处理同一段中文时，一个采用GBK而其他采用UTF-8，揭示了乱码产生的首要根源。 文章的核心亮点在于源码级剖析。它追踪了Tomcat服务器接收请求后的解码流程，展示了`CoyoteAdapter`如何通过`connector.getURIEncoding()`获取`server.xml`中配置的编码集（如`UTF-8`）来解析URI，并默认使用`ISO-8859-1`处理未指定的字符。对于请求参数，则解析了`Request.parseParameters()`方法的调用时机与逻辑。这些底层实现解释了为何配置不当或浏览器行为不一致会导致乱码。 最终，文章将整个过程归纳为“页面编码->服务器解码->业务处理->编码响应->客户端解码”的闭环，并强调在服务器-客户端交互环节集中设置正确的编码是解决问题的关键。对于需要彻底理清Java Web中文乱码链条的开发者而言，这是一份从现象到原理的清晰指南。
java中文乱码解决之道（五）—–java是如何编码解码的
这篇文章深入到了Java虚拟机内部，剖析了字符编码解码的核心机制。作者从I/O操作和内存处理这两个乱码高发场景切入，详细拆解了Java如何处理字符与字节之间的转换。 文章指出了一个关键点：乱码的“元凶”往往是编解码使用的字符集不一致。例如，在按字节读取UTF-8编码的文件时，若未在构造String时明确指定编码，Java会使用平台默认的GBK去解码，结果自然就乱了。更巧妙的是，文章揭示了字符流（如InputStreamReader）本质上只是一个“桥梁”，其底层仍在进行字节读取，并依靠指定的字符集完成解码。 在内存操作部分，文章通过分析String.getBytes()与new String()的源码，展示了StringCoding.encode()和decode()方法的工作流程。特别指出了一个隐藏逻辑：如果没有指定编码，系统会先尝试平台默认编码，失败则回退到ISO-8859-1。理解这套内部流程，能帮你从根源上理解乱码问题。
排错经历：全局变量被多次析构
这篇讲的是一个C++服务程序在退出时崩溃的排查过程。作者团队发现服务每次正常退出都会触发core dump，堆栈显示崩溃发生在exit()函数析构全局变量时，提示“double free or corruption (fasttop)”，指向一个std::string全局变量。 排查过程相当硬核。由于服务器使用定制glibc，缺乏调试符号，作者只能在不完整的栈上“黑灯瞎火”地工作。核心难点在于，崩溃发生在main函数返回之后，且该std::string在exit中被析构数百次，难以直接定位。作者尝试在string的析构函数中打断点，却发现this指针已被编译器优化掉，常规条件断点也无法设置。 最终，作者绕到析构函数的底层实现（_M_dispose）下断点，并通过分析内存布局，找到了引用计数成员（_M_refcount）的偏移地址。他巧妙地设置了一个基于寄存器的条件断点（`if *((int*)$edi+4)!=-1`），成功捕获到了那个引用计数异常（为-2）的string对象。通过自定义的xxd命令打印内存，最终定位到了那个出问题的全局变量。整个过程展示了在调试信息匮乏的条件下，如何结合对内存结构和编译器行为的深刻理解，一步步从core dump反向追踪到问题根源的扎实技巧。
java中文乱码解决之道（四）—–java编码转换过程
这篇文章深入拆解了Java程序从编码到输出的完整数据流，帮你从根源上理解中文乱码的产生。作者从一个.java文件被编辑器保存开始讲起，系统默认编码（如GBK）决定了它的存储格式。接着，javac编译器会读取这个文件，将其转换为JVM内部统一的Unicode表示，并存入.class文件。 真正的复杂性发生在运行时。文章细致地对比了三种典型场景：在命令行Console运行时，输入输出都依赖于操作系统的`file.encoding`；在Servlet/JSP中，容器接收客户端数据默认使用ISO-8859-1编码解码，输出时也默认按此编码发送，这就为中文传输埋下了隐患；而通过JDBC操作数据库时，驱动默认也会用ISO-8859-1来转换Unicode数据。 通过拆解这一步步的编码“接力”，文章揭示了问题的核心：数据在不同环节流转时，如果使用的编码字符集不一致且未显式指定，乱码就必然发生。理解了这个从文件系统、编译器到运行时容器的全链路编码过程，你才能真正抓住解决Java中文乱码的“命门”，而不仅仅是记住几个转换代码的补丁。
java中文乱码解决之道（三）—–编码详情：伟大的创想—Unicode编码
中文乱码问题的根源往往在于不同编码体系的碰撞。这篇文章聚焦于编码史上的关键一步——Unicode编码的诞生与核心设计。作者从各国各自为政的编码方案导致的信息混乱讲起，解释了Unicode如何以“字符大容器”的理念，为全球每个字符赋予唯一二进制编码，从根本上为跨语言、跨平台文本处理铺平了道路。 文章并未止步于概念，而是深入剖析了Unicode的实现细节。它重点对比了UTF-8、UTF-16、UTF-32等主流转换格式，并着重讲解了当前最流行的UTF-8编码。通过汉字“严”的编码实例，清晰展示了Unicode码点到UTF-8变长字节序列的转换规则。此外，文中还探讨了字节序（大端/小端）问题及其标识方法，并借助Windows记事本中同一字符在不同编码（ANSI、Unicode、UTF-8）下的十六进制存储对比，直观地揭示了它们在实际存储中的差异。
java中文乱码解决之道（二）—–字符编码详解：基础知识 + ASCII + GB**
这篇讲的是字符编码的“地基”怎么打。作者从计算机如何存储文字这个最基本的问题出发，系统梳理了编码、字符、字符集这些核心概念，重点对比了为西欧语言设计的ASCII和为汉字设计的GB系列编码的根本差异。 ASCII用1个字节表示128个字符，完美覆盖英语字母和符号。但汉字数量庞大，ASCII的“小房子”根本住不下。于是中国的GB2312标准采用双字节编码，用“两个大于127的字节”组合出超过6000个常用汉字，还巧妙兼容了ASCII。随后GBK和GB18030不断扩展，GB18030更采用单字节、双字节、四字节混合编码，终于将少数民族文字等也纳入其中，成为国家强制标准。 文章清晰地展示了编码标准如何随着需求而演进，从ASCII的128个字符到GB18030的庞大字符集，核心就是解决“如何用有限的数字组合，表示世界上尽可能多的文字”。这种从基础出发的梳理，能帮你彻底理解中文乱码的历史根源。
java中文乱码解决之道（一）—–认识字符集
这篇讲的是Java开发中常见的中文乱码问题，但它并没有直接跳进解决方案，而是从更底层的字符编码原理出发。作者从计算机如何识别和存储文字讲起，解释了为什么不同编码体系（如ASCII、GB2312、GBK、Unicode）会共存，以及Java内部使用Unicode编码与外部环境交互时，编码转换步骤出错是产生乱码的根本原因。 文章对几种关键编码做了通俗的对比：ASCII用一个字节处理西欧字符；GBK和GB18030通过双字节或可变字节方案扩展了中文支持，解决了生僻字显示问题；而Unicode（特别是UTF-8）则以变长编码实现了跨语言、跨平台的统一标准。作者点明了UTF-8是当前互联网上最主流的Unicode实现方式。 作为系列开篇，本文的目标是先帮读者建立对字符集的清晰认识，为后续具体排查和解决乱码问题打下基础。内容虽然涉及不少编码细节，但讲解循序渐进，适合遇到此类问题想探本溯源的开发者。
一起空指针引发的程序问题的排查过程
这篇讲的是一个空指针引发的程序崩溃案例，作者从一次测试中的突发崩溃出发，详细还原了完整的排查过程。 问题现象是程序在某个功能函数中崩溃，初步日志显示崩溃发生在处理数据库超时异常的流程中。通过分析堆栈和参数，排查迅速聚焦到崩溃行的具体代码：一个指针变量 `pReq` 被用来访问结构体成员，但该指针本身可能有问题。 根源在于一个细节：在向数据库发送消息时，传入的 `para` 参数是空指针且长度为0。这导致在后续复用存储空间的 `DlgBuf` 中，对应的 `para` 字段未被赋值，依然是初始化时的空指针。当数据库无应答触发超时处理时，程序用同一个序列号去取这个空指针并试图解引用，自然就崩溃了。作者通过修改调用代码，传入有效的结构体指针进行验证，问题得以解决。 这个案例很典型，它揭示了在C语言中对指针“先检查、后使用”的必要性，尤其是在异常处理和超时等非主流程路径上。文章最后的总结经验——对重要指针务必校验非空，将其视为一种异常保护手段——对处理类似底层内存问题很有参考价值。
在回调和闭包中的内存泄漏
这篇讲的是事件编程中回调和闭包常见的内存泄漏陷阱。作者从自己遇到的实际问题出发，展示了 kraih 提供的一个经典案例：在闭包外声明的变量，被闭包内递归调用的子程序所引用，导致变量引用计数无法归零，内存就泄露了。 文章不仅指出了问题，还给出了具体的检测方法。比如使用 Devel::Cycle 模块可以直接找到循环引用，或者更简单粗暴地用压力测试（一个无限循环配合 ps 命令）观察内存占用（RSS）是否快速飙升。根因被归结为闭包无意中捕获了外部变量的引用。 对于修复，作者分享了两个经验：一是显式地将函数自身作为参数传递，避免它引用外部的同名变量；更推荐的方式则是将逻辑封装成类（例如用 Moo），让闭包通过 `$self` 来调用方法，这样既能清晰地管理状态，又能避免回调嵌套导致的复杂引用链。对于依赖 AnyEvent、Mojolicious 等框架进行异步编程的开发者，理解并避开这些坑至关重要。
PHP概率算法（适用于抽奖、随机广告）
这篇讲的是一个简洁高效的PHP概率算法实现，特别适合用于抽奖系统或随机广告位分配等场景。 文章的核心是一个名为 `get_rand` 的函数。它的巧妙之处在于通过逐步缩小概率范围来工作：给定一个概率数组，函数首先计算总概率值，然后从1到总值之间随机取数。如果随机数落在当前奖项的概率区间内，则返回该奖项；否则，从总值中减去该奖项的概率，并继续判断下一个。这个过程就像从一个箱子里依次摸奖，只要奖项设置好概率，算法总能准确“命中”一个结果，且时间复杂度为O(n)。 文章接着展示了如何将此算法应用到实际抽奖逻辑中。通过一个二维数组配置好各奖项及其对应的整数概率值（v值），总和越大，概率精度越高。后端通过循环提取概率值，调用算法获取中奖ID，然后将中奖结果与未中奖信息分别整理，最终以JSON格式返回给前端。整个实现清晰直接，代码量少，在数据量较大时也能保持出色的性能。
程序中的“多线程”
这篇讲的是程序设计中“多线程”的基础概念，作者从大家熟悉的“工厂流水线”比喻切入，清晰地区分了“单线程”与“多线程”的工作方式。单线程像严格的流水线，必须前一步完成后才能做下一步；而多线程则允许不同任务并行执行，互不阻塞。 文章用生成、上传、删除话单文件的实例，对比了两种模式的流程图。单线程是顺序的三步走，多线程则是三个线程同时运行，各自负责独立的功能。这种对比直观展示了多线程如何实现真正的并行处理。 作者接着总结了多线程在大型软件中的优势：让程序逻辑更清晰、易于阅读；通过并行执行提升效率；同时增强模块化，便于问题追踪。这些好处都源于其将大任务拆解为可独立运行的小流程的设计思想。 总的来说，这篇文章用通俗的比喻和具体的代码场景，阐明了多线程作为一种核心编程方法的价值——它不仅是技术实现，更是一种让软件变得更高效、更健壮的设计哲学。