最新文章

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

IT 开发者/ 2013-07-26 13:23:24 / 累计浏览 6,202

加班与效率

这篇文章从微博上一篇关于“靠加班超越对手”的讨论切入，直指一个普遍存在的管理误区：当领导者无法衡量团队产出价值时，往往会把“工时”当作最简单粗暴的衡量标准。作者认为，将加班视为核心竞争力，是一种思维懒惰，本质上是用劳动密集型的“蛮力”去弥补知识密集型“创新”的匮乏。文章用了一个精辟的类比：产品发展不是短跑，而是登山，比的是策略、准备和步步为营，而非一时的速度。对于“效率”，文章给出了一个清晰的物理定义：效率 = 有用功 / 总功。提升效率并非单纯增加投入，而是要从“增加有用功”（砍掉低价值需求、聚焦核心痛点）和“降低总功”（减少重复劳动、提升人员能力）两方面同时着手。更关键的是，真正的整体效率源于对最终产品负责的共同使命，而非各自为政的局部优化。为了让这个原则更具操作性，文章介绍了亚马逊的“T-Shirt Size Estimation”方法：用XXXL、XXL等尺码分别量化需求的业务价值和开发成本，从而快速判断优先级——比如一个业务价值为XL但开发成本仅为S的需求，就值得立即推进。通篇在呼吁技术与管理者们回归理性，用更聪明的方式（思考与创新）去解决问题，而不是陷入用时间换产出的低效循环。

本机暂存

IT 开发者/ 2013-07-15 13:43:18 / 累计浏览 6,932

程序员最怕的事

这篇文章汇总了程序员社区里流传最广的五大恐惧，数据源自 Stack Overflow、Quora 等平台上相关帖子的投票结果。它并非严肃的技术探讨，而是一次有趣的技术人“心理体检”。排名从低到高，恐惧依次是：与不称职的上级或同事共事；被迫学习或使用自己讨厌的技术（比如有人“怕用 COBOL”）；不再热爱编程这份工作；失业风险（包括被外包、技术平台封闭甚至身体伤病）；而高居榜首、最普遍的恐惧是“做砸事情”——具体表现为害怕代码里的 Bug。从“周五晚上发现无法编译”到“担心 Bug 造成经济损失或物理伤害”，这种对交付质量的敬畏与焦虑，几乎伴随每一位开发者的日常。这篇文章的价值在于，它揭示了技术光环之下程序员真实的情感与压力。它可能让你会心一笑，找到共鸣；也可能提醒团队管理者，除了技术能力，程序员更需要一个健康的协作环境和工作热情。你的恐惧上榜了吗？

本机暂存

IT 后端/ 2013-07-15 13:27:12 / 累计浏览 2,520

文件操作函数在VFS层的实现

这是一篇源码分析/实现类的文章，深入内核代码，拆解了open、read、write和close这四个基础文件操作函数在VFS（虚拟文件系统）层的具体实现路径。文章开篇点明VFS作为统一接口的承上启下作用，随后逐一攻破。例如，对于open，它聚焦于do_sys_open函数，展示了如何从用户空间获取路径、分配文件描述符，到核心的do_filp_open如何查找/创建inode并构建file对象的完整过程。对于read和write，文章对比了它们近乎对称的实现结构：通过fget_light获取file对象，调用vfs_read/vfs_write执行操作，再更新文件偏移量。其中特别剖析了vfs_read如何根据file操作函数集（f_op）中是否存在自定义的read钩子来决定调用驱动层函数还是内核默认的同步读函数，清晰体现了VFS的灵活性与抽象层设计。最后，close的实现则强调了资源的清理与释放，如调用flush写回缓存、释放锁和file对象。整篇文章通过关键代码段的解析，清晰勾勒出一个系统调用从用户空间下发后，如何在内核VFS层被逐步拆解、调度，最终落地到具体文件系统操作的过程，巧妙之处在于VFS如何通过一套统一的数据结构（如file、inode、f_op函数指针集）和调度逻辑来屏蔽底层差异，为上层提供一致的体验。对于想理解Linux文件I/O内核实现的开发者而言，这篇代码级的走查非常直接且具参考价值。

本机暂存

