多线程并非万金油

我们项目中有一个daemon，功能是转发并处理消息，为了能看到daemon运行的细节，我们还做了一个monitor线程，由该线程通过某个端口提供简单的web服务，这样就可以直接用浏览器查看daemon的运行状态（比如处理了多少消息，丢弃了多少等）。后来，monitor线程出现了一个bug，造成线程挂掉——于是造成了整个daemon挂掉。这下郁闷了，daemon本身是很重要的，而monitor是不那么重要的，现在是次要部分的bug拖累了重要部分的运行。

这就是多线程程序的缺陷。如果多个线程做的是同样的事情，那还尚可；但如果多个线程，有的做这件事，有的做那件事，而且事情的重要程度不同，那不重要的线程由于代码错误或其他原因死了，其它的线程——包括执行重要功能的——也只能跟着挂。这在健壮性上肯定是不好的。apache采用多进程应该也是出于这样的考虑，因为它的module可能是用户自己写的，可能并不稳定，但由于module不稳定而挂掉整个apache，显然不应该。当然，apache2开始支持多线程，但即使这样，它默认还是多进程的，并没有整个倒向多线程。

也许有人会说：你代码写好一点，不要有bug，多线程不就没事了吗？首先，我们讨论的是软件健壮性的问题——怎样在坏了一部分以后其它部分还能工作，而不是软件正确性的问题——怎样写正确的代码。不是一个方向的问题，并不矛盾。其次，软件不可能没有bug，我们如果能把不同杀伤性的bug通过不同进程把它们隔开，就能降低影响，这跟挖掘bug的目标是一致的——都是为了增加软件的可用性。

所以，多线程并非万金油。为了健壮性，可以考虑把不同性质的任务分到不同的进程上，再由父进程统一管理。而在这些进程之下，可以再有多线程。当然，这样开发就复杂了。