酷壳 – CoolShell.cn

谜题的答案和活动的心得体会

2014年08月06日陈皓评论 98 条评论 58,939 人阅读

我于2014年8月3日周六的上午在微博、twitter、CoolShell上发布了一个和程序员有关的解谜题的活动—— 【活动】解谜题送礼物。我使用了二级域名fun.coolshell.cn做为这次活动的页面。

截止这篇文章发布的时候，fun.coolshell.cn的访问量UV大约有4万左右，通关人数大约有200人，但因为在活动的第二天网上就出了一些答题攻略，通过分析，实际靠自己能力通过的人数在130人左右。通过率大约不到4‰的样子。

在这里我把整个谜题和做这个活动的东西写一下，算是给自己的一个总结。

谜题的答案和花絮

fun.coolshell.cn上一共有十道谜题， 要设计这些东西还真是费尽脑汁，这让我对那些设计谜题式游戏的人相当敬佩 。

…

阅读全文 Read More

( 56 人打了分，平均分： 4.30 )

【活动】解迷题送礼物

2014年08月03日陈皓评论 107 条评论 45,972 人阅读

首先，先跟大家道歉一下最近CoolShell大约长达一个多月没有什么更新，原因主要在于，我去看世界杯去了，这一个月的世界杯熬夜看球使我的精力不佳，导致世界杯结束后的几个星期也没有缓过来，所以没有更新什么文章。好多朋友写邮件或是在微博上at我催我更新，所以有点惭愧了。

精神不佳我就不写文章了。于是，世界杯过后，我每天都会抽出每天晚上和周末的一些碎片时间，我仿照一些前端过关的游戏，做了几个和程序员有关的迷题，也是要通关的，不过和前端知识没什么关系。这个游戏我放到了下面这个二级域名下。

http://fun.coolshell.cn/

有兴趣的朋友可以去玩玩。通关的同学我会送你们《Unix环境高级编程（第三版）》（感谢 @出版圈郭志敏赞助）或一个马克杯（感谢 @linux命令行精选网赞助）），因为奖品数量有限，所以，我会送给前十个通关的同学（后面通关的我会随机抽几个）。

…

阅读全文 Read More

( 46 人打了分，平均分： 4.09 )

开发团队的效率

2014年06月09日陈皓评论 153 条评论 178,039 人阅读

我之前写过一篇叫《加班与效率》的文章，从概念上说了一些我对“效率”的认识，但是那篇文章趋于概念化，对于一些没有经历过这样的环境的同学来说，可能会觉得太抽象了。很早以前就想写一篇更具体一点的，可执行的文章与《加班与效率》这篇文章相辉映，并再把我两年前在杭州QCon上的那个 “ 鼓吹工程师文化”的《建一支强大的小团队》 （新浪微盘）的观点再加强一下。

但是我遇到了一些思维方式上的麻烦——我讲的总是从我的经历背景出发，没有从其它人的经历背景来讲 。这就好像，我在酷壳里说了很多东西（比如：专职的QA ， Code Review很重要，编程年龄，创业的， Rework 的……），有好些人觉得是不可能甚至太理想，其实我说的那些东西都是实实在在存在的，也是我所经历过的。于是，不同的经历，不同的环境，不同的眼界，造成了——有些人不理解我说的，而我也不能理解他们所说的。

所以，过去的这段时间我一有机会就找一些人交流并观察一些身边的事情，并去试着跟从和理解那些我不能理解的东西。现在觉得差不多了，所以，写下了这篇文章。（但越是去理解对方，我就越坚持我的观点，所以这篇文章可能还是会出现鸡同鸭讲的情形，无所谓了）

本文不讨论任何业务上的效率问题，只讨论软件开发或是软件工程中的效率问题。虽然产品和业务上的效率问题是根本，但是因为本文不是拉仇恨的，我也不想混在一起谈，所以请原谅我在这里先说开发团队的，以后重新开篇文章专门谈产品和业务的。