IT 后端/ 2013-07-15 13:26:14 / 累计浏览 4,254

Linux下访问文件的基本模式

这篇讲的是Linux内核中几种常见的文件访问方式，作者从底层机制出发，对比了普通模式、同步模式、直接I/O、异步模式以及内存映射这五种模式的运作原理与核心差异。普通模式依赖页高速缓存，读阻塞、写缓存即返回，是默认的平衡选择。同步模式则通过置位O_SYNC标志，强制写操作直到数据落盘才返回，代价是更高的延迟，但确保了数据持久性。直接I/O（O_DIRECT）完全绕过页高速缓存，在用户空间与磁盘间直接传输，适合数据库等需要自主管理缓存的场景。异步模式通过aio系列系统调用实现非阻塞I/O，进程提交请求后可立即返回处理其他任务，提升了并发处理能力。内存映射则通过mmap将文件映射到进程地址空间，把文件操作转化为内存操作，简化了编程模型并可能提升大文件访问效率。文章清晰地拆解了每种模式下内核标志位的状态与数据流路径，帮助开发者理解不同I/O策略的适用场景——比如高性能存储系统可能倾向于直接I/O或异步模式，而追求开发简便性的应用则更适合内存映射。通过对比这些模式的适用场景和实现机制，文章为开发者提供了选择I/O策略的清晰指引。

本机暂存

IT DevOps/ 2013-07-15 13:25:03 / 累计浏览 6,669

Linux下CPU的利用率

这篇讲的是如何真正理解Linux系统下CPU时间的构成，从而看懂利用率背后的含义。文章从内核时间基础切入，解释了HZ（时钟中断频率）、tick（中断间隔）和jiffies（中断累计次数）这几个关键概念，为你打下理解的底子。核心部分是将CPU时间拆解得明明白白：它并非一个整体，而是由用户态（User time、Nice time）、内核态（System time、Hardirq time、Softirq time）以及等待（Waiting time）、空闲（Idle time）和虚拟机偷取（Steal time）时间共同组成。文章直接给出了计算公式，让你能一一对应`top`命令输出中那些让人困惑的`%us`、`%sy`、`%id`等百分比，原来它们分别代表了不同时间段的占用情况。作者最后指明，`top`、`iostat`、`vmstat`这些常用工具的数据源头都是`/proc/stat`文件，其中的时间单位就是tick。搞清楚这些组成，当看到系统卡顿时，你才能从高企的`%sy`判断是内核子系统瓶颈，还是从高`%wa`看出是I/O等待拖了后腿，让性能分析有据可依。

本机暂存

IT 算法/ 2013-07-15 13:23:33 / 累计浏览 2,252

CFS中的虚拟运行时间

这篇讲的是Linux内核CFS调度器中最核心也最容易让人困惑的一个概念：虚拟运行时间（vruntime）。作者从对vruntime的不理解出发，在研究cgroup的CPU子系统时，才真正理清了它的原理。 CFS追求的是理想中的“完全公平”，但现实中同一时刻一个CPU核心只能跑一个进程。因此，算法需要一种机制来惩罚当前占用CPU的进程，从而照顾那些等待的进程。这个机制，就是vruntime。简单说，vruntime越小的进程，越值得被调度。它的精妙之处在于计算方式：vruntime并非进程实际运行的时间，而是结合了进程“权重”后的换算值。权重越大（对应用户态优先级nice值越低），进程实际运行一毫秒所产生的vruntime就越小，这样它在调度队列中的位置就越靠前（内核用一棵红黑树管理，vruntime小的在左端），从而获得更多的CPU时间。文章还揭示了内核是如何将用户熟悉的nice值映射到内部权重的，那就是通过一个叫`prio_to_weight`的静态数组进行转换。这套机制将“优先级”这个概念，巧妙地转化为“需要运行的紧迫度”，从而在动态调度中实现了对不同重要性进程的公平分配。

本机暂存

IT 算法/ 2013-07-15 13:18:51 / 累计浏览 2,499

如何通过数据来指导产品进行优化

