大项目不允许使用C++STL 容器合理吗？ 第1页

如果你有机会进Google，亲眼读一下Google File System的master的源码，就会知道中国坊间流传的很多关于C++的“经验/讲究”都是胡扯，包括题目中的这一条。顺便说一下，GFS 从2001年开始开发，当时就没什么STL忌讳。

我觉得你需要设法把“服务进程不能随便重启”这个条条框框打破，今后的日子就好过多了。否则一直被拖累，甚至造成安全问题。想想openssl最近一年出的那些状况，如由于不能重启而无法打上最新的安全补丁，那损失就大了。类似的情况还有bash的安全漏洞、时不时发布的内核安全补丁等等，评论中还列了其他一些需要重启的情况。

在Google，别说任何一台服务器可以随时重启，就是任何一个数据中心都可以随时下线维护，这才是服务可靠性的根源。

（八卦一下，在 GFS 论文的致谢一节中，最后一句是 Yoshka helped with early testing. 为什么别的致谢对象都有名有姓，单这一条有名无姓，答案在

。）

大胆点，你为什么不去怀疑前提的不合理呢？

首先应该挑战跑几个月不重启这种事情，为什么不重启呢，是服务进程状态必须维持，还是无法做到平滑升级？你们的系统总不可能不升级吧，而且C++任何系统也不保证说永远不会碰到core或OOM kill等莫名其妙没了的事情

所以换个角度，与其因噎废食，不如把根本问题解决了，如果你们能做到可以对外无感知地平滑升级，比如改为状态无关，或者出了问题简单重启就能恢复，那你的问题就不是问题

以前我在腾讯做过的几个服务器项目就是这样，如果数据逻辑可以分离，服务器随便重启不影响业务，就不会有这么多幺蛾子，当然也不是所有服务都能这么干，但是大部分业务进程是可以做到的，剩下需要常驻的那些，一般也都是成熟的组件服务，于是出现了不少鬼故事：

1 某项目更新代码只需要重启就行，于是同事连配置reload都懒得写了，每次更新配置直接kill -9然后重启

2 某项目内存泄露但泄得不是很快，大家也懒得管，crontab每天重启一次

3 进程挂了重启就行，不影响服务，某服务存在偶现core但是运维忘了配置告警，每次core了自动拉起，用户也没感觉到，直到几个月后磁盘被core文件填满了才发现