回忆Windows开发中的古老概念
这篇讲的是作者对早年Windows开发经历的回忆与反思。文章从那个技术概念刚兴起、信息尚不完善的时代切入——当时维基百科尚未诞生，许多计算机术语的定义模糊不清，而微软的技术动向则牵动着所有开发者的神经。作者回顾道，在那个年代，软件开发几乎等同于在Windows平台上耕耘，因为只有这样才能获得商业回报。 文章特别指出了微软战略上的一个关键转折：没有及时推出应用商店。作者认为这绝对是一个巨大的失策，因为这一缺失不仅改变了后来移动生态的格局，也间接映射出PC时代软件分发与盈利模式的局限。通过这段亲历的回忆，文章不仅呈现了早期技术圈的生态，更引发了对平台策略、技术文档普及以及开发者与巨头关系的持续思考。
空指针的解引用
这篇讲的是C语言中空指针解引用的一个反直觉现象——通常会导致程序崩溃的NULL指针访问，在某些特定情况下居然可以成功。 作者从C程序员最常遇到的“空指针访问异常”问题切入，但并未停留在常规的排查层面。文章通过几个具体的代码示例，揭示了在内存布局、编译器优化（如 `-fno-strict-aliasing`）以及特定系统内存映射等条件下，对地址 0（即 NULL）进行读写操作反而不会触发段错误。这些例子直观地说明了“空指针不可解引用”这一准则在实践中存在的灰色地带。 文章的核心价值在于，它并非鼓励滥用这一特性，而是引导读者深入理解指针、内存模型与底层硬件交互的复杂性。作者指出，这种“可解引用”的情况高度依赖于平台、编译器和运行时状态，具有不可移植性，因此在生产代码中必须严格避免。对于想夯实C语言功底、理解系统编程陷阱的开发者而言，这篇文章提供了一个从反例中学习规范的好视角。
有关面试
这篇讲的是作者作为技术面试官，在近期一系列高强度的招聘面试后，沉淀下来的第一手观察与思考。 他没有空谈理论，而是直接从面试现场的细节入手，探讨了几个关键问题：面试的本质究竟是“技术考核”还是“潜力探测”？作为面试官，如何避免陷入仅凭“手速”和“标准答案”来评判候选人的误区？在有限的时间里，是该深挖一个知识点来考察思维深度，还是广泛覆盖以评估知识广度？ 文章将面试形容为一场双向的信息对称博弈。作者特别指出了一个常见盲区：我们往往过度关注候选人“答对了什么”，却忽略了观察他“如何面对不知道的问题”以及“提问时展现了怎样的思考路径”。这些细节，往往比背诵八股文更能揭示一个人的技术素养和成长潜力。 对于正在准备技术面试的候选人，或是同样承担面试职责的技术人员，这篇文章提供了一个跳出常规题库的视角，去重新审视面试中那些容易被量化的标准所掩盖的、更重要的人的维度。
关于tcp-proxy的几个小问题
作者在本文中深入探讨了tcp-proxy在实际应用中遇到的几个典型小问题，这些经验源于作者的近期排查过程。文章首先提到了代理连接不稳定的故障，根因分析指向了TCP keepalive设置与后端服务超时不匹配，导致连接被意外终止；作者通过调整sysctl参数中的net.ipv4.tcp_keepalive_time和net.ipv4.tcp_keepalive_intvl值，并结合应用层心跳机制解决了这一问题。其次，针对代理转发时出现的随机
有关TCP Flag
这篇讲的是面试中关于TCP Flag的一个经典问题。面试者被要求介绍TCP flags时，特别提到了SYN和FIN在ACK确认时需要占用一个字节的数据，而其他标志如PSH、RST、URG等则不需要。面试者猜测是因为其他标志“不重要”，但这背后其实揭示了TCP协议设计的深层逻辑。 TCP协议中的标志位用于控制连接状态，每个标志都扮演特定角色。SYN用于建立连接时同步序列号，FIN用于释放连接，它们在ACK过程中必须占用数据字节，以确保可靠传输并避免确认丢失。相比之下，PSH（推动数据）、RST（重置连接）等标志通常不需要这种机制，因为它们的语义更多依赖即时处理而非额外的数据确认。关键差异在于：SYN和FIN直接影响连接的生命周期，需要更强的可靠性保障；而其他标志则更多是辅助性控制，对数据完整性的要求相对灵活。 文章从这个常见的面试场景出发，深入浅出
TCP SYN-Cookie背后的人和事 - 续
这篇讲的是TCP SYN-Cookie机制一次深入的“祛魅”与理解修正。作者坦言，在早前一篇相关文章中，自己认为SYN-Cookie完全不保存会话信息，而是用一个32位的Cookie作为替代。其推理依据是：若本机不保存任何秘密，攻击者就能伪造出合法的第三次ACK包，从而发起攻击。 然而，在深入代码和调试之后，作者发现了自己原先理解的局限。这篇文章正是围绕着这个认知的转变展开，探讨了在实际的工程实现中，SYN-Cookie机制为了确保安全性，究竟需要（并确实）维护哪些关键的秘密信息。作者的反思指出，仅仅停留在理论推导或文档描述层面，很容易对协议的具体实现产生偏差；只有结合源码剖析与实践验证，才能真正吃透一个技术的内核。 文中对秘密信息的讨论，直指SYN-Cookie抵御攻击的核心，揭示了教科书式原理与工业级实现之间那道需要亲手跨越的沟壑。
我对总线的理解和总结
这篇讲的是软件工程师如何通过理解硬件基础，特别是总线知识，来提升软件开发能力。作者从自身实践出发，强调了在日常编码工作之外，深入掌握总线这类硬件原理的重要性——它不仅能帮助写出更高效、更稳定的程序，还能让开发者对整个计算机系统的运作有更透彻的把握。文章系统总结了总线的核心概念，可能涵盖常见总线类型如 PCI、USB 和 SATA 等，并对比了它们的关键差异：比如传输速率、数据位宽以及各自适用的设备场景，例如高速存储或外围设备连接。通过这种梳理，作者为读者呈现了一个清晰的框架，用以区分不同总线技术的优劣和选型逻辑。最终，文章传递了一个实用的启发：在软件工程中融入硬件思维，能有效打破开发中的黑盒状态，助力更全面的系统设计和问题解决。
TCP/IP源码学习——inet_select_addr函数分析
这篇讲的是Linux内核里TCP/IP协议栈中一个看似不起眼却至关重要的函数——inet_select_addr。作者从源码层面，完整拆解了该函数如何为出站连接挑选源IP地址这一关键决策过程。 文章的核心在于揭示函数内部一套层次分明的选择逻辑。它并非简单取用，而是遵循严格的优先级：首先检查socket是否明确绑定了地址，接着查询路由表获取出口设备对应的地址，最后才考虑回环地址或全局默认地址。这种设计确保了在复杂的多网卡、多地址环境下，数据包总能带上最合适的“发件人”信息，为后续的路由和连接建立打下基础。 文中特别分析了实现的巧妙之处，比如它如何与路由子系统协同工作，以及不同版本（如IPv4与IPv6）内核代码中的差异处理。这种层层递进的决策树，体现了内核在网络配置灵活性与性能之间所做的精巧平衡。对于想深入理解网络栈源码细节、或需要诊断特定网络配置问题的开发者来说，这份对“如何做出正确选择”的源码级剖析，提供了非常清晰的脉络。
有关读写锁
这篇文章讲的是为什么在并发编程中需要引入读写锁。作者从最基本的互斥锁（Mutex）出发，指出在“读多写少”的场景下，互斥锁会让所有线程串行化，即使多个线程只是读取数据，也无法并行，这严重限制了程序的吞吐量和性能。 核心方案就是读写锁（Read-Write Lock）。文章清楚地解释了它的关键差异：将锁分为“读锁”和“写锁”。多个线程可以同时持有读锁，进行并发读取，实现了真正的读并行；而写锁则是独占的，一旦有线程想写入数据，它必须等待所有读锁和其他写锁被释放。这种设计巧妙地在保证数据一致性（通过写锁的独占性）的同时，最大化地提升了读操作的并发性能。 文章进一步对比了它们的适用场景。互斥锁适合写操作频繁，或者读写耗时都差不多的简单场景。而读写锁则明确针对读远多于写，且读操作耗时较长的应用，例如缓存系统、配置中心或任何读多写少的共享数据结构。理解这一点，就能在性能瓶颈出现时，知道该从哪里优化锁策略。
编写安全代码：小心使用浮点数
这篇讲的是浮点数在实际编码中潜藏的风险，以及如何写出更安全的代码。作者从浮点数的二进制表示原理出发，解释了为什么像0.1这样的简单小数在计算机里无法被精确存储，进而可能引发比较判断失效、累加误差扩大等隐蔽问题。文章重点对比了浮点数与整数（或高精度库）在财务计算等场景下的差异，指出在需要精确值的领域（如金额处理、循环计数）盲目使用浮点数是常见错误根源。同时，它也分析了浮点数在科学计算等可接受误差范围的场景下仍然适用，但必须理解其误差传播机制。作者最终给出了一系列实用建议：比如避免用==直接比较浮点数，改用范围判断；在关键业务中考虑使用定点数或Decimal类型；以及如何通过单元测试捕捉由浮点运算引发的边界问题。整篇文章将底层原理与编码实践紧密结合，为开发者提供了一份规避常见陷阱的清晰指南。
编写安全代码：再论整数类型转换
这篇文章围绕C99标准中的整数提升规则展开深入讨论。作者从之前博文的评论区一个具体问题出发，通过重新研读标准、与同行交流以及独立思考，最终澄清了对整数类型转换行为的理解。 整数提升是C语言中隐式类型转换的核心机制，尤其在表达式求值和运算符操作时容易引发意料之外的符号扩展或截断。文章结合标准条目和实际代码案例，剖析了诸如有符号与无符号混合运算、窄类型向宽类型提升时的符号位处理等关键场景的差异。例如，当int与unsigned int运算时，int会被转换为unsigned int，这可能导致负数被重新解释为极大正数，进而引发逻辑错误。 作者通过逐步拆解标准条款，揭示了这些转换在底层实现中的一致性及其在安全性上的潜在影响。最后，文章将这些技术细节与编写健壮代码的实践联系起来，强调了理解隐式转换规则对于预防整数溢出和漏洞的重要性。
锁是怎么实现的？
这篇讲的是锁在计算机底层的基本实现原理，作者从最基本的机制出发，梳理了实现锁的几种核心方式。 文章首先排除了应用层常见的各类复杂锁，聚焦于最底层的实现。它可能从原子操作说起，比如利用CPU的原子指令来保证单个操作的不可分割性，这是构建一切锁的基石。接着，会探讨更复杂的实现：比如自旋锁如何让线程在“忙等”中循环尝试获取锁，适用于极短临界区；而互斥锁或信号量则可能涉及内核态与用户态的切换，通过让线程挂起和唤醒来避免CPU空转，适用于可能耗时较长的场景。作者或许还会简要提及读写锁如何分离读写权限以优化并发性能。 这种从原理根源讲起的方式，帮助读者跳出了对“锁”这个抽象概念的模糊认知，理解了不同锁策略在性能、开销和适用场景上的根本权衡，为选择和设计正确的并发方案打下了基础。
有关Cache 2 - 基本结构
这篇讲的是《计算机体系结构量化方法》一书中关于Cache原理的部分章节。作者分享了阅读附录B后的感悟，认为书中将Cache比喻为“一种将小而快的存储器与大而慢的存储器结合使用的巧妙机制”这一描述非常精准。 文章从一个常见误区切入：我们往往笼统地说Cache能提升性能，但它具体是怎么提升的？书中一句话点明了关键：Cache对“时延”和“带宽”的改善是分离的。Cache通过提供靠近CPU的快速存储，极大地降低了数据访问的“时延”（第一个比特到达的时间）；而其通过预取和块传输的设计，又在一定程度上保证了后续数据传输的“带宽”。 作者特别欣赏这种化繁为简的论述方式。通过这个清晰的视角，Cache不再是一个模糊的“加速器”，而是一个在成本、容量与性能之间进行精细权衡与协同设计的系统核心部件。这种理解方式，能让工程师在架构设计和性能分析时，有更明确的思考方向。
C函数串接的几种手法
作者针对“如何将多个业务处理函数串行调用”这个C语言开发中的常见需求，介绍了几种实现函数串接的具体手法。文章并非泛泛而谈，而是直接切入实践，展示了通过函数指针数组、宏封装以及利用回调机制等不同思路来组织代码的方法。 对比的核心在于代码的灵活性与耦合度：使用函数指针数组可以在运行时动态决定调用序列，适用于流程可变的场景；而利用宏进行声明式封装，则能在编译期生成更紧凑、执行效率更高的串接代码，适合对性能要求较高的固定流程。文章还探讨了如何利用上下文结构体为这些串接的函数传递状态，这是实现复杂链式调用的关键。 作者通过对比不同方案的代码组织复杂度与运行开销，给出的选择思路是：对于快速原型或流程频繁变更的场景，灵活的函数指针方案更便捷；对于核心且稳定的处理管线，编译时确定的宏或内联方式通常性能更优。这种基于实际约束的权衡，能帮助读者在具体项目中做出更合理的设计选择。
时延和带宽的关系
这篇讲的是网络基础概念中的一个常见误区。作者坦诚，自己多年间曾一直认为“时延”和“带宽”是反比关系——时延低，带宽就高。但深入理解后发现，这完全是两个独立维度的指标。 文章的核心在于厘清这一对比：时延是数据包从源头到目的地所需的时间（单位通常是毫秒），它主要受限于物理距离、中间设备的处理速度等“传输路径”特性。而带宽是网络链路在单位时间内能传输的最大数据量（单位通常是Mbps/Gbps），它取决于线路的物理介质和协议设计，是“管道”的粗细。 关键差异在于，两者并无直接的制约关系。一条高带宽的跨洋光纤，因为距离遥远，其时延可能远高于一根低带宽的局域网网线。优化目标也不同：对实时交互（如视频会议、游戏）更关键的是低时延；而对大文件下载、流媒体高清视频，则更需要高带宽来提升吞吐量。 作者从个人认知纠偏出发，把这个容易混淆的知识点讲透了。这提醒我们，在做网络性能优化或方案选型时，必须分清瓶颈究竟是在“管道宽度”（带宽）还是“路径耗时”（时延），才能对症下药。
开源世界中的算法与数据结构 3 -- Linux IPv6 FIB表实现
这篇讲的是Linux IPv6 FIB（转发信息库）实现的演进。作者从IPv4 FIB的实现局限性出发，探讨了直接将其扩展到IPv6的可行性——如果照搬IPv4的哈希链表方案，最坏情况下需要进行128次哈希计算和链表遍历，效率堪忧。文章随后切入正题，展示了Linux内核2.6版本实际采用的解决方案：使用Patricia（基数）树来重构IPv6 FIB。这不仅是一次数据结构的替换，更体现了对IPv6巨大地址空间的工程适配，通过树形结构显著提升了查找效率与扩展性，让网络栈能更优雅地应对新一代协议的挑战。
开源世界中的算法与数据结构 3 -- Linux Kernel List 和GList
这篇讲的是 Linux 内核和 GLib 中两种经典链表实现的设计哲学与实践权衡。作者没有纠缠于基本的增删操作，而是从工程实现的底层逻辑出发，对比了它们的差异。 核心差异在于内存模型：Linux 内核链表是侵入式的，它不另立节点存储数据，而是将 `list_head` 结构体直接“嵌”到你的数据结构里，通过 `container_of` 宏从节点反推出宿主对象。这带来了极致的内存效率和访问速度，节点与宿主数据一体，缓存友好。但代价是链表节点不能脱离宿主数据独立存在。 相反，GLib 的 `GList` 是通用的、非侵入式的。每个节点都是独立的内存块，通过 `prev` 和 `next` 指针串联，节点里用一个 `gpointer data` 指向实际数据。这带来了灵活性——节点可以被多个链表共享，生命周期也容易管理。但每一次插入、删除或访问数据，都需要额外的指针解引用，在性能敏感的内核路径上可能无法接受。 文章正是通过这两种截然不同的设计，揭示了在“通用性/灵活性”与“高性能/低开销”之间做选择时的典型工程考量。读完能理解，为何没有完美的链表，只有最适合特定场景的实现。
开源世界中的算法与数据结构 2 -- Linux Skbuff实现
这篇讲的是Linux内核网络栈中至关重要的数据结构 `skbuff`（套接字缓冲区）。作者从2003年接触Linux协议栈的亲身经历谈起，那时参考资料匮乏，很多理解都是自己摸索的。 他提到了一本关键参考书——2008年出版的《TCP/IP Architecture, Design and Implementation in Linux》，书中第五章对 `skbuff` 的代码实现有非常详细的解析。不过，作者并非简单翻译这一章，而是希望基于这些关键代码片段，分享自己对其背后设计思想的理解。 摘要着重于源码分析类文章的核心：它探讨了 `skbuff` 这个管理网络数据包在内核中流转的核心结构是如何被设计和实现的。文章的价值在于，它不仅仅罗列代码，而是结合作者长期的实践经验和经典的参考书籍，去剖析 `skbuff` 这样一个关键数据结构的设计取舍与巧思。对于想深入理解Linux网络子系统工作原理的开发者而言，这是一个从资深工程师视角切入的深度解读。
开源世界中的算法与数据结构 1 -- Linux FIB实现
这篇讲的是作者对Linux 2.4版本中FIB（转发信息库）数据结构的回顾与剖析
做大的艺术 - 大型网站的架构设计
这篇讲的是大型网站架构设计中，如何从大到小演化的过程，强调了整合与运营才是真正的难点。 文章从网站架构的基本原则和开源软件说起，指出尽管许多文章内容相似，但实践中的挑战在于整合——需要自制工具或根据业务定制软件，以及运营——涉及数据中心建设、业务流程设计等多方面考量。作者将这一演化过程比作人的成长，形象地说明了从小规模到大规模的过渡并非单纯的软件堆砌，而是一个涉及技术、业务和运营的综合艺术。 核心观点在于，成功的架构设计不仅依赖于技术选型，更需要在实际运营中不断调整与优化。通过具体案例，文章揭示了运营层面的复杂性，比如如何平衡性能与成本，以及如何适应业务变化。结论是，网站的壮大是一个动态故事，充满了创新与挑战，这为读者提供了从实践角度思考架构问题的启发。