最新文章

采集自各技术站点的近期文章。

IT 安全/ 2015-01-14 13:42:39 / 累计浏览 3,433

C语言的整型溢出问题

这篇讲的是C语言中一个常被忽视但极其危险的安全陷阱：整型溢出。作者从“无符号整型溢出有定义（模运算），而有符号整型溢出是未定义行为”这个核心区别出发，拆解了问题的根源。文章的重点在于揭示溢出带来的真实危害，并用四个具体示例生动说明。例如，一个简单的`while`循环可能因`short`溢出而变成死循环；一次看似安全的内存拷贝检查，会因`int`到`size_t`的隐式类型转换而被绕过，导致缓冲区溢出。更严重的案例直接关联到OpenSSL的Heartbleed漏洞，展示了如何通过精心构造的输入，让`malloc`分配的内存远小于预期，从而引发远程代码执行。作者还特别提醒了编译器优化带来的“反直觉”行为：编译器在`-O2`等优化级别下，会假定有符号整型不会溢出，从而直接删除你手写的溢出检查代码。这意味着，那些在调试版本下有效的保护措施，可能在发布版本中完全失效，这使得问题更加隐蔽和致命。整篇文章就像一份简洁的安全编码警示录，它没有停留在理论定义，而是通过剖析编译器行为和真实漏洞，提醒开发者在处理整数时必须如履薄冰，尤其是在涉及内存操作和用户输入的场景中。

本机暂存

IT 前端/ 2015-01-14 13:38:23 / 累计浏览 1,294

函数式 CSS

这篇讲的是如何将函数式编程的核心思想——比如不可变性和组合性——应用到传统上“全局且可变”的CSS开发中。作者从Wealthfront工程团队的实践出发，指出CSS的全局作用域、样式易被覆盖和与DOM结构紧耦合等问题，会带来意想不到的样式冲突和维护噩梦。文章给出的核心方案是“函数式CSS”风格指南。其关键在于通过严格的命名约定为类名添加前缀，从而模拟出作用域，隔离样式；同时倡导使用组合（如同时应用多个类或Sass的@extend指令）来扩展样式，而不是重写已有的规则。这样既能避免副作用，又能提升样式的可复用性。作者通过对比修改前后的代码实例，展示了如何减少样式依赖、增强组件独立性。最终目标是让样式表变得更具伸缩性、更少“意外”，即使在大型项目中也能保持可维护性。对于任何受困于CSS全局混乱的前端团队，这套实践提供了清晰的约束思路和改进路径。

本机暂存

IT 设计/ 2015-01-14 13:35:54 / 累计浏览 2,368

函数要多小才够好——谈小函数之道

作者从“函数设计的本质是内聚”这一共识出发，深入探讨了一个常被忽视但至关重要的实践细节：函数到底应该写多长、多小才算好。文章指出，函数的“小”并非目的，而是其内聚性与可读性的外在表现。为此，作者提出了一个核心衡量标准：“代码最小处理单元”。他将一次赋值、一次比较乃至一次函数调用视为一个单元，并基于人脑认知负荷（不超过7个单位），建议单个函数内的最小处理单元也应控制在7个以内。这为“多小”提供了一个可操作的参考尺度。作者进一步分享了四个明确的拆分信号：函数过长无法一览无余、局部变量超过七个、缩进嵌套层级过多，以及最重要的——函数内部代码处于不同的抽象层次。他通过一个初始化函数的改造示例，清晰展示了如何将混杂的底层细节封装成更小的、抽象单一的函数。文章的点睛之笔在于，它定义了小函数的“下限”与“意义”。哪怕函数体只有一行代码，如经典的 `int max(a, b)`，其存在的价值在于通过函数名将具体逻辑抽象为意图清晰的“做什么”，在调用处极大地降低了阅读者的认知成本。文末，作者建议开发者多尝试编写10行以内的短小函数，逐步体会其带来的清晰与可维护性的“大威力”。

本机暂存

IT 前端/ 2015-01-14 13:34:33 / 累计浏览 2,770

css3文字阴影属性text-shadow

