以指定的并行度并行压缩大量的文件

       背景：最近有一同事需要对一批文件进行压缩，文件比较大也比较多，希望能同时对多个文件进行压缩，同时还要求同时被压缩的文件的个数

要受控制，可以指定；这样做的目的是为了充分利用系统的资源，又不造成因为竞争资源而降低压缩的效率。为此我专门写了一个SHELL，来完成这个功能。觉得很有意识。所以拿出来和大家分享一下。如果能给大家一点点的启发或者

帮助，那将是我最大的荣幸！

 

       原理：遍历fileList.txt文件（该文件保存着要被压缩的文件的文件名），如果当前正在执行的gzip的数目少于预定值4，则执行gzip命令压缩

文件，如果已经超过预定值4，则休眠10秒钟。利用信号机制，当gzip执行完成的时候会向父进程发SIGCHLD信号，父进程捕获该信号后，将保存

正在执行的GZIP数目的变量runNum的值减一。

       代码：

################################################################

#!/bin/bash

set -bm  #必须执行该命令，不然会收不到信号
runNum=0

#信号处理函数
function traSIGCHLD(){
   echo 'a child exit'
   runNum=$((runNum-1))
}

#注册信号处理函数
trap 'traSIGCHLD' SIGCHLD
trap -p

 

while read line
do

   #如果超过4个进程再运行则休眠
   if [ $runNum -ge 4 ]
   then
       echo  "$runNum more than 4,will sleep!"
       sleep 10 &
       wait $!
       runNum=$((runNum+1))

   #如果低于四个进程在运行则启动新的进程
   else
       echo "$runNum less than 4,will start new task!"
       #这里是要执行的命令
       gzip $line &
       runNum=$((runNum+1))
   fi
done<fileList.txt;

#取消信号注册
trap SIGCHLD

##################################################################

        特殊说明：1。 sleep 10 &返回的时候也会向父进程发SIGCHLD信号，从而造成runNum的值被减一。从而使变量runNum不能正确

的反应正在运行的gzip的数目(比正在运行的数目小)  ，这会造成真实的正在运行的gzip的数目多于指定的数目4，并且sleep 10 &每返回

一次，就会多一个gzip。这里通过wait $!让主程序等待sleep 10 &的返回，只要它一返回，马上对runNum进行补偿加一；

                        2。这个是在我测试的代码的基础上做过小小的修改的，没经过测试，所以可能会存在一些问题，但是基本原理是一样的。所以

如果大家想在真实环境使用的话请严格的测试后再使用，以免造成系统事故；