就在昨天，就在我们的项目要结项的时候，一个影响力不亚于’广岛原子弹’的bug出炉了，蒙蔽我近一个月的问题终于被澄清了，不过为时已晚，项目即将上线，如果想彻底地解决这个问题，需要对整个系统的实现架构作调整，目前能做的只是’亡羊补牢’了。
这里先简单的说一下问题的原因吧！熟悉Unix编程的人都知道有’共享内存映射’这回事儿，我们的问题恰巧就出在对’共享内存映射’的使用不当上。由于我们使用的底层库采用的是mmap的匿名共享内存映射，所以这里例子中的共享内存映射默认就指使用mmap的映射。我们可以利用下面的一个例子简单说明一下我在项目中遇到的问题，实际上看完这个’精简版’之后你会认为这很简单亚，怎么会让你困惑一个月，的确是这样不假，但是如果加上了繁杂的上下文后，找起来也并不是件容易的事情。
假设我们有这样的4个进程，它们的亲缘关系是这样的：A是爷爷，B、C是兄弟，并同为A的儿子，而D则是孙子，是B的儿子，用图表示如下：
A
| —- B
| |—-D
|
| —- C
问题就出在D利用mmap映射到匿名设备上后，将返回的起始地址赋值给一块由A创建，B、C、D都继承并能访问到的共享内存中的指针。C的任务是读写这块由D创建的这块儿共享内存中的数据。明眼人一眼就可以看出，C是访问不到这块D映射的共享内存的，即使C知道那块内存在D中的地址，但是由于C没有映射，在C进程空间中即使访问那个相同的地址，实际上访问的虚拟内存页也是不同的，最终的结果就是dump core。不光是C就连B、A也都无法访问D的那块共享内存，原因这里不详说，任一本质量上乘的有关Unix编程的书都会讲到这一点。
出现这样的问题，自己有推卸不掉的责任，先撇开责任不谈，反思自己在查找bug过程中的行为，我觉得有两个问题是今后需要改正的：
1、始终质疑别人的代码，导致在查找bug的时候戴上了’有色眼镜’，思维也发生了倾斜，把大部分时间和精力都花在查找别人的代码漏洞中，而忽略了对自己代码的细致地分析。不过这个过程到让我学了不少以前未接触的’知识领域’^_^。
2、测试时态度不够端正。其实项目负责人当初就对这块儿的可靠性有质疑，只是他当时也不能具体说明到底哪个地方的使用会出问题，回头看来自己在测试时测试用例不全，也是导致没有及时发现对症问题的一个重要原因，从而失去了走向查找出正确问题所在之道的机会！
问题既然发生了，那么我们如何来解决这个问题呢？我和leader一起想了若干种方法结果都被我们一一否决，最后拿出了一个折衷的方案，该方案虽然不存在上述问题了，但是它也让我们的系统不能完全满足用户的需求。这个方案说来也简单那就是采用’池策略’，而且这个池也是一个扩展性不好的池，也就是说我们在系统初始化的时候就预先映射完毕所有的内存，这样所有的A进程的子进程都会继承A的内存映射关系，从而解决上述问题，不过这样做实际上就给系统加了一个限制，容量上的限制。
在接下来的另一个类似需求的项目中我们还需要使用这样的架构，而且这个延续的项目需要的系统容量更大，在这个系统中我们需要对整体的系统架构进行改动了，否则一旦出问题，就不再是’亡羊’就可以’补牢’的了！
目前部门内所有项目的架构基本上都是基于’共享内存’的，虽然’共享内存’是最快的IPC对象，但是它同样给系统带来进程同步性能低下、亲缘关系错综复杂等弊端，甚至于对于我们目前项目这样的需求都不能很好的支持。程序庞大，动一发而牵全身。当然对架构的改造也不是一朝一夕之事，需要的是魄力、时间和耐心，起码让我们的Unix程序符合K.I.S.S这种最适合Unix的文化，目前我们采用的这种架构还是比较臃肿的。
评论