这篇技术文章聚焦于CSS3的text-shadow属性，系统讲解了其语法、参数及与box-shadow的异同。作者从回顾熟悉的box-shadow入手，详细拆解了text-shadow的每一个值：包括可选的颜色(color)、必需的水平与垂直偏移量(offset-x, offset-y)以及可选的模糊半径(blur-radius)，并特别说明了多个阴影叠加时的层级覆盖规则——与CSS类选择器不同，阴影列表遵循“先书写的在底层”的原则。文章清晰对比了两者的关键差异：text-shadow没有inset内阴影选项，但在处理半透明文本时，不会像box-shadow那样裁剪阴影形状。作者指出，两者共同的特点是都不影响文档布局。在应用层面，文章展示了如何利用不同颜色与偏移的阴影组合，创造出凹凸立体文字效果，甚至模拟表单按钮的点击状态变化，并附上了可供体验的在线Demo与效果截图。整体而言，文章通过具体参数解析与实用案例，帮助开发者掌握text-shadow的灵活用法，为页面文字增添视觉深度提供了明确的技术指引。

本机暂存

IT 数据库/ 2015-01-14 13:31:36 / 累计浏览 2,739

SSDB 源码分析 – 网络框架概述

这篇从SSDB重构后的模块化代码出发，聚焦其高度可复用的网络框架。作者首先指出SSDB网络协议虽简单且业务无关，能广泛应用于各类应用，但许多实现代码在解析报文时不够严谨，常误用`fgets()`等行级IO函数。随后，文章剖析了其多线程服务器框架的核心：通过`serve()`函数作为IO主线程管理连接与IO操作，并用`proc()`函数根据命令属性分发任务——或在主线程处理，或投入线程池。框架的巧妙之处在于，利用IO多路复用作为主循环，并通过名为`SelectableQueue`的结构，将线程间通信抽象为类似网络IO的逻辑，从而清晰高效地处理了主线程与工作者线程间的请求与响应传递。整个框架封装完善，几行代码即可构建并运行一个服务器。

本机暂存

IT 后端/ 2015-01-13 23:06:54 / 累计浏览 2,568

vfork 挂掉的一个问题

这篇讲的是 vfork 系统调用中一个经典的“坑”：为什么在子进程中使用 `return` 会导致程序崩溃，而用 `exit()` 却不会？作者从知乎上的一个实际提问出发，澄清了一些可能误导人的回答。文章首先梳理了 fork 与 vfork 的根本区别——fork 会复制父进程内存，而 vfork 则让父子进程共享同一内存空间。vfork 的设计初衷是为了在创建子进程后立即执行 exec 时提高效率。关键点在于，vfork 保证子进程先运行，直到它调用 `exit()` 或 `exec()` 后，父进程才继续。崩溃的根源正在于此：因为父子进程共享栈空间，如果在子进程的 main 函数中使用 `return`，它会像正常函数返回一样修改栈（弹栈、释放局部变量），这相当于破坏了父进程正在使用的栈。当父进程稍后恢复执行时，栈已被改写，导致不可预知的行为或直接崩溃。而 `exit()` 是直接终止进程，不会去操作和释放共享的函数栈，因此父进程能安全恢复。文章最后也指出，现代操作系统已通过“写时拷贝”技术大幅优化了 fork，使得 vfork 的性能优势不再明显，Linux 手册也不鼓励使用它，除非对性能有极致要求。理解这个底层机制，有助于我们避免这类隐蔽的陷阱。

本机暂存

IT 后端/ 2015-01-13 23:03:06 / 累计浏览 2,999

State Threads 回调终结者

这篇讲的是如何用 State Threads (ST) 这个仅3000行C代码的轻量级库，来终结高性能服务器开发中令人头疼的异步回调噩梦。作者从此前介绍的协程库 Protothreads 出发，引出了这个更适合服务器领域的“宝藏”项目。文章的核心在于将 ST 与传统的事件驱动状态机（EDSM）进行对比。传统 EDSM 依赖异步回调，开发者需要将线性的处理逻辑拆解成一堆回调函数，心智负担沉重。而 ST 的巧妙之处在于，它在 EDSM 的内核之上，为每个网络连接抽象出一个“线程”概念。这个线程并非操作系统线程，而是由 ST 自己在用户空间调度的轻量级执行体。 ST 的调度器通过模拟 setjmp/longjmp 来切换这些“线程”的上下文，整个过程没有系统调用开销。只有当所有“线程”都在等待 I/O 时，才会触发一次真正的 select()/poll() 系统调用。这样，开发者可以用接近写多线程同步代码的直观方式（线性思维）来编写高性能网络程序，同时又享受事件驱动模型带来的低开销与高可扩展性，避免了回调割裂逻辑的复杂性。文章还梳理了 ST 从网景、SGI 到 Yahoo! 的发展历史，并讨论了其 MPL/GPL 双许可证的兼容性细节。尽管这个库已稳定多年未再更新，但其“结合多线程编程简洁性与事件驱动性能”的设计思想，至今仍对理解服务器编程模型有重要启发。

