TCP/IP网络编程之多进程服务端(一)
进程概念及应用
我们知道,监听套接字会有一个等待队列,里面存放着不同客户端的连接请求,如果有一百个客户端,每个客户端的请求处理是0.5s,第一个客户端当然不会不满,但第一百个客户端就会有相当大的意见了。为了要使得所有客户端都尽可能的满意,我们应采用并发服务端,使其同时向所有发起请求的客户端提供服务。而且,网络程序中数据通信时间比CPU运算时间占比更大,因此,向多个客户端提供服务是一种有效利用CPU的方式。接下来讨论同时向多个客户端提供服务的并发服务端,下面提出具有代表性的并发服务端实现模型和方法:
- 多进程服务器:通过创建多个进程提供服务
- 多路复用服务器:通过捆绑并统一管理I/O对象提供服务
- 多线程服务器:通过生成与客户端等量的线程提供服务
先来简单理解下进程:我们打开电脑一般不会只做一件事,比方单纯的浏览网站,单纯的聊天。一般我们都是几件事轮流切换着做,我们会在浏览网页时打开音乐播放器播放音乐,还会时不时回复下QQ消息。那么这里就牵扯到三个进程了,一个是浏览器进程,一个是播放器进程,还有一个是QQ进程。从操作系统的角度看,进程是程序流的基本单位,若创建多个进程,则操作系统将同时运行。有时一个程序运行过程中也会产生多个进程,像谷歌浏览器,打开一个tab页,实际上就是产生一个新的进程。接下来要创建的多进程服务器就是其中的代表,编写服务端前,先了解一下通过程序创建进程的方法
CPU核的个数和进程数:拥有两个运算器的CPU称为双核CPU,拥有四个运算器的CPU称作四核CPU。也就是说,一个CPU可能包含多个运算器(核)。核的个数与可同时运行的进程数相同,相反,若进程数超过核数,进程将分时使用CPU资源。但因CPU运算速度极快,我们会感到所有进程同时运行,当然,核数越多,这种感觉越明显
进程ID
讲解创建进程方法前,先简要说明下进程ID。无论进程是如何创建的,所有进程都会从操作系统分配得到ID。此ID称为“进程ID”,其值为大于2的整数,1要分配给操作系统启动后的(用于协助操作系统)首个进程,因此用于进程无法得到ID为1的进程ID,接下来观察Linux中正在运行的进程:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
# ps au
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 384 0.0 0.0 1520 208 pts
/23
Ss+ Sep04 0:00
/bin/sh
-c nginx -g
"daemon on;"
&& uwsgi --ini
/data/web/uwsgi
.ini
root 438 0.0 0.6 257212 36936 pts
/23
Sl+ Sep04 0:03 uwsgi --ini
/data/web/uwsgi
.ini
root 473 0.0 0.0 1520 208 pts
/3
Ss+ Sep21 0:00
/bin/sh
-c nginx -g
"daemon on;"
&& uwsgi --ini
/data/web/uwsgi
.ini
root 513 0.0 0.7 186080 44028 pts
/3
S+ Sep21 0:05 uwsgi --ini
/data/web/uwsgi
.ini
root 555 0.0 0.6 186724 40404 pts
/3
Sl+ Sep21 0:00 uwsgi --ini
/data/web/uwsgi
.ini
root 702 0.0 0.0 110044 696 tty1 Ss+ Aug19 0:00
/sbin/agetty
--noclear tty1 linux
root 703 0.0 0.0 110044 732 hvc0 Ss+ Aug19 0:00
/sbin/agetty
--keep-baud 115200 38400 9600 hvc0 vt220
root 3025 0.0 0.0 1520 16 pts
/1
Ss+ Aug19 0:00
/bin/sh
-c nginx -g
"daemon on;"
&& uwsgi --ini
/data/web/uwsgi
.ini
root 3694 0.0 0.1 242444 10644 pts
/1
Sl+ Aug19 0:01 uwsgi --ini
/data/web/uwsgi
.ini
root 3992 0.0 0.0 102696 1468 pts
/7
Ss+ Aug19 10:49
/usr/local/bin/python
/usr/local/bin/gunicorn
-w 3 -k gevent -b :5001 manage:app
root 4089 0.0 0.0 11636 8 pts
/8
Ss+ Aug19 0:00
/bin/sh
-c uwsgi --ini
/data/code/uwsgi
.ini && nginx -g
"daemon off;"
|
可以看出,通过ps命令可以查看当前运行的所有进程,该命令同时列出了PID(进程ID),ps命令可通过指定a和u参数u列出所有进程的详细信息
通过fork函数创建进程
1
2
|
#include<unistd.h>
pid_t fork(
void
);
//成功时返回进程ID,失败时返回-1
|
fork函数将创建调用的进程副本,也就是说,并非根据完全不同的程序创建进程,而是复制正在运行的、调用fork函数的进程。另外,两个进程都将执行fork函数调用后的语句(准确地说是在fork函数返回后)。但因为通过同一个进程、复制相同的内存空间,之后的程序流根据fork函数的返回值加以区分。即利用fork函数的如下特点区分程序执行流程:
- 父进程:fork函数返回子进程ID
- 子进程:fork函数返回0
此处,“父进程”指原进程,即调用fork函数的主体,而“子进程”是通过父进程调用fork函数复制出的进程。图1-1展示了调用fork函数后的程序运行流程
图1-1 fork函数的调用
图1-1中可以看到,父进程调用fork函数的同时复制出子进程,并分别得到fork函数的返回值。但复制前,父进程全局变量gval增加到11,将局部变量lval的值增加到25。复制完成后根据fork函数的返回类型区分父子进程,父进程将lval加1,但这不会影响子进程的lval的值。同样,子进程将gval的值加1也不会影响父进程的gval。因为fork函数调用后分成了两个完全不同的进程,只是二者共享同一代码块而已。接下来,我们验证之前所说的内容
fork.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
#include <stdio.h>
#include <unistd.h>
int
gval = 10;
int
main(
int
argc,
char
*argv[])
{
pid_t pid;
int
lval = 20;
gval++, lval += 5;
pid = fork();
if
(pid == 0)
// if Child Process
gval += 2, lval += 2;
else
// if Parent Process
gval -= 2, lval -= 2;
if
(pid == 0)
printf
(
"Child Proc: [%d, %d] \n"
, gval, lval);
else
printf
(
"Parent Proc: [%d, %d] \n"
, gval, lval);
return
0;
}
|
- 第11行:创建子进程,父进程的pid中存有子进程的ID,子进程的pid是0
- 第12、18行:子进程执行这两行代码,因为pid为0
- 第15、20行:父进程执行这两行代码,因为此时pid中存有子进程ID
编译fork.c并运行
1
2
3
4
|
# gcc fork.c -o fork
# ./fork
Parent Proc: [9, 23]
Child Proc: [13, 27]
|
从运行结果可以看出,调用fork函数后,父子进程拥有完全独立的内存结构
进程和僵尸进程
文件操作中,关闭文件和打开文件同等重要。同样,进程销毁也和进程创建同等重要。如果未认真对待进程销毁,它们将变成僵尸进程困扰各位。
僵尸进程
进程完成工作后(执行完main函数中的程序后)应被销毁,但有时这些进程变成僵尸进程,占用系统中的重要资源。这种状态下的进程称作“僵尸进程”,这也是给系统带来负担的原因之一。因此,我们应该消灭这种进程
产生僵尸进程的原因
为了防止僵尸进程的产生,先解释产生僵尸进程的原因。利用如下两个示例展示调用fork函数产生子进程的终止方式:
- 传递参数并调用exit函数
- main函数中执行return并返回值
向exit函数传递的参数值和main函数的return语句返回的值都会传递给操作系统,而操作系统不会销毁子进程,直到把这些值传递给产生该子进程的父进程,处在这种状态下的进程就是僵尸进程。也就是说,将子进程变成僵尸进程的正是操作系统。既然如此,僵尸进程何时被销毁呢?其实之前已给出答案:当子进程将返回值传递给父进程的时候。那么,如何向父进程传递返回值呢?操作系统不会主动把这些值传递给父进程,只有父进程主动发起请求(函数调用)时,操作系统才会传递该值。换言之,如果父进程未主动要求获得子进程的结束状态值,操作系统将一直保存,并让子进程长时间处于僵尸进程状态。接下来的示例将创建僵尸进程
zombie.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
#include <stdio.h>
#include <unistd.h>
int
main(
int
argc,
char
*argv[])
{
pid_t pid = fork();
if
(pid == 0)
// if Child Process
{
puts
(
"Hi I'am a child process"
);
}
else
{
printf
(
"Child Process ID: %d \n"
, pid);
sleep(30);
// Sleep 30 sec.
}
if
(pid == 0)
puts
(
"End child process"
);
else
puts
(
"End parent process"
);
return
0;
}
|
- 第14行:输出子进程ID,可以通过该值查看子进程状态(是否为僵尸进程)
- 第15行:父进程暂停30秒,如果父进程终止,处于僵尸进程状态的子进程将同时销毁。因此,延缓父进程的执行以验证僵尸进程
编译zombie.c并运行
1
2
3
4
5
|
# ./zombie
Child Process ID: 5507
Hi I'am a child process
End child process
End parent process
|
程序开始运行,在打印出子进程的进程ID后,会停歇30秒,这个时候我们可以趁机看一下5507进程号所对应的进程状态
1
2
3
|
# ps -ef | grep 5507
root 5507 5506 0 11:44 pts
/32
00:00:00 [zombie] <defunct>
root 5509 23062 0 11:45 pts
/31
00:00:00
grep
--color=auto 5507
|
可以看到,5507对应的进程号的状态为defunct,即为僵尸进程。经过30秒后,随着父进程的终止,子进程也将销毁
销毁僵尸进程1:利用wait函数
如前所述,为了销毁子进程,父进程应主动请求获取子进程的返回值,接下来讨论下发起请求的具体方法,共有两种,其中之一就是调用wait函数
1
2
|
#include <sys/wait.h>
pid_t wait(
int
*statloc);
//成功时返回终止的子进程ID,失败时返回-1
|
调用次函数时如果已有子进程终止,那么子进程终止时传递的返回值(exit函数的参数值、main函数的return返回值)将保存到该函数的参数所指的内存空间。但函数参数指向的单元中还包含其他信息,因此需要通过下列宏进行分离
- WIFEXITED子进程正常终止时返回真(true)
- WEXITSTATUS返回子进程的返回值
也就是说,向wait函数传递变量status的地址时,调用wait函数后应编写如下代码
1
2
3
4
5
|
if
(WIFEXITED(status))
{
puts
(
"Normal termination!"
);
printf
(
"Child pass num: %d \n"
, WEXITSTATUS(status));
//返回值是多少
}
|
根据上述内容编写示例,此示例中不会再让子进程编程僵尸进程
wait.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
int
main(
int
argc,
char
*argv[])
{
int
status;
pid_t pid = fork();
if
(pid == 0)
{
return
3;
}
else
{
printf
(
"Child PID: %d \n"
, pid);
pid = fork();
if
(pid == 0)
{
exit
(7);
}
else
{
printf
(
"Child PID: %d \n"
, pid);
wait(&status);
if
(WIFEXITED(status))
printf
(
"Child send one: %d \n"
, WEXITSTATUS(status));
wait(&status);
if
(WIFEXITED(status))
printf
(
"Child send two: %d \n"
, WEXITSTATUS(status));
sleep(30);
// Sleep 30 sec.
}
}
return
0;
}
|
- 第9、13行:第9行创建的子进程将在第13行通过main函数中的return语句终止
- 第18、21行:第18行中创建的子进程将在第21行通过调用exit函数终止
- 第26行:调用wait函数,之前终止的子进程相关信息将保存到status变量,同时相关子进程被完全销毁
- 第27、28行:第27行中通过WIFEXITED宏验证子进程是否正常终止,如果正常退出,则调用WEXITSTATUS宏输出子进程的返回值
- 第30~32行:因为之前创建了两个进程,所以再次调用wait函数和宏
- 第33行:为暂停父进程终止而插入的代码,此时可以查看子进程状态
1
2
3
4
5
6
|
# gcc wait.c -o wait
# ./wait
Child PID: 6862
Child PID: 6863
Child send one: 3
Child send two: 7
|
在系统中执行ps命令可以发现,并没有上一个示例中对应PID的进程。这是因为调用了wait函数,完全销毁了子进程,另外两个子进程终止时返回3和7传递给父进程。这就是通过调用wait函数消灭僵尸进程的方法,调用wait函数时,如果没有已终止的子进程,那么程序将阻塞直到有子进程终止,因此需谨慎调用该函数
销毁僵尸进程2:使用waitpid函数
wait函数会引起程序的阻塞,还可以考虑调用waitpid函数,这是防止僵尸进程的第二种方法,也是防止阻塞的方法
1
2
|
#include <sys/wait.h>
pid_t waitpid(pid_t pid,
int
*statloc,
int
options);
//成功时返回终止的子进程ID(或0),失败时返回-1
|
- pid:等待终止的目标子进程的ID,若传递-1,则与wait函数相同,可以等待任意子进程终止
- statloc:与wait函数的statloc具有相同意义
- options:传递头文件sys/wait.h中声明的常量WNOHANG,即使没有终止的子进程也不会进入阻塞状态,而是返回0并退出函数
下面介绍用上述函数的示例,调用waitpid函数,程序不会阻塞
waitpid.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
int
main(
int
argc,
char
*argv[])
{
int
status;
pid_t pid = fork();
if
(pid == 0)
{
sleep(15);
return
24;
}
else
{
while
(!waitpid(-1, &status, WNOHANG))
{
sleep(3);
puts
(
"sleep 3sec."
);
}
if
(WIFEXITED(status))
printf
(
"Child send %d \n"
, WEXITSTATUS(status));
}
return
0;
}
|
- 第12行:调用sleep函数推迟子进程的执行,这会导致程序延迟15秒
- 第17行:while循环调用waitpid函数,向第三个参数传递WNOHANG,因此,若之前没有终止的子进程将返回0
编译waitpid.c并运行
1
2
3
4
5
6
7
8
|
# gcc waitpid.c -o waitpid
# ./waitpid
sleep 3sec.
sleep 3sec.
sleep 3sec.
sleep 3sec.
sleep 3sec.
Child send 24
|
可以看出第20行共执行了五次,另外,也证明waitpid函数并未阻塞
</div>
<div class="postDesc">posted @ <span id="post-date">2018-09-25 20:31</span> <a href="https://www.cnblogs.com/beiluowuzheng/">北洛</a> 阅读(<span id="post_view_count">230</span>) 评论(<span id="post_comment_count">0</span>) <a href="https://i.cnblogs.com/EditPosts.aspx?postid=9689514" rel="nofollow">编辑</a> <a href="#" onclick="AddToWz(9689514);return false;">收藏</a></div>
</div>
<script type="text/javascript">var allowComments=true,cb_blogId=411871,cb_entryId=9689514,cb_blogApp=currentBlogApp,cb_blogUserGuid='b99fbb2a-e185-4a7a-4eef-08d54dba4453',cb_entryCreatedDate='2018/9/25 20:31:00';loadViewCount(cb_entryId);var cb_postType=1;var isMarkdown=false;</script>