打印出什么？这个简单，了解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的目标是一致的——都是为了增加软件的可用性。

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

在 处理业务部门反馈的问题时，发现一个奇特的现象：php程序通过中间件收发消息，设置是3ms超时，运行正常，没有超时的消息；但如果在php里加一个循 环（加循环的位置与中间件的调用无关），超时出现了。php自己傻循环怎么会影响中间件消息的response time呢？

先是怀疑我们的php module写得不对，参考了一下别人的代码，发现没有什么特别的，用的是极简单的php module API，如果这样写都不对，真不知道什么是对的了。

再 是怀疑php本身，于是换了几个php版本（php接口也要重新编译，累人），问题依然出现。再把我们的中间件API加入php的 basic_function里，即做为php的内置函数（就像split,sleep这些函数一样），问题还是一样。可能不是php的问题。

接着怀疑apache，于是降低apache的进程数，发现httpd进程数为1或2的时候真的没有超时了，但进程数如果多于3就不行。难道apache的调度有问题？我们默认用的是prefork任务模式，换成worker试试（参见这里），换mpm了，php给apache的so也要重新编译（还是累人），最后发现换成worker任务内模式当进程数多了还是一样超时。

难道和php、apache都没有关系？干脆启动两个独立的php进程，没有超时；启动3个，没有超时；启动4个，超时来了。看来4这个数字很神秘。最后猜测是机器乃4核CPU，4个php进程占完了4个CPU，中间件daemon就没有保障了。

这个猜测有点跳跃，要想办法证明之，于是想到了CPU affinity，我们用taskset把4个php进程都绑定到0,1,2三个CPU上，此时超时消失了。看来之前确实是php进程占了4个CPU，导致中间件daemon无法足够快的分配到CPU。

解决方案呢？

如果我改改daemon，是不是能解决这个问题？于是把daemon的优先级设为最高（RT），超时依旧。

仔 细想想有了个结论：daemon用的CPU并不多，但是其睡眠和唤醒非常频繁（daemon主要是IO操作，转发来自网络的包），当其从睡眠中醒来时，必 须很快分配给它一个CPU，但是php占了4个CPU，所以不能很快的给daemon，所以daemon出现了延时（睡过头了），造成消息超时。这大概能 说明为什么把daemon设成高优先级不能解决问题——优先级虽高，但终究是要睡的。

我的结论就是这样，最后的证明还是要看看内核代码了。未完待续。