本机暂存

IT 前端/ 2015-01-13 22:56:38 / 累计浏览 1,530

引入css外部样式表

这篇讲的是一个看似基础却让不少前端开发者栽跟头的问题——CSS外部样式表的引入与缓存。作者从在微信端调试样式，修改后却无法实时看到更新的实际踩坑经历出发，深入探讨了路径选择、缓存控制等关键细节。文章清晰地对比了相对路径与绝对路径在实际项目中的优劣，明确指出了项目上线时应优先使用绝对路径，以提升索引效率、有利于SEO和外链权重。更核心的部分聚焦于缓存问题，详细解释了浏览器（尤其是微信）缓存旧版CSS的机制，并通过分析淘宝和Facebook的实践案例，给出了具体的解决方案：为URL添加版本号参数（如 `?t=20150105`）或使用文件哈希值，可以有效强制浏览器更新资源。作者最终总结出几条实用建议：少用相对路径、多用绝对路径、WebApp引入CSS时最好带版本号、并合理利用缓存机制（如304状态码）。对于前端初学者或曾为样式更新不生效而困惑的开发者而言，这些基于真实场景的总结和对比，提供了非常直接的参考和避坑指南。

本机暂存

IT 前端/ 2015-01-12 22:55:35 / 累计浏览 2,061

css3中的几何图形shape研究

这篇技术文章深入探讨了CSS3中一个颇为强大但可能被忽视的属性：`shape-outside`。作者开门见山地指出，传统CSS布局中，浮动元素周围的文字总是沿着矩形框排列，而`shape-outside`正是为了突破这一限制，允许文字沿着圆形、椭圆、多边形等自定义几何轮廓进行环绕排布。文章清晰地梳理了该属性支持的四种基本形状函数：`inset()`（定义内凹区域）、`circle()`（定义圆形）、`ellipse()`（定义椭圆形）以及灵活性最高的`polygon()`（定义任意多边形）。通过具体的代码示例和效果对比图，详细解释了每个函数的参数含义，例如`circle()`中`closest-side`与`farthest-side`半径的区别，以及如何使用`polygon()`配合坐标点来创建复杂的五边形环绕效果。不过，作者也坦率地指出了这个属性的现实局限：它目前只能应用于设置了`float`属性的元素，并且浏览器兼容性并不理想。因此，文章认为其最典型的应用场景是处理浮动图片（如头像）与周围文字的排版，能让图文混排效果更生动。尽管实用性受限于兼容性，但文章最后强调，学习`shape-outside`有助于更深入地理解浮动模型和CSS布局逻辑。它展示了Web技术如何为设计师提供更精细的控制力，即便这项技术尚未全面普及，其背后的原理依然值得前端开发者了解。

本机暂存

IT 前端/ 2015-01-12 22:54:34 / 累计浏览 2,539

关于webapp中的文字单位的一些捣腾

这篇文章探讨的是移动WebApp开发中一个经典纠结：文字单位该用px、em、百分比还是rem？作者没有停留在理论争论，而是用实测对比给出了直观结论。作者从PC与移动端对文字尺寸需求的差异出发，分别在未设置viewport和设置了`width=device-width`的情况下，对这几种单位进行了实测。关键发现是：当正确设置了viewport使布局宽度等于设备宽度后，不同单位计算出的最终显示大小趋于一致，px、em和rem在视觉效果上已无本质区别。文章的核心价值在于澄清了一个常见误区，并提供了清晰的实践路径。它建议开发者可以优先遵循设计稿的px数值进行输出，后期根据实际设备再微调。同时，考虑到代码维护和未来兼容性，作者推荐使用px与rem作为首选单位，尤其强调了为html根元素设定基础字体大小的重要性。因此，这篇文章为前端工程师在移动端文字排版上提供了一份基于实测的决策参考，帮助大家跳出单位选择的“内耗”，将精力集中在更统一、可控的工程实践上。

