你必须解决它

随着时间的推移，很多程序里都会慢慢积累一些看似没用的或废弃的代码，没人敢动它们，因为担心会把程序弄坏。我认为，这些代码借助于人们对它的缺乏 了解，害怕修改程序——这其实是源于一种迷信，而非出于理智——而驻留在程序里，成为了一种具有最隐蔽形式的技术债务。你也许在处理这些代码时会把程序弄 坏，但你必须处理掉它们——为了坚守你的理智，为了保持程序的健康。

 

几周前，一个主要由我负责的我们的基础系统里的一个服务开始表现出反常现象。其中有一个线程的CPU使用率时不时会冲上100%，偶尔会减退平息， 但大多数会保持高位，留下一排让人烦恼的Munin监控图，它的每次冲锋都像是对我的嘲弄。通过一些查找发现了两个问题，我研究了好几天，结果却发现那只 是障眼法，根本不是问题的根源。

正好赶上假期，我把绝大部分的时间都花在了我们生产环境集群服务器的一个节点上，试图能明白这个问题的成因(这个现象只在生产环境且有一定的并发时 才会出现，在测试环境中无法复制，即使加到10倍的负载)。从凌晨2点到4点，不知损失了多少脑细胞，我胡乱的在程序里加入bug调试，异常捕捉(尽管没 有任何迹象显示有异常抛出)的代码，以及其它一些胡乱的，让人后怕的没用代码。最终，我发现了在一个资源竞争的条件判断中一个套接字标志可以被设置成 SO_WRITE，却从来没有被清除。这会导致在While(true)循环里的Selector.select()调用立即退出，而不是耐心的等待一个 网络IO事件发生，这最终导致了一个自我循环的线程占用100%CPU负荷的现象。幸运的是，这个问题并没有影响到这个服务的运行。修改了一下程序解决了 这个问题后(只是把一行代码剪切到原位置的下两行)，服务运行的非常的好，这个劳动节剩下的一个周末我在旧金山过的很愉快。

你必须解决它。

假期结束回到办公室后，我向我那充满耐心、热心帮助的同事为此事说了一大篇解释和抱歉的话，然而之后，我突然感觉到有些后怕，我在程序里留下了那么 多没用的显示log信息的、捕捉无意义异常的、其它的乱七八糟的代码，我害怕去碰它们了。理由站不住脚，这是害怕去改动能够正常运行的程序，尽管这些都是 迷信。

编程是一种科学，我们所有的系统都是基于其中的一些原则、约定和API(数学，POSIX，编程语言)。因为我知道这些各个层面上的知识，这些保证 了我不会产生没有根据的怀疑和恐惧，我不会让自己在这些问题面前吓的不敢乱动。迷信在编程中是没有用的——你可以问问任何一个能花上一两天去跟踪内存泄漏 问题的程序员。

我们面对的任务并不是“找出为什么运行异常”，而是去发现编程语言的哪种写法触发了这种不期望的行为。抛弃恐惧、误解、抱怨的思想习惯，要想到计算 机程序有它自己的规则，我们擅长于理顺它们。当然，最终，我的程序经过整理，完全按照我要求的方式精确的运行。它的工作流程我重新掌握的一清二楚，我又重 新控制了它。

如果你的程序让你害怕，你应该解决它，直到你不再怕它为止。

 

 

翻译来源：外刊IT评论

 

 

;-)

评论

19 楼 抛出异常的爱 2010-10-28  

callofseen 写道

问题终于解决了。

锁死是因为内存管理出了问题。内存管理出了问题是因为我误以为cpuid是从0开始的。而实际上在这个环境里，cpuid是从4开始的。于是改了一行宏，在里面加了个-4，问题就解决了。

楼上很效率

18 楼 callofseen 2010-10-28  

问题终于解决了。

锁死是因为内存管理出了问题。内存管理出了问题是因为我误以为cpuid是从0开始的。而实际上在这个环境里，cpuid是从4开始的。于是改了一行宏，在里面加了个-4，问题就解决了。

17 楼 todo158 2010-10-27  

很佩服LZ的勇气
代码如果还是正常运行，我是绝对不改

16 楼 aninfeel 2010-10-27  

弄好了领导不会奖励你，但是弄坏了的话……hoho

15 楼 raojl 2010-10-27  

dump core 是可以关闭的，也可以在程序内部屏蔽该信号。

14 楼 xiaobing 2010-10-27  

只有全面的了解系统，才能随意的改变代码，如果是接别人的项目，在不了解整个运行过程还是最好别乱改。

13 楼 sdh5724 2010-10-27  

主贴的内容回复下：

这家伙挺没有经验的， select这个问题， 基本差不多， 10秒种就能确定的。strace 看下就明白发生什么问题了。 额。。

12 楼 sdh5724 2010-10-27  

是无法上生产环境的？ 这就痛苦咯～

