多进程/线程的取和舍

    多线程是我们在开发中必须掌握的一个开发技能，多线程可以充分发挥cpu多核的特性，充分利用cpu多核的优势，让我们的程序更快的运行，但是在实际开发过程中（注：我只工作了一年多的时间，主要做游戏开发，但是我看过几个大型的游戏的服务源码）多线程并不经常使用，只是在很少的地方使用了多线程去开发。为什么很多人排斥多线程呢。

    从给我目前的经验来看（一年多经验，望大神补充和修正）多线程虽然有他的优点，但不是必须的。

    一：虽然多线程可以利用多核的优势，但是系统维护这些线程和对线程之间的切换也需要消耗性能的，出了一些特定的场景比如c10k等

    二：多线程增加了开发难度，降低了开发效率，比如传统的并发模型采用主线程接收连接，开辟子线程去处理逻辑，但是在实际生产环境中发现，每个进程和线程都需要一定的资源，当这些进程／线程数量增加的一定过的数量是，它们维护和资源消耗给系统带了了很大的压力，并且根据二八原则，这些线程其实80%的时间其实是空闲的，但是它们在这段时间里也占有了系统大量的资源，因此多线程的并发效果并不理想，所以才有了select和epoll等多路服用机制，这种基于回调的reactor模型更能充分发挥服务器的处理能力和cpu的运算能力

   三：当然采用select和epoll模型解决了大部分的并发场景，但是当并发数量达到了一个更高的等级时它还是不够用，这时我们就会在select模型的基础上加上多线程去应对同一时刻到来的大量请求和数据，即主线程监听子线程epoll wait，这是就会有新的问题出现，即我们常说的惊群问题（linux内核版本2.6之后修复了该问题，但是也有人持不同的看法点击打开链接，在这里我也不下结论，没有亲自验证过，不过有人验证2.6之后确实没有惊群现象发生了http://blog.csdn.net/daiyudong2020/article/details/50417400），在2.6之前对于惊群的解决办法我们通常是加锁，这也是我们下面要说的另外一个点。

    四：数据的同步问题，因为多线程的存在，所以可能有多个线程同时操作一块数据区，此时为了数据的同步我们不得不通过锁的机制去保证数据的同步，这种机制看起来是行的通的，就像上面的机制，我们通过锁来保证同一时刻只有一个线程的epoll被唤醒，但是我们要知道上面我们只有一个数据要锁就是epoll监听的fd，当我们有大量的数据要同步的时候，比如游戏中的大地图数据，这些数据是所有人都能访问的，数据量很大，并且这些数据又会影响其他的数据，我们要通过锁机制来保证这些数据以及与之相关的数据的同步，看起来是一个很大的工程量，它所带了来的开发难度远远超过了它所带了的价值，并且锁也是消耗资源的，我们不能把这些同步问题寄托在申请大量的锁上，所以在有很多共享数据存在的场景中多线程并不是很好的选择。

   五：线程切换的代价，对于这一点并不是任何情况下都会有的，如果在一个线程里可以做完我们想做的事就不会有这个问题，但是当我们需要多个线程才能完成一个任务时，此时就需要收动的切换线程，这对于暂且不说切换线程在性能上的损耗，对于程序员来说需要我们很清楚的知道此时我们在做什么，什么时候要切换，要切换到哪个线程，切换过程中怎么保证数据的统一，这都需要我们考虑，要做到这些并不容易。

  经验有限，暂时了解这么多，以后漫漫补充（欢迎大家前来补充和修正）。最后附上惊群问题的一些资料点击打开链接