本机暂存

IT 后端/ 2015-01-12 22:52:43 / 累计浏览 2,917

一次php进程诡异退出的排查过程

这篇文章讲述的是一个常驻PHP进程总在莫名退出时，如何一步步定位到信号干扰并解决的实战经验。作者在反垃圾平台的离线扫描部分遇到了一个“诡异”问题：一个用`while(1)`循环的PHP守护进程会不定期退出。最初怀疑是致命错误，但通过`register_shutdown_function`捕获后发现，该函数在进程退出时根本没有执行，日志一片空白。这提示退出可能并非源于PHP内部错误。根据官方文档注释，作者意识到当进程收到SIGTERM或SIGKILL等信号时，`register_shutdown_function`会被跳过。于是，他转而使用`pcntl_signal`为一系列常见信号（如SIGTERM, SIGHUP等）安装自定义处理函数，以记录是哪个信号导致了退出。最终，日志锁定了元凶——SIGALRM（alarm信号）。这只是一个无关紧要的定时器信号，但默认行为就是终止进程。解决方案很直接：在信号处理函数中，对SIGALRM进行特殊处理，直接忽略它，而对其他信号则记录后干净退出。这个案例展示了在Linux环境下排查PHP进程异常退出的典型思路：当高级的错误捕获机制失效时，问题根源很可能在更底层的操作系统信号层面。通过合理捕获并处理这些信号，就能有效“驯服”那些看似毫无征兆的进程退出问题。

本机暂存

IT 后端/ 2015-01-12 22:52:04 / 累计浏览 3,649

妙用php中的register_shutdown_function和fastcgi_finish_request

这篇讲的是 PHP 中两个常被混淆的“请求结束期”函数：`register_shutdown_function` 和 `fastcgi_finish_request`。虽然它们都在脚本执行尾声触发，但一个负责“善后”，一个用于“提前下班”。 `register_shutdown_function` 注册的函数，即使遇到 fatal error 或主动调用 `die()` 也会执行。文章展示了它的两个实用场景：一是作为“黑匣子”记录错误现场，比如精准捕获内存溢出的详细信息；二是用于监控请求是否异常中断，确保关键流程可追溯。 `fastcgi_finish_request` 则完全不同，它是一个“分水岭”。调用之后，所有输出都会发送给客户端，之后的代码（如日志记录、数据清理）虽然继续执行，但不再产生网页输出。文章用代码演示了如何用它来优化响应速度——把用户不需要看到的耗时操作，挪到“已响应”之后进行。文章通过具体的代码示例和输出对比，清晰地区分了两者：一个保障程序的健壮性与可观测性，另一个则专注于提升前端的响应体验。

本机暂存

IT 安全/ 2015-01-12 22:50:58 / 累计浏览 3,638

调试利器之tcpdump详解

讲的是网络排查必备的工具tcpdump。文章开篇点明其“dump traffic on a network”的本质——一个功能强大、可扩展的包分析工具，能深入到网络层、协议、端口进行过滤和抓取。安装部分是这篇文章的一个重点。作者详细拆解了三种途径：最省心的yum命令安装、稍麻烦但直接的rpm包安装，以及最繁琐但能获取最新源码的编译安装。对于源码编译，还贴心地提示了可能遇到的libpcap依赖问题及解决方法，比如需要先安装flex、bison和m4等，这对新手排坑很有帮助。工具的基本使用也是核心。文章列举了tcpdump纷繁复杂的命令行参数，并对其中常用的选项，如`-A`（ASCII码查看）、`-i`（指定接口）、`-w`（写入文件）等，配合具体命令示例解释了它们在不同场景下的用途。例如，用`-A`参数可以直观看到MySQL通信的SQL语句原文，用`-w`抓包后配合Wireshark分析则能解决更复杂的问题。整体来看，这篇文章从安装到实战，为初学者搭建了清晰的tcpdump入门路径，强调了它在网络诊断和安全分析中不可替代的作用。

本机暂存

IT 后端/ 2015-01-12 22:48:51 / 累计浏览 4,691

ip地址中的网络号，主机号

