多线程vs多进程（分析、比较和建议…

    准备培训教材，想带过这一点，又懒得自己总结，于是跑到网上乱看。发现在这点上存在太多误会。虽然评论中不乏真知灼见，但作者基本都没有说到点上。
    误区1：把并发的难度归结到多线程or多进程身上。比如像锁之类问题，如果某个模型很难实现和规避，另一个模型也好不到哪里去。如果某个模型很容易搞定，另一个模型最多复杂一点点。比如某个应用多进程时不需要用锁，那好，多线程程序用TSS，也就多一个锁，能复杂到哪里去？
    误区2：把并发和分布式糅合在一起，得到晕头的结论：多进程可以运行在多台主机，多线程不行。程序不管是多进程还是多线程，都可以抓去另一台主机运行，但这些主机间能否彼此协作，取决于软件是否是分布式设计。
    误区3：裸奔比较性能，其实这点真不重要，两者都够快了。如果实现后发现一个模型比另一个模型快得多，只能说明具体实现有问题。
    误区4：比较创建销毁的代价，如果是高性能的应用，肯定不会经常创建、销毁进程/线程；如果不是那么在意性能的应用，两者的些许差异有意义吗？
   
    我的看法：
    多线程的最主要优点是：共享数据方便（都在一个地址空间，不需要IPC）；可移植性好。
    多进程的最主要优点是：可靠性较高（进程间彼此隔绝，一个进程被OOXX不会影响其他进程）；能够在外部监控（因为进程是操作系统分配资源的对象）。
    开发难度：多线程比较简单，因为不用去搞体位繁多的IPC，故不容易被不熟悉的API阴到。
    调试难度：都很麻烦，是开发者的噩梦。所以需要多些单元测试，多测试，多做日志，少调试。
   
    对于选择的建议：
    需要能工作在windows => 多线程
    线程/进程间没有什么需要共享的数据 => 多进程优先，反之多线程优先。需要共享的数据越多越复杂，多线程得分越高。
    对可靠性要求高 => 取决于开发团队，无数优秀产品证明多线程程序可以坚如磐石，但未必每个团队都能做到。
    需要监控单个工作者占用的资源 => 多进程
    开始学习并发编程 => 多线程，学习曲线较低，要掌握的API较少