这篇讲的是如何用数据驱动产品优化，以登录体验的实战为例。文章先点出登录成功率是衡量体验的核心指标，通过数据分析发现，密码、账户名和校验码出错是导致登录失败的三大原因。作者没有停留在表面，而是深挖“校验码为什么出错”，定位到“识别度低”这个根本问题。优化方案很有层次感，围绕校验码提出了“事前、事中、事后”的解决思路。比如“事前”通过技术提前识别真人，直接减少不必要的校验码出现；“事中”则降低易混淆字符（如0和O）的出现概率，并增加输入即时反馈；“事后”为输错的用户强化刷新指引和语音备选。这些具体手段都带来了可衡量的成功率提升。最后，文章总结出一套通用方法：先确定可量化的体验指标，再通过数据精准定位问题症结，最后通过迭代优化并用数据验证效果。整个过程强调用数据说话，而非主观臆断，对产品经理和设计师都有直接的参考价值。

本机暂存

IT 后端/ 2013-07-15 13:16:40 / 累计浏览 6,646

大数据下的工行

这篇讲的是工行2013年那场著名的系统故障，作者从一条已消失的微博切入，还原了事件的全过程。故障发生在计划内数据库升级（DB2从V9升至V10）后的首个业务高峰，暴露出凌晨低负载测试无法完全模拟真实压力的问题。文章的核心技术分析指出，问题可能源于IBM软件的内存清理缺陷，导致数据库主机CPU和内存迅速耗尽。作者站在DBA视角，还原了故障当时的决策困境：是冒险切换至未经充分验证的灾备中心（可能牺牲数据一致性），还是耗时更长但能保证数据完整地回退版本？理性选择了后者，这符合金融系统对CPA中一致性（C）的严格要求。文中还穿插了作者亲历的2008年淘宝机房断电惊魂时刻，形成对比——成熟的容灾架构需通过定期实战演习来锻造，而非仅靠昂贵备库。最后，文章对工行将直接原因归咎于IBM软件缺陷的内部通报，留下了耐人寻味的评论。全文通过一个具体故障，探讨了大型系统运维中测试验证、灾备切换与故障复盘的真实逻辑。

本机暂存

IT 后端/ 2013-07-15 13:14:05 / 累计浏览 3,014

解决进程间共享内存，由于某个进程异常退出导致死锁问题

这篇讲的是在进程间共享内存编程中，因某个进程异常退出而导致死锁的经典坑。作者从一个线上服务重启后的超时问题出发，层层排查，最终定位到根源：一个读进程在持有读写锁时突然崩溃，导致锁的计数器（`nr_readers`）没有递减，写进程因此永远等不到锁，共享内存数据无法更新，最终引发服务故障。作者不仅用测试代码复现了这一问题，更深入探讨了如何解决。读写锁在这种场景下缺乏自动恢复机制。一个巧妙的出路是改用互斥锁，并设置其`PTHREAD_MUTEX_ROBUST_NP`属性（Robust锁）。当持锁进程死亡时，锁不会永久阻塞，而是返回`EOWNERDEAD`，后续线程调用`pthread_mutex_consistent_np`即可修复锁状态，使其恢复正常。此外，作者还提醒，通过共享内存交换数据时，务必增加完成标记，以确保数据在进程崩溃时不会处于不完整的中间状态。文章从实际故障切入，完整呈现了“发现问题-分析根因-测试验证-寻求方案”的解决链条，特别是对Robust锁的应用，为处理跨进程的异常状态恢复提供了非常实用的思路。

本机暂存

IT 算法/ 2013-07-15 13:03:13 / 累计浏览 4,105

二叉树迭代器算法

这篇文章探讨了如何为二叉树设计迭代器，从而将遍历算法与具体数据结构解耦，实现如通用求和函数这样的抽象操作。作者指出，直接转换递归遍历行不通，因为其依赖编译器管理的隐式调用栈。核心思路是通过显式栈结构来手动控制遍历流程。文章详细展示了如何基于栈实现一个非递归的中序遍历，并将其封装为包含`next()`方法的迭代器。关键设计在于，迭代器的状态完全由栈的内容决定，每次调用`next()`对应一次栈操作。作者还澄清了一个常见误区：尽管单次`next()`调用可能涉及多次栈操作，但由于每个节点在整个迭代过程中仅入栈和出栈一次，因此总时间复杂度仍是线性的O(n)，与递归遍历一致。最后，文章简要对比了在支持`yield`语义的语言（如Python）中，一种更直观的生成器实现方式，并提示读者思考其背后的变换原理。