这篇文章讲的是IP地址的核心结构——网络号与主机号。作者开篇就用了一个很形象的比喻：如果说MAC地址是你唯一的身份证号，那IP地址就是你详细的通信地址。这个地址被分成两部分：“网络号”标识你所在的网络（好比哪个城市或街道），而“主机号”则标识该网络上的具体设备（好比门牌号）。这种层次化的设计，让互联网上的通信定位变得高效有序。文章的重点在于“如何计算”。作者以一个具体的IP地址（192.9.200.13）和子网掩码（255.255.255.0）为例，手把手演示了计算过程：先将两者转换为32位二进制，然后通过“按位与”运算得出网络号（192.9.200.0），再将掩码取反后与IP地址“按位与”得到主机号（13）。整个过程清晰展示了子网掩码的核心作用——就像一把尺子，精准地划分出IP地址中网络与主机的边界。此外，文章还补充了IP地址的五类分类法（A、B、C、D、E类）及其二进制特征，并解释了子网掩码的另一种简洁写法（如/24代表前24位为1）。这些知识点串联起来，能帮助读者不仅知道“是什么”，更理解“怎么算”以及“为什么这么设计”，是理解网络通信基础的一个扎实入门。

本机暂存

IT 算法/ 2015-01-12 22:48:16 / 累计浏览 2,033

為什麼我喜歡玩魔方？

这篇讲的是一个技术人如何通过玩魔方，观察到“万能感”这种迷人的心理机制。作者并非单纯分享魔方技巧，而是从自身业余爱好出发（平均还原时间40秒，最快26秒），将玩魔方时那种“搞定不听话事物”的愉悦，与编程入门时写出“Hello World”的成就感联系了起来。文章指出，这种通过自身意愿操控复杂系统的满足感，在苹果产品设计中体现为“一键直达”的简洁体验，在更广泛的领域则近乎一种“上帝模式”的诱惑。作者也冷静地提醒，这种“万能感”如同精神毒品，一旦遇到无法掌控的边界，便容易滋生挫败感与负面情绪。最终，他将这个小爱好上升到对“权力的诱惑”的思考，认为这或许是人类历史中无数争斗的缩影。

本机暂存

IT 后端/ 2015-01-11 23:55:23 / 累计浏览 2,409

怎样获取PHP函数默认参数常量名

这篇讲的是PHP中如何获取函数默认参数的常量名称。作者从实际编码场景切入，当函数定义中使用常量作为默认参数时，开发者可能需要在运行时获取这个常量名，但早期版本的PHP对此无能为力。关键对比在于PHP版本差异：在PHP 5.4.6之前，函数定义属于编译时信息，运行时反射API无法直接访问常量默认参数名。文章指出，直到PHP 5.4.6才通过反射扩展

本机暂存

IT 后端/ 2015-01-11 23:54:32 / 累计浏览 1,811

PHP中的NOP及为什么有这个opcode

这篇讲的是PHP虚拟机（Zend VM）中一个看似“无用”的指令：ZEND_NOP。作者从汇编语言中的空操作指令切入，解释了PHP作为高级语言为何还需要它——这源于编译器的优化策略，而非底层内存对齐的考虑。文章核心展示了PHP的“早期绑定”机制。在编译阶段，如果函数声明或类声明（如代码中的Bar类）能被确定，其对应的执行指令就会被直接替换为ZEND_NOP。通过VLD调试工具的输出对比，读者能清晰看到，处于条件语句内、编译时无法确定的Foo类仍需DECLARE_CLASS指令，而Bar类的声明已被优化掉。作者进一步探讨了为何不移除这些NOP指令。关键在于opcode数组的内存是预先按文件分配的，移除单个NOP并不能回收空间。对于Zend引擎而言，类和函数声明的数量相对于总指令数很少，为此修改引擎结构的收益有限。而像eAccelerator这类opcode缓存扩展，则会在编译优化阶段主动移除NOP以提升后续执行效率。整篇文章从一个具体指令出发，揭示了PHP编译优化与执行模型间的协作细节，帮助开发者理解那些“静默”发生的性能考量。

本机暂存

IT 后端/ 2015-01-11 23:51:00 / 累计浏览 2,885

从未降级的搜索技术-Hippo在线服务调度系统