我下面会罗列几个非常典型的开发方式—— 软件开发中的“锁” ， 接力棒式软件开发 ， 保姆式软件开发 ， WatchDog软件开发 ， 故障驱动式软件开发 。

…

阅读全文 Read More

( 112 人打了分，平均分： 4.68 )

TCP 的那些事儿（下）

2014年05月28日陈皓评论 162 条评论 284,155 人阅读

这篇文章是下篇，所以如果你对TCP不熟悉的话，还请你先看看上篇《 TCP的那些事儿（上）》上篇中，我们介绍了TCP的协议头、状态机、数据重传中的东西。但是TCP要解决一个很大的事，那就是要在一个网络根据不同的情况来动态调整自己的发包的速度，小则让自己的连接更稳定，大则让整个网络更稳定。在你阅读下篇之前，你需要做好准备，本篇文章有好些算法和策略，可能会引发你的各种思考，让你的大脑分配很多内存和计算资源，所以，不适合在厕所中阅读。

TCP的RTT算法

从前面的TCP重传机制我们知道Timeout的设置对于重传非常重要。

设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。

而且，这个超时时间在不同的网络的情况下，根本没有办法设置一个死的值。只能动态地设置。为了动态地设置，TCP引入了RTT——Round Trip Time，也就是一个数据包从发出去到回来的时间。这样发送端就大约知道需要多少的时间，从而可以方便地设置Timeout——RTO（Retransmission TimeOut），以让我们的重传机制更高效。听起来似乎很简单，好像就是在发送端发包时记下t0，然后接收端再把这个ack回来时再记一个t1，于是RTT = t1 – t0。没那么简单，这只是一个采样，不能代表普遍情况。

…

阅读全文 Read More

( 102 人打了分，平均分： 4.75 )

TCP 的那些事儿（上）

2014年05月28日陈皓评论 237 条评论 488,078 人阅读

TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看 W.Richard Stevens 的《 TCP/IP 详解卷1：协议》（当然，你也可以去读一下 RFC793 以及后面N多的RFC）。另外，本文我会使用英文术语，这样方便你通过这些英文关键词来查找相关的技术文档。

之所以想写这篇文章，目的有三个，

一个是想锻炼一下自己是否可以用简单的篇幅把这么复杂的TCP协议描清楚的能力。
另一个是觉得现在的好多程序员基本上不会认认真真地读本书，喜欢快餐文化，所以，希望这篇快餐文章可以让你对TCP这个古典技术有所了解，并能体会到软件设计中的种种难处。并且你可以从中有一些软件设计上的收获。
最重要的希望这些基础知识可以让你搞清很多以前一些似是而非的东西，并且你能意识到基础的重要。

所以，本文不会面面俱到，只是对TCP协议、算法和原理的科普。

…

阅读全文 Read More

( 128 人打了分，平均分： 4.82 )

「我只是认真」聊聊工匠情怀

2014年05月26日王晨纯评论 78 条评论 74,349 人阅读

（感谢网友 @Hesey小纯纯投稿博客 | 原文链接）

老罗的Smartisan T1手机发布会很多人应该都看了，发布会的最后老罗凝视着自己的工匠自画像，半晌没说话，随后转过身，慢慢离开舞台，屏幕下方只留下一句话：

我不是为了输赢，我就是认真。

这一瞬间让我想起93年「狮城舌战」的主角蒋昌建，在「人性本善还是人性本恶」的总结陈词最后，以顾城的名句，「黑夜给了我黑色的眼睛，我却用它寻找光明」，把整个辩论赛的氛围推向高潮。

而老罗的这句话，和这句话背后的工匠背景，却以另外一种 无声的却震人心魄的力量 ，敲打着每一个在场的，或是观看着整个发布会的观众的心绪。

「工匠情怀」，我深有体会，就像我在面向GC的Java编程一文中所提到的：

