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