线程池

过程:

 

原先的改进过程:

单进程－>多线程－>多进程－>进程池(多进程的优化)

 

从理论上讲，在线程和多进程之间可能还有这样一个阶段(只不过我没有经历，直接跳过去了)：线程池(多线程的优化)，所以最终其实是这样的一个渐渐转变过程:

 

    单进程－>多线程－>线程池(多线程的优化)－>多进程－>进程池(多进程的优化)。

 

 

转变:

 

在刚开始未优化前，只是将程序的正确性放在第一位，当程序运行无误后，就有时间考虑如果进一步提高性能的优化问题了。

 

首先想到的就是多线程，由于资源的限制：CPU个数是有限的，每个进程所启动的线程数是有限的，而每个线程都要占用一定的代码空间和数据空间（对这个程序而言，数据空间占大部分），而这些都将算作整个程序所占用的空间，而这个值也是有限制的，所以理论上能并行运行的线程数是有限的。

 

为了避免出现上述的一些弊端导致程序的崩溃，改成多进程方式。

 

虽然启动进程速度方面不如启动线程，但是它分散了很多限制条件，比如每个进程启动的线程数（这样以来，就肯定不存在问题了），还有每个线程所占的空间也是各算各的，而无需累加，对程序所占空间的限制也几乎完全避免了，因此这个是非常好的选择。

 

优化前:

 

       一开始采用多进程的方式还是模仿多线程的方式进行处理的。

 

       假设并行数设置为10，那么我就一次性启动10个进程，然后等待这10个进程都处理完之后再启动下一组进程（还是10个）……,直到全部都处理完。

 

分析:

做法无口厚非，而且也是模拟多线程的pthread_join的做法的，似乎挺好，可是对于需要进行非常多次的操作来说就存在一个小小的浪费，就如同“木桶原理”，某一进程组的运行时间取决于最长的一个进程的运行时间（如果不考虑多进程之间的资源竞争因素），所以如果不幸是每组都有一个运行时间超长的话，那么尽管别的进程都完毕了，也无法起新的一组进程。

优化后:

 

       改进的思路自然而然带来了“进程池”的概念：

 

我们先准备10个进程池，说白了就是10个空位子而已，一个一个察看，如果位置空了，那么就在这个位子上启动一个进程，进程结束以后，自动退出该位子，那么通过不断轮巡位子的占用情况，一旦发现有“空位”，就启动一个进程，使同时运行的进程数永远保持<=10的情况，这样就基本消除了原先的等待时间，使资源利用率达到最佳。

 

结果:

 

       运行条件：拆分1000个文件，并行进程数为10。

 

日期

 

优化前（单位：秒）

 

优化后（单位：秒）

 

21

 

5371

 

5040

 

22

 

6951

 

6246

 

23

 

8801

 

7247

 

24

 

12482

 

10159

 

25

 

14149

 

12678

 

26

 

16320

 

14045

 

 

 

         结果也表明，这样的做法的确进一步提高了性能。