优秀程序员的价值，不在于其所掌握的几招屠龙之术，而是在细节中见真著。

如果我们可以一次把事情做对，并且做好，在允许的范围内尽可能追求卓越，为什么不去做呢？

追求卓越，追求完美，追求细节的极致。小时候看到那些修表匠，握着一个小螺丝刀，或是看着电工，用烙铁沾着锡和松香，在那一小寸的世界里，把坏了的地方修好，那种专注的眼神，觉得很厉害。

现在再去回想那些工匠工作的场景，越发觉得钦佩。在我老家有一家刻章的店，在我上幼儿园的时候就已经在那开了很多年了。前段时间需要刻一个章，发现那家店还在，于是走进去，门口坐着一个老人，我确实记不得当年是不是他，不过看这岁数八九不离十。我以前在别的地方刻的章，都是在电脑里设计完图案后，激光刻蚀。但那次老人却是用的手刻，我着实惊呆了。只看他拿出一块红色的印底，右手持着刻刀，开始一下一下地刻着。虽然老人连话都不怎么说得清了，但是工作时那专注的神情，和精湛的手艺，以及最后成品那比机器更完美的效果，着实让我心里非常动容。

…

阅读全文 Read More

( 82 人打了分，平均分： 4.32 )

面向GC的Java编程

2014年05月07日王晨纯评论 46 条评论 60,405 人阅读

（感谢网友 @Hesey小纯纯投稿博客 | 原文链接）

Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题。以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧！甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决。

这话其实也没有太大问题，的确，大部分场景下关心内存、GC的问题，显得有点“杞人忧天”了，高老爷说过：

过早优化是万恶之源。

但另一方面， 什么才是“过早优化”？

If we could do things right for the first time, why not?

事实上 JVM的内存模型 ( JMM )理应是Java程序员的基础知识，处理过几次JVM线上内存问题之后就会很明显感受到，很多系统问题，都是内存问题。

对JVM内存结构感兴趣的同学可以看下浅析Java虚拟机结构与机制这篇文章，本文就不再赘述了，本文也并不关注具体的GC算法，相关的文章汗牛充栋，随时可查。

另外，不要指望GC优化的这些技巧，可以对应用性能有成倍的提高，特别是对I/O密集型的应用，或是实际落在YoungGC上的优化，可能效果只是帮你减少那么一点YoungGC的频率。

但我认为， 优秀程序员的价值，不在于其所掌握的几招屠龙之术，而是在细节中见真著 ，就像前面说的， 如果我们可以一次把事情做对，并且做好，在允许的范围内尽可能追求卓越，为什么不去做呢？ …

阅读全文 Read More

( 41 人打了分，平均分： 4.00 )

C语言的整型溢出问题

2014年04月21日陈皓评论 96 条评论 109,641 人阅读

整型溢出有点老生常谈了，bla, bla, bla… 但似乎没有引起多少人的重视。整型溢出会有可能导致缓冲区溢出，缓冲区溢出会导致各种黑客攻击，比如最近OpenSSL的heartbleed事件，就是一个buffer overread的事件。在这里写下这篇文章，希望大家都了解一下整型溢出，编译器的行为，以及如何防范，以写出更安全的代码。

什么是整型溢出

C语言的整型问题相信大家并不陌生了。对于整型溢出，分为无符号整型溢出和有符号整型溢出。

对于unsigned整型溢出，C的规范是有定义的 ——“溢出后的数会以2^(8*sizeof(type))作模运算”，也就是说，如果一个unsigned char（1字符，8bits）溢出了，会把溢出的值与256求模。例如：

unsigned char x = 0xff;
printf("%d\n", ++x);

上面的代码会输出：0 （因为0xff + 1是256，与2^8求模后就是0）

对于signed整型的溢出，C的规范定义是“undefined behavior” ，也就是说，编译器爱怎么实现就怎么实现。对于大多数编译器来说，算得啥就是啥。比如：