本机暂存

IT 后端/ 2013-07-15 13:02:02 / 累计浏览 3,907

JVM的GC简介和实例

这篇文章从JVM内存布局讲起，重点剖析了Java堆的分代模型——新生代如何划分Eden与Survivor区，以及Minor GC触发时基于复制算法的运作机制。作者通过一段简单代码和jstat监控，演示了在默认配置下，新对象如何优先在Eden区分配，当Eden空间不足时如何触发一次Minor GC，以及部分存活对象如何被直接晋升到老年代。整个过程配合真实的GC日志进行了拆解。文章还简要介绍了Serial、ParNew、CMS等常见的垃圾收集器，并利用JVM参数（如-Xmn、-XX:SurvivorRatio）调整新生代配置，为后续对比不同收集器的行为埋下伏笔。它并非泛泛而谈理论，而是将“对象优先在Eden分配”、“大对象直接进入老年代”等原则，用可观察的内存变化和日志数据做了印证。对于想理解GC基本行为，或对“Minor GC后对象为何直接进入老年代”感到困惑的初学者，这份实战记录提供了清晰的图示和数据支撑。

本机暂存

IT 安全/ 2013-07-10 13:55:53 / 累计浏览 4,478

QR二维码的攻击方法与防御

这篇来自“黑客讲坛”的文章深入剖析了QR二维码背后的安全隐患。作者blackeagle从二维码的结构原理切入，详细解读了其寻景图案、校准图案等组成部分，并指出其设计上依赖纠错码容错的特性。文章的核心价值在于揭示了一种具体的篡改攻击方法：攻击者可以通过对比原始QR码与目标恶意码的模块差异，用笔精准涂改少数白色模块，利用QR码自身的纠错能力，就能将扫码结果“劫持”到另一个URL地址。在此基础上，文章进一步归纳了网络钓鱼、恶意软件传播、个人隐私泄露（如火车票二维码信息被识别）等实际攻击场景。这篇文章不仅科普了二维码的技术细节，更重要的是揭开了日常便捷工具的安全风险一角，让读者认识到每次扫码背后可能存在的“陷阱”，对提升公众和开发者对二维码安全的重视很有启发。

本机暂存

IT 后端/ 2013-07-10 13:47:02 / 累计浏览 3,807

数据的存储介质-磁盘的RAID

这篇讲的是如何通过RAID技术将多块磁盘组织起来，从而突破单盘性能与安全性的限制。作者从计算机存储的两个基本要素——通信管道与存储介质出发，引出RAID的核心思想：通过数据分区（Partition）提升吞吐量与IOPS，通过数据复制（Replication）保障安全。文章清晰地对比了几种经典RAID模式。RAID0纯粹追求并行读写的速度，但毫无冗余；RAID1采用全盘镜像，安全但空间代价高昂。RAID5用XOR校验位巧妙地在安全与空间利用率间取得平衡。而现实中更常用的RAID10（1+0）与理论上更优的RAID01，文章通过图示和坏盘场景分析，点明了为何“先冗余后分区”的RAID10才是工程首选。更深入一层，文章探讨了实现RAID的两种形态：依赖RAID卡、电池与SSD保障日志的单机方案，以及通过光纤通道、InfiniBand等协议连接的外部盘柜。最后，作者将视角延伸至分布式存储，指出HDFS、GFS等系统本质上借鉴了RAID10的思路，并点明了在上层已做复制切分时，底层再用传统RAID可能带来的冗余与性能损耗。

本机暂存

IT 后端/ 2013-07-10 13:45:23 / 累计浏览 2,568

数据的存储介质-磁盘的硬件特性

