高性能服务器编程感悟

      前些年，程序性能随着硬件升级而提升往往不怎么需要程序员的参与。比如cpu频率从100M上升到500M，原先要执行1min的程序现在可能只要执行10几秒。而需要使用大内存的程序在内存扩容后执行速度也往往可以提高很多。但是现在情况发生了变化，想想吧。主流配置为cpu主频2g+内存2g的时间已经持续了多久？太久了，现在进入了多核的时代，单核-双核-四核。CPU也开始使用狼群战术了。这时候如果想要提升程序性能，就需要程序员付出额外的努力了：使用多进程、多线程，在享受快感的同时承受同步之类问题的折磨。
      我个人喜欢多线程超过多进程，hoho，程序员控制线程比控制进程方便多了，共享数据也方便。所以以下讨论都基于多线程并发。另外，虽然题目是“高性能服务器编程”，但接下来讲的只有并发而不包括通信模式。ps：一个好的服务器架构应该较好地将通信和业务划分开，哪天我有空了再讲通信模式吧哈哈。
      我的一些感悟：
      1）不管什么程序 模块化都很重要，对于并发程序更是如此。设想一下如果全局变量满天飞，线程安全是多么让人绝望的一件事。什么是模块？我不想去google上copy软件工程教材上的话。在我看来，<定义一>模块就是你把它实现为一个类后在实现及修改重构时没有感到后悔，几年后回头看不觉得自己sb的东东。如果程序是并发的，务必保证里面会并发访问到的各个模块是 线程安全的。
      2）大锁 = 开发方便，安全性高 = 效率低；小锁 = 开发繁琐，潜在bug多 = 效率可能高但搞不好说不定更低。以上是废话，大家都懂。以下不是废话： 大部分模块直接使用大锁即可。优化所有代码可能引入bug（多线程还是挺费脑筋的），肯定浪费时间，效率未必提高多少。优化应该抓住关键点进行优化。但是（但是是很重要的,汉语的特点)，模块的数据结构应该保证使用小锁时不需要太多修改。具体地说：就是 数据结构中应该明确定义单元。<定义二>单元，就是增删改查会操作到的最小单位，或者这样一个东西：如果你没有把它实现为一个类，当你想把锁改小时会后悔。举个例子吧，假设班级是一个模块，提供若干个操作，班级下可以有很多学生，如果不把学生作为ADT，在学生属性不多的时候实现起来也完全OK，但是如果以后想用小锁对一个学生加锁呢？方法一，用一组锁，然后满地找修改和读取学生属性的代码块进行加锁处理，可能改得鸡飞狗跳。方法二，k自己一巴掌，咋这么笨呢，将学生概念抽取为ADT，然后在这个ADT里面放一个锁。
      3) 记得软工里面讲模块要高内聚， 低耦合。啥叫低耦合？如果你一个模块里面保存另一个模块内数据的引用、指针甚至是数组的某个位置。这耦合度就很高了。耦合度高时线程安全简直没法做，除非你整个程序就一个锁——那和单线程程序区别也不会很大了。所以并发程序别这么干。就像现在很多数据库设计也都不用外键一样。数据可以用程序来保证逻辑关联，但避免真实物理关联。举个例子，有一个模块是班级，一个模块是学生。比较低耦合的设计是班级中保存这个班级学生的学号集合。高耦合的设计是班级中保存这个班级学生的内存地址集合。高耦合的情况下，很多操作实现起来都会一阵鸡飞狗跳。
      4）要想效率高，就要 等待少。这又是废话。就像吃多变胖喝水止渴一样。所以关键是下面我要讲的几个模式，这几个模式可以达到该目的。我可能一时想不全，以后慢慢补充吧。
            a）要想富，少生孩子多种树。咳咳，说错了。第一个是随便搞模式，也就是说不锁了，信春哥得永生，信润哥无bug。当一个模块都没有提供修改操作时你锁它干嘛？
            b）swap指针模式：先把数据准备好，锁住，交换指针。这样子可以大为降低锁定持续的时间。
            c）读写锁模式：大部分时候，只读操作比写操作要多得多，使用读写锁吧！
            d）趁热模式：需要使用智能指针。常有这种数据结构，主体为一个容器如vector（或者map之类），有一部分操作会增减该容器的元素，但大部分操作只是针对该容器某一元素做些邪恶的事情，可是做邪恶事情时我们也不得不锁住整个容器——不然干一半突然发现对象消失了岂不是很扫兴？（如果那个服务因此挂了值班人员半夜call你真的可能扫了某方面的性质）。一个比较好的方法是容器内保存的是智能指针，第一步锁容器，获取该指针，解锁，然后对这个指针想干嘛就干嘛。就算该元素被移出容器了，你也可以趁热继续嘿咻嘿咻。没有引用计数处理内存释放太麻烦了，所以要用智能指针。另外，容器元素应该提供线程安全操作。