也写了很多年程序， 这几年我最大的感悟是， 代码的可诊断性比代码的性能来的重要的多。 一旦系统DOWN了， 每行log都显得弥足珍贵啊～

检查下lock 顺序吧。 lockA->lockB->lockC  unlockC->unlockB->unlockA  .  这话估计也是多余的了。 10年的程序员都知道这么干啊。

11 楼 parabellum_sky 2010-10-26  

我很想感受一下这种压力！

callofseen 写道

tuti 写道

2008lilewei 写道

callofseen 写道

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！
兄弟，要顶住 ！

可以找人结对一下,一个人的思维有局限性,而且自己还意识不到.
当你能把问题清晰得向另一个人描述出来时,往往会有意想不到的效果.

嗯。。。开始状态十分低迷，没想到这么多热心相助的同学，现在精神好了不少。
涉及的代码不多，大概2000行。而且每个字都是我自己敲出来的。加上这几天每天熬夜，基本上每行代码连同缩进和注释我都能背出来了。
其实难的不在于这个问题能不能解决。难点在于这个周末就要交货给客户了。这客户不是好惹的主，一旦delay，就是赔偿几百万USD。这当口出了错，压力太大了。
现在我基本放弃修修补补的A计划，打算改plan B了。放弃这2000行代码。写个性能差些但是确保稳定的顶_上去。然后在下次deliver之前再回头来修改A。
一晚上写了几封信给其他同事。等他们上班了，最后确定一下plan B，然后开工赶代码和测试。想想很可笑，无奈的笑。2个月前写的东西，在deadline最后2天被推翻重写。这个时候信心比什么都重要。

我工作差不多10年了。上一次有这种到边缘的感觉，大概是03年。

10 楼 skzr.org 2010-10-26  

tuti 写道

2008lilewei 写道

callofseen 写道

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！
兄弟，要顶住 ！

可以找人结对一下,一个人的思维有局限性,而且自己还意识不到.
当你能把问题清晰得向另一个人描述出来时,往往会有意想不到的效果.

一语道破天机！

9 楼 callofseen 2010-10-26  

tuti 写道

2008lilewei 写道

callofseen 写道

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！
兄弟，要顶住 ！

可以找人结对一下,一个人的思维有局限性,而且自己还意识不到.
当你能把问题清晰得向另一个人描述出来时,往往会有意想不到的效果.

嗯。。。开始状态十分低迷，没想到这么多热心相助的同学，现在精神好了不少。
涉及的代码不多，大概2000行。而且每个字都是我自己敲出来的。加上这几天每天熬夜，基本上每行代码连同缩进和注释我都能背出来了。
其实难的不在于这个问题能不能解决。难点在于这个周末就要交货给客户了。这客户不是好惹的主，一旦delay，就是赔偿几百万USD。这当口出了错，压力太大了。
现在我基本放弃修修补补的A计划，打算改plan B了。放弃这2000行代码。写个性能差些但是确保稳定的顶_上去。然后在下次deliver之前再回头来修改A。
一晚上写了几封信给其他同事。等他们上班了，最后确定一下plan B，然后开工赶代码和测试。想想很可笑，无奈的笑。2个月前写的东西，在deadline最后2天被推翻重写。这个时候信心比什么都重要。

我工作差不多10年了。上一次有这种到边缘的感觉，大概是03年。

8 楼 tuti 2010-10-26  

2008lilewei 写道

callofseen 写道

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！
兄弟，要顶住 ！

可以找人结对一下,一个人的思维有局限性,而且自己还意识不到.
当你能把问题清晰得向另一个人描述出来时,往往会有意想不到的效果.

7 楼 2008lilewei 2010-10-26  

callofseen 写道

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

这种情况确实让人抓狂，我最近也遇到了类似的问题，也是N久没有找出来问题所在，内心都有阴影了。但就像LZ所说的，你必须解决他 ！
兄弟，要顶住 ！

6 楼 callofseen 2010-10-26  

抛出异常的爱 写道

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

木有任何log。这里的运行环境比kernel还底层。log是靠UDP stack发送到syslog的。一旦CPU锁死了，任何信息都发不出来了。只有serial console寥寥几句无用的话。

5 楼 抛出异常的爱 2010-10-26  

callofseen 写道

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

dump log 有没有

4 楼 callofseen 2010-10-26  

从上周5开始。4天了。也是并发造成的死锁。没有panic，没有core，没有log。但是机器就是一遍又一遍的重启。每天都是2点之后睡觉。昨天咳嗽了一晚上，没睡觉。我有点绝望了。

3 楼 wmwer 2010-10-25  

有关系。。。。

2 楼 tuti 2010-10-25  

老抛又开始跑火车了，你回的和原帖有关系吗？

1 楼 抛出异常的爱 2010-10-25  

我们的DNA
也是由垃圾组成的.....

PS:程序员就是上帝
造就了人,
但人为什么会犯错你永远猜不到.