这篇讲的是磁盘硬件的核心工作原理，作者从硬件决定软件性能的根本逻辑出发，带我们看懂这个既熟悉又陌生的“老古董”。他从磁盘的老祖宗——磁带机讲起，清晰解释了硬盘为实现“随机访问”而做出的关键设计：让磁介质盘片匀速旋转，由轻量化的磁头臂负责寻道移动，而不是反过来。文章还深入了一个常被忽视但至关重要的细节：磁盘块的原子写入。它解释了磁盘如何保证在异常断电情况下数据不“写一半”，即通过开机时的检查与清理来维持逻辑一致性。这种“最大努力保证原子性”的思路，是理解单机存储一致性的基础。对于容易混淆的IOPS（每秒读写操作数）和吞吐量（MB/秒），作者用“飞机运旅客”的生动比喻做了拆解。IOPS看重减少寻道和旋转延迟，适合数据库等小数据随机访问场景；吞吐量则擅长顺序大文件写入，比如视频存储。两者与延迟存在动态权衡关系。整篇文章用通俗的语言和比喻，把磁盘的机械特性、数据组织方式以及性能指标的内在关联讲得明明白白。对于想优化存储性能或理解上层软件（如数据库、文件系统）行为的工程师来说，这是打下坚实基础的必要一课。

本机暂存

IT 安全/ 2013-07-10 13:43:42 / 累计浏览 2,434

玩转robots协议

这篇讲的是互联网上一个看似基础却引发过巨头战争的协议——Robots协议。作者从2012年百度与奇虎360之间那场著名的“爬虫纠纷”与亿元索赔案切入，生动地引出了这个“君子协定”的重要性。文章的核心在于阐明，Robots协议并非技术强制规范，而是网站与搜索引擎爬虫之间的一种行业默契。它通过一个简单的`robots.txt`文件，让网站管理员能够表达自己的意愿：是欢迎所有爬虫，还是只对特定爬虫关闭某些路径。文章用淘宝（完全禁止百度爬虫）和京东（屏蔽特定路径及一淘爬虫）的真实案例做了对比，清晰地展示了不同网站会根据自身商业策略和需求来制定抓取规则。在讲解具体用法时，文章区分了“基本玩法”和“高阶玩法”。基础部分详细解释了`User-agent`和`Disallow`两大指令，如何屏蔽整个站点、特定目录或文件。而进阶部分则巧妙解决了“如何屏蔽a1-a100目录却单独允许a50”这类实际问题，引入了`Allow`指令的使用逻辑——“谁管得细就听谁的”，并指出了谷歌等搜索引擎对高级指令支持度更好的现状。整个讲解由浅入深，将技术细节融入到了实际场景的考量之中。

本机暂存

IT 后端/ 2013-07-08 22:53:02 / 累计浏览 3,100

kmemcache源码浅析

这篇讲的是memcache的Linux内核移植版kmemcache的源码实现。作者深入分析了这个不走寻常路的高性能缓存项目，重点剖析了它如何摒弃了常见的epoll通知机制，转而利用网络数据包 skb 的回调函数，实现了更细粒度的 packet 级调度。文章的核心在于揭示kmemcache独特的网络模型设计：一个dispatcher（调度器）与多个worker（工作线程）协同工作。其中dispatcher专门负责处理TCP和Unix域套接字，并将新建的连接分配给特定的worker；而所有的UDP请求也由这些worker直接处理。在实现细节上，文章拆解了用户态守护进程umemcached与内核模块kmemcache.ko之间，如何通过Netlink机制完成启动参数传递等关键交互。作者结合具体的代码结构（如cn_entry、cn_queue），清晰地展示了“请求-应答”的同步通信流程，以及其中涉及的序列号管理和回调处理等巧妙设计。整体来看，这是一篇扎实的内核级源码剖析，它不仅解释了kmemcache“做了什么”，更细致地拆解了它是“怎么做到的”，对于想理解Linux内核网络子系统优化或高性能缓存实现的读者来说，提供了非常具体的参考。

本机暂存

IT AI/ 2013-07-08 22:51:41 / 累计浏览 4,308

浅析十三种常用的数据挖掘的技术