这篇讲的是，在搜索团队经历了一次手忙脚乱的双11“搬机器”救援后，如何从零开始构建一个真正服务于在线系统的调度平台——Hippo。故事要从一次教训说起。当年双11，团队为天猫和主搜分别预留了14倍和1倍的资源余量。然而流量突变，主搜压力远超预期，天猫却只涨了4倍。工程师们被迫手动迁移机器来救场，改配置、发数据、起进程，折腾一个半小时才勉强应对。更无奈的是，这种紧急操作往往还未必能准确命中流量高峰。每年大促都像一场无法预演的战役，让运维和开发都身心俱疲。为了解决这些痛点——资源僵化、扩容迟缓、手动部署风险高，团队调研了当时主流的调度系统。但发现Yarn对于C++在线服务显得笨重，而FUXI和Mesos在资源回收上采用强制策略，可能影响在线服务的稳定性，这与搜索系统“高可用、资源分配稳定”的核心要求相悖。因此，他们决定自研一个专注在线服务的平台。 Hippo采用了两层架构：Master层负责核心的资源管理与调度，而具体的AM层则允许各应用定制自己的调度逻辑。它的设计核心在于保证在线服务的平稳运行：资源回收策略更为柔性，并针对海量数据（如40G索引、多GB模型）的快速分发和部署做了特别优化。这篇文章详细拆解了系统从需求诞生到架构落地的全过程，展示了一个为复杂在线场景量身定制的调度系统是如何思考的。

本机暂存

IT 后端/ 2015-01-11 23:49:09 / 累计浏览 2,622

聊聊多线程程序的load balance

这篇讲的是，如何在一个常见的“接收者-工作线程池”模型中，主动优化负载均衡以提升性能。作者从一个大家熟悉的设计出发：一个 receiver 线程接收请求，放入队列，通过条件变量唤醒任意一个 worker 处理。他敏锐地指出，完全依赖内核的调度和负载均衡可能带来问题。核心问题有两个：如果 worker 线程远多于 CPU 核心数，唤醒时几乎无法均匀分配到不同 CPU，导致某些核过载而某些核空闲，形成“伪并发”。其次，即使 worker 数量合理，内核的负载均衡也未必能确保将任务分配到不同的物理核心（避免争抢共享缓存和计算资源）。对此，作者提出了应用层的“微调”方案。一方面，将 worker 线程数控制在接近或略小于 CPU 核心数。另一方面，更关键的是，通过线程绑定（affinity）固定 worker 在特定 CPU 上，并设计一个分级的条件变量唤醒机制。这能确保新任务被优先分配给空闲或低负载物理核心上的 worker，从而主动实现更优的负载分布。文章通过精心设计的实验验证了结论。例如，将 worker 线程数从 240 降至 24 后，CPU 利用率从 2200% 提升至接近 2400%。启用绑定线程和分级唤醒后，处理 12 个并发任务时性能得到进一步提升。作者也发现，对于依赖内存缓存的任务（如 mmap 读文件），让 worker 集中在相邻 CPU 上反而可能提升性能，这体现了负载均衡策略需具体场景具体分析。作者通过细致的对比实验表明，这些在应用层主动进行的微调，有时能取得比等待内核调度更优的效果。

本机暂存

IT 安全/ 2015-01-11 23:48:18 / 累计浏览 3,458

bash代码注入的安全漏洞

这篇文章深入剖析了2014年被称为“Shellshock”的Bash代码注入漏洞。作者从继“心脏流血”后又一“毁灭级”安全事件切入，详细拆解了漏洞的检测方法与技术原理。核心在于Bash处理环境变量时，会错误地执行函数体定义之外的恶意代码——这个缺陷从Bash 1.14一直延续到4.3版本。文章不仅解释了CVE-2014-6271和随后被发现修复不彻底的CVE-2014-7169，更关键的是，作者澄清了“该漏洞影响有限”的误解。他指出，只要服务器端应用（如PHP调用系统shell命令）会衍生出Bash子进程，就可能在传递环境变量时被注入恶意指令，这意味着许多现代系统都存在风险。这不仅仅是对一个历史漏洞的技术复盘，更是对安全观念的提醒：看似底层的工具链漏洞，其冲击力可能远超想象，影响面覆盖了从Web服务到系统管理的广泛场景。

本机暂存