07 2010存档

打印出什么？这个简单，了解c++的都能答对：打出 "Small Pig“，因为是虚函数嘛。

好，现在改改Pig类：

再运行，就不是打出3行“Small Pig”了，而是：

Pig

Small Pig

Pig

为什么？因为构造函数和析构函数特殊，在它们里面this指针只能当成自己用（而不是当成子类），所以调用虚函数的结果是调用了父类的实现。

这个问题造成了今天的bug，花了不少时间。其实这个注意事项在《Effective c++》里是有的，我也看过，但是....开发中谁还记得那么多条条框框？还是实际犯错印象比较深刻。

有人问了：如果我把call改成纯虚函数会怎样呢？更郁闷，g++编译的时候就会提示构造函数里的call“找不到实现”！

【原理】

现在互联网公司使用的都是多CPU（多核）的服务器了，Linux操作系统会自动把任务分配到不同的处理器上，并尽可能的保持负载均衡。那Linux内核是怎么做到让各个CPU的压力均匀的呢？

做一个负载均衡机制，重点在于：

1. 何时检查并调整负载情况？

2. 如何调整负载？

先看第一个问题。

如果让我这样的庸俗程序员来设计，我第一个想到的就是每隔一段时间检查一次负载是否均衡，不均则调整之，这肯定不是最高效的办法，但肯定是实现上最简单的。实际上，2.6.20版linux kernel的确使用软中断来定时调整多CPU上的压力（调用函数run_rebalance_domains），每秒1次。

但每秒一次还是不能满足要求，对很多应用来说，1秒太长了，一秒钟内如果发生负载失衡对很多web应用都是不能接受的，何况其他实时应用。最好kernel能够紧跟进程的变化来调整。

那么，好，我们在进程创建和进程exit的时候检查并调整负载呢？可以，但是不完整，一个进程创建以后如果频繁的睡眠、醒来、睡眠、醒来，它这样折腾对CPU的负载是有影响的，你就不管它了吗？说到底，我们其实关注的是进程是否在使用CPU，而不是它是否诞生了。所以，我们应该在进程睡眠和醒来这两个时间点检查CPU们的负载。

再看第二个问题，怎么调整负载呢？从最繁忙的那个CPU上挪一个进程到最闲的那个CPU上，如果负载还不均衡，就再挪一个进程，如果还不均衡，继续挪....这也是个最笨的方法，但它却真的是linux CPU负载均衡的核心，不过实际的算法在此基础上有很多细化。对于Intel的CPU，压缩在同一个chip上的多核是共享同一个L2的（如下图，里面的一个Processor其实就是一个chip），如果任务能尽可能的分配在同一个chip上，L2 cache就可以继续使用，这对运行速度是有帮助的。所以除非“很不均衡”，否则尽量不要把一个chip上的任务挪到其他chip上。

于是，为了应对这种CPU core之间的异质性——在不同的core之间迁移任务，代价不同——Linux kernel引入了sched_domain和sched_group的概念。sched_domain和sched_group的具体原理，可参考刘勃的文章和英文资料。

【代码剖析】

SMP负载均衡检查或调整在两个内核函数里发生：

1. schedule（）。当进程调用了sleep、usleep、poll、epoll、pause时，也就是调用了可能睡去的操作时都会转为内核代码里对schedule()函数的调用。

2. try_to_wake_up() 。说白了就是进程刚才睡了，现在要醒来，那醒来以后跑在哪个CPU上呢？这个选择CPU的过程，也就是负载均衡的过程。

我们先看schedule（）的代码，我们忽略函数前面那些和负载均衡无关的代码（本文代码以内核2.6.20版为准）：

[kernel/sched.c --> schedule() ]

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

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

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

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