大多情况下，并行对复杂度影响过大，并间接导致测试困难---多线程或多进程导致的问题往往是有时发生，有时不发生，一般的测试手段并不足以发现这类问题。

　　所以原则上应该尽可能不用，除非收益足够大。或则说在满足需求的前提下，线程数和进程数应该尽可能少。

　　以多线程和多进程而论，确定“什么时候适合使用这种技术”是比“怎么使用这项技术”困难的多的事情。

　　现实中人们往往对事件，信号灯等同步处理手段关注过多，而对究竟应不应该启用多线程/进程关注的太少。这里来简单做个总结，对于下面这些场景，一般来讲启用多线程/进程是合适的：

　　● 数据很容易分割，处理不同数据时彼此间没有什么交互。比如说：你有10万个文件需要处理，每个文件的处理彼此独立。这时候显然要做并行，这样最终数据处理速度将依赖于并行分布的程度。这好像很简单，但却触发了MapReduce这样著名的模型（参见《软件随想录》）。在待处理数据持续增长的情形下，如果不启用并行，那几乎没有办法保证速度不会下降，这并不是单纯靠优化算法可以解决的问题。

　　● 监控设备响应（端口监视也应该属于这个类别）。这时候我们会希望能及时响应设备的事件，而不希望设备上的数据采集和对数据的处理彼此干涉。比如：Windows中就单独建立了Raw Input Thread（RIT）来监控整个系统的键盘和鼠标消息，而后再分发给各个进程中的线程。（详见《Windows核心编程》）。

　　● 优化UI响应速度。比如：用文档编辑器打开大文件时，如果不分离UI响应和实际处理，UI会挂起，很典型的应用是进度条的处理。使用了MVC（Model-View-Controller）模式的应用中大多时候可以适用这条，因为很多时候都需要View和Controller总是保持响应。

　　● 待处理的请求天生就是并行的。比如：当浏览不同网站时，不同的网站的显示会在不同的窗口中处理，这类处理天生就是并行的，既可以用多线程也可以用多进程。客户-服务器体系也是这类情形。

　　● 计算量很大，并且算法可以分割。有些传说中的领域（大气模拟、基因工程等）事实上是并行计算的主战场，比如在展示MPI（Message Passing Interface）的使用时，经常使用的计算π的例子，就是如此。但这离通用软件开发的距离就有点远，知之不详，这里就不列了。

　　这个列表应该进一步总结和加长，但限于精力，眼下却只能列这么多了。

　　对于多线程的误用，在MSDN上可以找到一份很好的总结，这里提取几个典型的结果：

　　● 锁争用和顺序执行。这时虽然启用了多线程，但实际执行起来这些线程是串行的。

　　● 过度订阅。如果系统的核数远少于线程数，同时启动很多个线程，时间往往会浪费在抢占上。

　　● I/O效率低。多线程被用来做频繁的I/O操作，这会导致很多时间开销在I/O操作上。

　　多进程的误用眼下看到的总结还不多，这里略过，有经验的可以帮忙一起总结。

　　最后加一点关于并行种类的补充资料：

　　为并行分类并不是很容易的事，这里只介绍一种最简单的，依据内存架构对并行进行分类的方法。依据内存架构，并行可以分为三类：

　　● Shared Memory： 常说的多线程即是这一类，比较有名的实现是OpenMP。

　　● Distributed Memory：如果多台PC组合起来进行并行计算那就是这一类。比较有名的实现是MPI。

　　● Hybrid Distributed-Shared Memory：如果多台PC进行分布，每台PC上还启用多核，那就是这类。

　　有人似乎还想进一步区分并行和并发，这就有点微妙了，个人不是很能分的清楚。