这篇讲的是数据挖掘领域里十三种核心的技术方法，作者没有停留在抽象概念，而是系统地梳理了从统计、关联规则到神经网络、模糊集等每种技术的底层逻辑。比如，统计技术的核心是先假设一个概率模型再进行挖掘；而关联规则旨在发现变量间隐藏的规律性，其生成的规则带有可信度。文章特别适合想快速建立技术全景图的读者。它清晰区分了各类技术的特点：决策树用于展示条件规则；神经网络通过输入层、隐含层和输出层的复杂连接来建模；粗糙集处理不精确的数据分类；差别分析则专注于发现异常模式。这些技术并非孤立存在，它们共同支撑起从分类预测、聚类分析到异常检测等数据挖掘的核心任务。对于技术实践者而言，这篇文章的价值在于将众多方法置于统一框架下进行说明，帮助读者理解每种技术解决哪类问题、其基本假设是什么。结尾也点明了数据挖掘作为一门交叉学科，融合了机器学习、统计学、数据库等多个领域的精华，其发展最终旨在将海量数据转化为可用知识。

本机暂存

IT 后端/ 2013-07-08 22:49:01 / 累计浏览 2,544

scribe的生产实践总结

作者结合两年生产实践，分享了对Facebook开源日志系统Scribe的应用总结。Scribe以精简稳定著称，作者团队在线上运行超过两年，未曾遭遇其自身进程崩溃。文章核心聚焦于生产环境中Scribe的关键运维实践。针对Master节点宕机，标准配置是Primary接Secondary文件，故障时日志本地缓存，恢复后自动补发，并可通过一行脚本监控积压。为防止Scribe进程意外阻塞业务，建议采用异步线程写日志。而最棘手的情况是网络拥塞导致日志追送困难，作者提到一项压缩传输的改造尝试。文章最后将Scribe与LinkedIn开源的Kafka进行对比：Scribe如同“激流勇进”的冲锋舟，简单可靠；Kafka则似“航空母舰”，以集群和去中心化设计，对单点故障的容忍度更高。作者认为，对于中心化的日志收集场景，两者各有适用之处。

本机暂存

IT 开发者/ 2013-07-08 22:48:09 / 累计浏览 4,321

论“重复造轮子”

这篇文章从一个常见的技术讨论入手，探讨了“重复造轮子”这一现象。作者指出，它看似是个人偏好或技术问题，实则普遍存在于个人、团队甚至公司层面，往往导致资源浪费。文章深入剖析了其出现的几个核心原因：程序员之间相互轻视，觉得不如自己写的顺手；因版权协议限制而不得不自研；以及部门间因进度紧张、沟通不畅而放弃代码复用。作者还提到了一种“战略级”的造轮子，并以自己前公司的实践（如自研类似Hadoop的系统）为例，分析了其与拥抱开源路线在业务发展上的不同结果。作者的核心观点是，重复造轮子在大多数情况下并不值得，除非是为了有意义的创新或受限于客观条件。他特别对创业公司提出务实建议：应尽可能采用开源技术，将有限的精力聚焦于业务本身，避免陷入研发底层框架的“奢侈”消耗中。文章通过具体案例和经验，为技术决策提供了清晰的参考视角。

本机暂存

IT 后端/ 2013-07-08 22:45:40 / 累计浏览 2,778

剖析网页字符集的设置顺序

这篇讲的是作者从一次电商网站数据迁移中遇到的顽固乱码问题出发，深入排查并最终厘清了网页字符集设置的优先级顺序。问题根源在于，影响浏览器字符集解读的因素不止一个，而开发者往往不清楚它们之间的覆盖关系。作者通过实际测试，逐一验证了五种设置方式：文件编码、Apache2默认配置、PHP.ini配置、PHP脚本中的header函数以及HTML的meta标签。他设计了一个清晰的对比实验，例如同时设置header为gb2312、meta为utf8，观察显示结果，从而确定了基本的优先级。最关键的发现在于，当服务器端的PHP.ini或Apache配置介入后，情况会变得更复杂。测试表明，php.ini中的默认字符集设置优先级最高，它会覆盖header函数的输出；而Apache2的默认设置优先级则高于meta标签，但低于header函数。最终，文章得出了一个非常实用的优先级排序：php.ini默认设置 > header函数设置 > Apache2默认设置 > meta标签设置。搞清楚这个顺序，对于彻底解决因字符集配置冲突导致的乱码问题，提供了明确的排查路径。

本机暂存