signed char x =0x7f; //注：0xff就是-1了，因为最高位是1也就是负数了
printf("%d\n", ++x);

上面的代码会输出：-128，因为0x7f + 0x01得到0x80，也就是二进制的1000 0000，符号位为1，负数，后面为全0，就是负的最小数，即-128。

…

阅读全文 Read More

( 47 人打了分，平均分： 4.34 )

从LongAdder看更高效的无锁实现

2014年04月17日 liuinsect 评论 35 条评论 47,374 人阅读

（感谢 @jd刘锟洋投稿，更多文章参看他的博客：码梦为生）

原文链接 ：《比AtomicLong还高效的LongAdder 源码解析》

接触到AtomicLong的原因是在看guava的LoadingCache相关代码时，关于LoadingCache，其实思路也非常简单清晰：用模板模式解决了缓存不命中时获取数据的逻辑，这个思路我早前也正好在项目中使用到。

言归正传，为什么说LongAdder引起了我的注意，原因有二：

作者是Doug lea ，地位实在举足轻重。
他说这个比AtomicLong高效。

我们知道，AtomicLong已经是非常好的解决方案了，涉及并发的地方都是使用CAS操作，在硬件层次上去做 compare and set操作。效率非常高。

因此，我决定研究下，为什么LongAdder比AtomicLong高效。

首先，看LongAdder的继承树：

la1

继承自Striped64，这个类包装了一些很重要的内部类和操作。稍候会看到。

…

阅读全文 Read More

( 23 人打了分，平均分： 3.91 )

从Code Review 谈如何做技术

2014年04月12日陈皓评论 218 条评论 205,670 人阅读

（这篇文章缘由我的微博，我想多说一些，有些杂乱，想到哪写到哪）

这两天，在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录，从上面发现Code Review做得好的是一些比较偏技术的团队，而偏业务的技术团队基本上没有看到Code Review的记录。当然，这并不能说没有记录他们就没有做Code Review，于是，我就问了一下以前在业务团队做过的同事有没有Code Review，他告诉我不但没有Code Review，而且他认为Code Review没用，因为：

1）工期压得太紧，时间连coding都不够，以上线为目的，

2）需求老变，代码的生命周期太短。所以，写好的代码没有任何意义，烂就烂吧，反正与绩效无关。

我心里非常不认同这样的观点，我觉得我是程序员，我是工程师，就像医生一样，不是把病人医好就好了，还要对病人的长期健康负责。对于常见病，要很快地医好病人很简单，下猛药，大量使用抗生素，好得飞快。但大家都知道，这明显是“饮鸩止渴”、“竭泽而渔”的做法。医生需要有责任心和医德，我也觉得程序员工程师也要有相应的责任心和相应的修养。东西交给我我必需要负责，我觉得这种负责和修养不是”做出来“就了事了，而是要到“做漂亮”这个级别，这就是“山寨”和“工业”的差别。而只以“做出来”为目的标准，我只能以为，这样的做法只不过是“按部就班”的堆砌代码罢了，和劳动密集型的“装配生产线”和“砌砖头”没有什么差别，在这种环境里呆着还不如离开。

老实说，因为去年我在业务团队的时候，我的团队也没有做Code Review，原因是多样的。其中一个重要原因是，我刚来阿里，所以，需要做的是在适应阿里的文化，任何公司都有自己的风格和特点，任何公司的做法都有他的理由和成因，对于我这样的一个初来者，首要的是要适应和观察，不要对团队做太多的改动，跟从、理解和信任是融入的关键。（注：在建北京团队和不要专职的测试人员上我都受到了一些阻力），所以跟着团队走没有玩Code Review。干了一年后，觉得我妥协了很多我以前所坚持的东西，觉得自己的标准在降低，想一想后背拔凉拔凉的，所以我决定坚持，而且还要坚持高标准。

…

阅读全文 Read More

( 211 人打了分，平均分： 4.77 )