服务器，使用多进程 与 多线程 请问有什么区别

关于多进程和多线程，教科书上最经典的一句话是“进程是资源分配的最小单位，线程是CPU调度的最小单位”，这句话应付考试基本上够了，但如果在工作中遇到类似的选择问题，那就没有这么简单了，选的不好，会让你深受其害。

经常在网络上看到有的XDJM问“多进程好还是多线程好？”、“Linux下用多进程还是多线程？”等等期望一劳永逸的问题，我只能说：没有最好，只有更好。根据实际情况来判断，哪个更加合适就是哪个好。

我们按照多个不同的维度，来看看多线程和多进程的对比（注：因为是感性的比较，因此都是相对的，不是说一个好得不得了，另外一个差的无法忍受）。

适应于多核、多机分布式；如果一台机器不够，扩展到多台机器比较简单

适应于多核分布式

进程占优

1）需要频繁创建销毁的优先用线程

原因请看上面的对比。

这种原则最常见的应用就是Web服务器了，来一个连接建立一个线程，断了就销毁线程，要是用进程，创建和销毁的代价是很难承受的

2）需要进行大量计算的优先使用线程

所谓大量计算，当然就是要耗费很多CPU，切换频繁了，这种情况下线程是最合适的。

这种原则最常见的是图像处理、算法处理。

3）强相关的处理用线程，弱相关的处理用进程

什么叫强相关、弱相关？理论上很难定义，给个简单的例子就明白了。

一般的Server需要完成如下任务：消息收发、消息处理。“消息收发”和“消息处理”就是弱相关的任务，而“消息处理”里面可能又分为“消息解码”、“业务处理”，这两个任务相对来说相关性就要强多了。因此“消息收发”和“消息处理”可以分进程设计，“消息解码”、“业务处理”可以分线程设计。

当然这种划分方式不是一成不变的，也可以根据实际情况进行调整。

4）可能要扩展到多机分布的用进程，多核分布的用线程

原因请看上面对比。

5）都满足需求的情况下，用你最熟悉、最拿手的方式

至于“数据共享、同步”、“编程、调试”、“可靠性”这几个维度的所谓的“复杂、简单”应该怎么取舍，我只能说：没有明确的选择方法。但我可以告诉你一个选择原则：如果多进程和多线程都能够满足要求，那么选择你最熟悉、最拿手的那个。

需要提醒的是：虽然我给了这么多的选择原则，但实际应用中基本上都是“进程+线程”的结合方式，千万不要真的陷入一种非此即彼的误区。

消耗资源：

从内核的观点看，进程的目的就是担当分配系统资源（CPU时间、内存等）的基本单位。线程是进程的一个执行流，是CPU调度和分派的基本单位，它是比进程更小的能独立运行的基本单位。

线程，它们彼此之间使用相同的地址空间，共享大部分数据，启动一个线程所花费的空间远远小于启动一个进程所花费的空间，而且，线程间彼此切换所需的时间也远远小于进程间切换所需要的时间。据统计，总的说来，一个进程的开销大约是一个线程开销的30倍左右，当然，在具体的系统上，这个数据可能会有较大的区别。

通讯方式：

进程之间传递数据只能是通过通讯的方式，即费时又不方便。线程时间数据大部分共享（线程函数内部不共享），快捷方便。但是数据同步需要锁对于static变量尤其注意

线程自身优势：

提高应用程序响应；使多CPU系统更加有效。操作系统会保证当线程数不大于CPU数目时，不同的线程运行于不同的CPU上；

改善程序结构。一个既长又复杂的进程可以考虑分为多个线程，成为几个独立或半独立的运行部分，这样的程序会利于理解和修改。

逻辑上实现了http协议、管理web资源、负责提供web服务器的管理功能。

Web服务器逻辑和操作系统共同管理TCP连接。

Apache 就是 开源的 软件web 服务器的一种。

一旦连接建立起来并被接受，服务器会将新连接添加到其现存的web服务器连接列表中，做好监视连接上数据传输的设备。

可以用反向DNS对大部分web服务器进行配置，以便将客户端IP地址转换成 客户端 主机名。

好处: web服务器可以将客户端主机名用于详细的访问控制和日志记录。

坏处:主机名查找可能会花费很长时间，要么只允许特定内容进行解析。

有些web服务器还支持ident 协议。服务器可以通过ident协议找到发起http连接的 用户名 。对记录日志非常有用。

类似这种。

如果客户端支持ident协议，就在tcp端口113上监听 ident请求。

但ident在公共因特网上不能很好的使用

解析请求报文时，web服务器会不定期从网络上接受输入数据。网络连接可能随时都会出现延迟。web服务器从网络中读取数据，将部分报文数据临时存储在内存中，直到收到足以进行解析的数据并理解其意义为止。

web服务器对报文解析后，并用自己内部的数据结构来存储请求报文。

请求可能会在任意时刻到达，所以web服务器不停观察有无新的web请求。不同的web服务器会以不同的方式为请求服务。

单线程的服务器一次只处理一个请求。一个事务处理结束后，才会去处理下一条连接。

结构容易实现，单性能很差。

多进程和多线程服务器用多个进程或更高效的现成同时对请求进行处理。

可以根据需要创建，或者预先创建一些线程/进程。有些服务器会为每条连接分配一个线程/进程，但当服务器同时要处理成百上千甚至上万的连接时，需要的继承或者线程数量可能会消耗太多内存或系统资源。(预先分配 线程池，进程池，内存池等手段)

因此这类服务器会对线程/进程的最大数量进行限制

线程与复用功能结合，利用计算机平台上多个CPU。多个线程中的每一个都在观察打开的连接。并对每条连接执行少量任务。

收到并解析请求后，可以根据方法、资源、首部和可选的主体部分对请求进行业务处理。

在web服务器将内容传送给客户端之前，要将请求 报文中的URI映射为web服务器上适当的内容或内容生成器，以识别出内容的源头。

请求URI 作为名字 来 访问 Web 服务器文件系统中的文件。通常web 服务器的文件系统中会有一个特殊的文件夹专门用于存放web内容。

即文档的 根目录 。

同时服务器也需要注意，不能让URL退到docroot之外，将文件系统的其余部分暴露出来。不允许这样的uri出现：

web服务器可以接受收对目录url的请求，其路径可以解析为一个目录。而不是文件。我们可以对大多数web服务器进行配置。使其在客户端请求目录url时 采取不同的动作。

大多数web服务器都会去查找目录中的一个名为indexhtml 的文件来替代此目录。

如果用户请求的时一个目录的url，并且这个目录中有一个名为indexhtml 的文件。服务器就会返回这个文件。

Web 服务器还可以将URI映射为动态资源，也就是说，映射到按需动态生成内容的程序上去。

实际上，有一大类名为应用程序服务器的Web 服务器会将Web服务器连接到复杂的后端应用上去。

Web 服务器主要做的事：

也就是说 web服务器会将URI路径名 映射为 可执行文件目录 。

服务器端包含项（SSI），如果某个资源被表示为存在服务器端包含想，服务器会在将其发送给客户端之前对资源内容进行处理。

web 服务器还可以为特定资源进行访问控制，有请求到达，要访问受控制资源时，服务器可以根据客户的ip地址进行访问控制，比如输入密码才能访问。

如果事务处理产生了响应 主体，就将内容放在响应报文中发回去。实体包括：

服务器要负责确定响应主体的MIME类型。有很多配置服务器的方法可以将MIME类型与资源关联起来。

Web 服务器有时会返回重定向响应而不是成功的报文。Web服务器可以将浏览器重定向到其他地方执行请求。

重定向返回码 3XX。Location响应首部包含了内容的新地址。

对于非持久连接而言，服务器应该发送了整条报文后，关闭自己一端。

对于持久而言，连接仍然可以保持打开状态。这种情况下服务器端要正确的计算content length，不然客户端无法知道响应何时结束。

当事务结束时，web服务器会在日志文件中添加一跳目录，来描述已执行的事务。

1，进程：子进程是父进程的复制品。子进程获得父进程数据空间、堆和栈的复制品。

2，线程：相对与进程而言，线程是一个更加接近与执行体的概念，它可以与同进程的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。

两者都可以提高程序的并发度，提高程序运行效率和响应时间。

线程和进程在使用上各有优缺点：线程执行开销小，但不利于资源管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。

答案二:

根本区别就一点：用多进程每个进程有自己的地址空间(address space)，线程则共享地址空间。所有其它区别都是由此而来的：

1。速度：线程产生的速度快，线程间的通讯快、切换快等，因为他们在同一个地址空间内。

2。资源利用率：线程的资源利用率比较好也是因为他们在同一个地址空间内。

3。同步问题：线程使用公共变量/内存时需要使用同步机制还是因为他们在同一个地址空间内。

网上的答案的 版本怎么想怎么都太学术了。我当时看到过一个比喻特别的好， 我就模仿者把它说下来哈，有错误希望支持哈：

多进程的服务器就好比是

立体的交通系统（立交桥）虽然说建造的时候花费比较大，消耗的资源比较多，但是真要是跑起来不会交通堵塞。但是汽车在上面跑，相互通信就是个很费事儿问题（进程间通信比较麻烦）；多线程就好比是平面的交通系统，造价低，但是很容易交通堵塞，

但是也有好处同步的时候方便。

在网络服务器方面：

单进程 < 多进程(单线程)< 多进程（多线程）

在游戏方面的应用：

I、多线程服务器，玩家数据缓存和向DB的存储我们可以开一个线程单独去做，这样不会有什么大的问题。日志和网络上面说过可以很容易切割出去，主要就是对游戏逻辑的切割。

A：按场景分线程，一个线程管理若干个场景。这样配置灵活，一个线程可以管理若干个小场影，除非有个场景人多到一个CPU跑不下来，一般的游戏都会满足需求。缺点则是不在同一线程的Object在做逻辑交互时，必须用异步，如果用到了脚本，那么这里的复杂度和性能要值得注意。如果项目中出现单个服务器解决不鸟的问题(例如战场服务器)，似乎就成了多线程多进程的庞大架构。

B：将某些功能切割到其它线程，例如Object的管理和查找，NPCAI的寻路，这种方式貌似在做逻辑需要分离到别的线程模块功能时有点麻烦，如果直接上锁等待肯定不是最好的方式,所以这些逻辑必须变成异步。

2、多进程服务器,其实这里的多进程和场景多线程改成了多进程。这里玩家数据缓存和向DB的存储我觉得用一个单独的DB服务器。多进程服务器可以在GameServer和GameClient之间加一个Gate，因为在跨服场景不需频繁断线连接。多进程服务器所有的通讯都依靠网络，有些逻辑必须有网络延迟的消耗。优点是配置灵活，在物理机器性能不够时可以通过扩充物理机器来解决

服务器还有有一个很蛋疼的问题就是过载： 下面介绍一下产生的原因和解决办法：

服务器过载：

原因是高优先级处理阶段对CPU的不公平抢占。所以，如果限制高优先级处理阶段对CPU的占用率，或者限制处理高优先级的CPU个数，都可以减轻或者消除收包活锁现象。具体的可以采用以下的方法：

方法一、采用轮询机制

为了减少中断对系统性能的影响，在负载正常的情况下采用“下半处理”的方法就非常有效，而在高负荷情况下，采用这个方法仍然会造成活锁现象，这时可以采用轮询机制。虽然这个方法在负载正常的情况下会造成资源的浪费和响应速度降低，但在网络数据频繁到达服务器时就要比中断驱动技术有效的多。

方法二、减低中断的频率

这里主要有两种方法：批中断和暂时关闭中断。批中断可以在超载时有效的抑制活锁现象，但对服务器的性能没有什么根本性的改进;当系统出现接收活锁迹象时，可以采用暂时关闭中断的方法来缓和系统的负担，当系统缓存再次可用时可以再打开中断，但这种方法在接收缓存不够大的情况下会造成数据包丢失。

方法三、减少上下文切换

这种方法不管服务器在什么情况下对性能改善都很有效，这时可以采用引入核心级(kerne1—leve1)或硬件级数据流的方法来达到这个目的。核心级数据流是将数据从源通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程中因为数据在内存中，因此需要CPU操作数据。

硬件级数据流则是将数据从源通过私有数据总线或是虽等DMA通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程不需要CPU操作数据。这样在数据传输过程中不需要用户线程的介入，减少了数据被拷贝的次数，减少了上下文切换的开销。

任何一项技术的出现都是为了解决现有问题。

之前的互联网大多是单机服务，体量小。而现在的更多是集群服务，同一时刻有多个用户同时访问服务器，那么就会有很多线程并发访问。

比如，常见的电商系统场景，同一时刻比如整点抢购时，会有海量用户同时访问服务器。

如果不使用多线程处理，那基本凉凉……

所以现在公司里开发基本都是多线程的。使用多线程确实提高了运行的效率。

但与此同时，也会伴随着一些问题出现，让人很头痛。

比如，需要特别注意数据的增删改情况，也就是线程安全问题。

想要保证线程安全也有很多方式，比如说：加锁。

但是，又可能会出现其他问题，比如：死锁，所以多线程相关问题会比较麻烦。

面试官现在也非常喜欢拿多线程来考你，比如：

产生死锁的条件是什么，怎么解决死锁？

乐观锁和悲观锁如何实现，有哪些实现方式？

非公平锁和公平锁在ReentrantLock中的实现？

Lock 和 synchronized 有什么区别？

ReentrantLock和synchronized如何选择？

如今多线程在面试中已经是常客了，同时也是我们必备的知识点。

因此，我们需要理解多线程的原理和它可能会产生的问题以及如何解决问题，才能拿下高薪职位。

相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。 关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 libev 事件驱动库的服务器模型将给出实现代码。 本文涉及到线程 / 时间图例，只为表明线程在各个 IO 上确实存在阻塞时延，但并不保证时延比例的正确性和 IO 执行先后的正确性；另外，本文所提及到的接口也只是笔者熟悉的 Unix/Linux 接口，并未推荐 Windows 接口，读者可以自行查阅对应的 Windows 接口。阻塞型的网络编程接口几乎所有的程序员第一次接触到的网络编程都是从 listen()、send()、recv()等接口开始的。使用这些接口可以很方便的构建服务器 /客户机的模型。我们假设希望建立一个简单的服务器程序，实现向单个客户机提供类似于“一问一答”的内容服务。图1 简单的一问一答的服务器 /客户机模型我们注意到，大部分的 socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是 IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。实际上，除非特别指定，几乎所有的 IO接口 (包括 socket 接口 )都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。这时，很多程序员可能会选择多线程的方式来解决这个问题。多线程服务器程序 应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。 具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。 我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。图2 多线程服务器模型 在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。 很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型： int accept(int s, struct sockaddr addr, socklen_t addrlen); 输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。 上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。 但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。 对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。 总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。下一章我们将讨论用非阻塞接口来尝试解决这个问题。使用select()接口的基于事件驱动的服务器模型 大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型： FD_ZERO(int fd, fd_set fds) FD_SET(int fd, fd_set fds) FD_ISSET(int fd, fd_set fds) FD_CLR(int fd, fd_set fds) int select(int nfds, fd_set readfds, fd_set writefds, fd_set exceptfds, struct timeval timeout) 这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该“可读”事件是否发生。另外，用户可以设置 timeout 时间。 下面将重新模拟上例中从多个客户端接收数据的模型。图4使用select()的接收数据模型 上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。图5使用select()接口的基于事件驱动的服务器模型 这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。 上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误事件”的句柄 ( 使用 FD_SET() 标记 )。 作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用 FD_ISSET() 检查 )，以确定到底哪些句柄发生了事件。 上述模型主要模拟的是“一问一答”的服务流程，所以，如果 select() 发现某句柄捕捉到了“可读事件”，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的“可写事件”的 select() 探测。同样，如果 select() 发现某句柄捕捉到“可写事件”，则程序应及时做 send() 操作，并准备好下一次的“可读事件”探测准备。下图描述的是上述模型中的一个执行周期。图6 一个执行周期 这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。 相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。 但这个模型依旧有着很多问题。 首先，select() 接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。 其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。图7 庞大的执行体对使用select()的事件驱动模型的影响 幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。使用事件驱动库libev的服务器模型 Libev 是一种高性能事件循环 / 事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。 （事实上，现存的事件循环 / 事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。） 与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。 void ev_loop( ev_loop loop, int flags ) Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化： void ev_io_init(ev_io io, callback, int fd, int events) 初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表“可读事件”，EV_WRITE 表“可写事件”。 现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。 无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。 void ev_io_start( ev_loop loop, ev_io io ) void ev_io_stop( EV_A_ ) 由此，我们可以容易得出如下的“一问一答”的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。图8 使用libev库的服务器模型 上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环 / 事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。 由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有“一问一答”的通讯逻辑，所以上述使用 libev 库的“一问一答”模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。 总结 本文围绕如何构建一个提供“一问一答”的服务器程序，先后讨论了用阻塞型的 socket 接口实现的模型，使用多线程的模型，使用 select() 接口的基于事件驱动的服务器模型，直到使用 libev 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用“事件驱动模型”可以的实现更为高效稳定的服务器程序。文中描述的多种模型可以为读者的网络编程提供参考价值。

thread_return指向某存储线程返回值的变量。

倘若线程返回值是一个字符串。我们当然可以用一个指针void thread_return 搞定。

但如果有多个返回值或者返回的是一个结构体，那么void thread_return就不能满足需要了。所以需要用void thread_return。

供参考，非权威解释。

服务器端：

import javaawt;

import javaawtevent;

import javaxswing;

import javaio;

import javanet;

import javautilVector;

public class OneToMoreServer extends JFrame implements ActionListener{

JPanel contentPane;

JLabel jLabel2 = new JLabel();

JTextField jTextField2 = new JTextField("4700");

JButton jButton1 = new JButton();

JLabel jLabel3 = new JLabel();

JTextField jTextField3 = new JTextField();

JButton jButton2 = new JButton();

JScrollPane jScrollPane1 = new JScrollPane();

JTextArea jTextArea1 = new JTextArea();

ServerSocket server = null;

Socket socket = null;BufferedReader instr =null;PrintWriter os=null ;

Vector vector=new Vector();

boolean serverRun=true;

boolean clientRun=true;

//Construct the frame

public OneToMoreServer() {

jbInit();

}

class MyThread extends Thread{//该线程负责接收数据

Socket socketI=null;

BufferedReader br=null;

public MyThread(Socket socket)

{

socketI=socket;

}

public void run(){

try{

while(clientRun){

thissleep(100);

br= new BufferedReader(new InputStreamReader(socketIgetInputStream()));

if(brready()){ //检查是否有数据

jTextArea1append("接收到来自客户端("+socketIgetInetAddress()toString()+")的消息: "+brreadLine()+"\n");

}

}

}catch(Exception ex){JOptionPaneshowMessageDialog(null,extoString());}

}

}

public void actionPerformed(ActionEvent e){

if(egetSource()==jButton1){

int port=IntegerparseInt(jTextField2getText()trim());

//监听指定端口

try

{

server = new ServerSocket(port);

new Thread(new ListenClient())start();

}

catch(IOException ex)

{

JOptionPaneshowMessageDialog(null,extoString());

}

}

if(egetSource()==jButton2){

String msg=jTextField3getText()trim();

if(msglength()!=0)

sendData("hello");

}

}

//该线程负责监听指定端口

class ListenClient implements Runnable

{

public void run()

{

try{

if(jButton1getText()trim()equals("侦听")){

jButton1setText("正在侦听");

while(serverRun)

{

Socket socketI=serveraccept();//有客户端连入时建立一个线程监听客户端发送的消息

vectoradd(socketI);

jButton1setText("正在聊天");

jTextArea1append("客户端"+socketIgetInetAddress()toString()+"已经连接到服务器\n");

MyThread t=new MyThread(socketI);

tstart();

}

}

}catch(Exception ex){

JOptionPaneshowMessageDialog(null,extoString());

}

}

}

private void sendData(String s){//发送数据

try{

for(int i=0;i<vectorsize();i++)

{

//怎么广播

//向每个客户端发送一条消息

Socket socket=(Socket)vectorget(i);

os= new PrintWriter(socketgetOutputStream());

osprintln(s);

osflush();

}

}catch(Exception ex){

}

}

private void jbInit() {

contentPane = (JPanel) thisgetContentPane();

contentPanesetLayout(null);

thissetSize(new Dimension(540, 340));

thissetTitle("服务器");

jLabel2setBounds(new Rectangle(22, 27, 72, 28));

jLabel2setText("端口号");

jLabel2setFont(new javaawtFont("宋体", 0, 14));

jTextField2setBounds(new Rectangle(113, 27, 315, 24));

jButton1setBounds(new Rectangle(440, 28, 73, 25));

jButton1setFont(new javaawtFont("Dialog", 0, 14));

jButton1setBorder(BorderFactorycreateEtchedBorder());

jButton1setActionCommand("jButton1");

jButton1setText("侦听");

jLabel3setBounds(new Rectangle(23, 57, 87, 28));

jLabel3setText("请输入信息");

jLabel3setFont(new javaawtFont("宋体", 0, 14));

jTextField3setBounds(new Rectangle(114, 60, 314, 24));

jTextField3setText("");

jButton2setText("广播");

jButton2setActionCommand("jButton1");

jButton2setBorder(BorderFactorycreateEtchedBorder());

jButton2setFont(new javaawtFont("Dialog", 0, 14));

jButton2setBounds(new Rectangle(440, 58, 73, 25));

jScrollPane1setBounds(new Rectangle(23, 92, 493, 189));

contentPaneadd(jTextField2, null);

contentPaneadd(jButton1, null);

contentPaneadd(jLabel3, null);

contentPaneadd(jTextField3, null);

contentPaneadd(jButton2, null);

contentPaneadd(jScrollPane1, null);

contentPaneadd(jLabel2, null);

jScrollPane1getViewport()add(jTextArea1, null);

jButton1addActionListener(this);

jButton2addActionListener(this);

thisaddWindowListener(new WindowAdapter(){

public void windowClosing(WindowEvent e){

try{

socketclose();

instrclose();

Systemexit(0);

}catch(Exception ex){

//JOptionPaneshowMessageDialog(null,extoString());

}

}

});

}

public static void main(String arg[]){

JFramesetDefaultLookAndFeelDecorated(true);

OneToMoreServer frm=new OneToMoreServer();

frmsetDefaultCloseOperation(JFrameEXIT_ON_CLOSE);

frmsetVisible(true);

}

}

客户端

import javaawt;

import javaawtevent;

import javaxswing;

import javaio;

import javanet;

public class Client extends JFrame implements ActionListener{

JPanel contentPane;

JLabel jLabel1 = new JLabel();

JTextField jTextField1 = new JTextField("127001");

JLabel jLabel2 = new JLabel();

JTextField jTextField2 = new JTextField("4700");

JButton jButton1 = new JButton();

JLabel jLabel3 = new JLabel();

JTextField jTextField3 = new JTextField();

JButton jButton2 = new JButton();

JScrollPane jScrollPane1 = new JScrollPane();

JTextArea jTextArea1 = new JTextArea();

BufferedReader instr =null;

Socket socket = null;

PrintWriter os=null;

public Client() {

jbInit();

}

class MyThread extends Thread{

public void run(){

try{

os=new PrintWriter(socketgetOutputStream());

instr=new BufferedReader(new InputStreamReader(socketgetInputStream()));

while(true)

{

thissleep(100);

if(instrready())

{

jTextArea1append("接收到来自服务器的消息: "+instrreadLine()+"\n");

}

}

}catch(Exception ex){

JOptionPaneshowMessageDialog(null,extoString());

}

}

}

public void actionPerformed(ActionEvent e){

if(egetSource()==jButton1){

String ip=jTextField3getText()trim();

int port=IntegerparseInt(jTextField2getText()trim());

connectServer(ip,port);

}

if(egetSource()==jButton2){

String s=thisjTextField3getText()trim();

sendData(s);

}

}

private void connectServer(String ip,int port){//连接

try{

if(jButton1getText()trim()equals("连接")){

jButton1setText("连接服务器");

socket=new Socket(ip,port);

jButton1setText("正在聊天");

MyThread t=new MyThread();

tstart();

}

}catch(Exception ex){

JOptionPaneshowMessageDialog(this,extoString());

}

}

private void sendData(String s){//发送数据

try{

os = new PrintWriter(socketgetOutputStream());

osprintln(s);

osflush();

thisjTextArea1append("向服务器发送消息:"+s+"\n");

}catch(Exception ex){

JOptionPaneshowMessageDialog(this,extoString());

}

}

private void jbInit() {

contentPane = (JPanel) thisgetContentPane();

jLabel1setFont(new javaawtFont("宋体", 0, 14));

jLabel1setText("服务器名称");

jLabel1setBounds(new Rectangle(20, 22, 87, 28));

contentPanesetLayout(null);

thissetSize(new Dimension(540, 340));

thissetTitle("客户端");

jTextField1setBounds(new Rectangle(114, 26, 108, 24));

jLabel2setBounds(new Rectangle(250, 25, 72, 28));

jLabel2setText("端口号");

jLabel2setFont(new javaawtFont("宋体", 0, 14));

jTextField2setBounds(new Rectangle(320, 27, 108, 24));

jButton1setBounds(new Rectangle(440, 28, 73, 25));

jButton1setFont(new javaawtFont("Dialog", 0, 14));

jButton1setBorder(BorderFactorycreateEtchedBorder());

jButton1setActionCommand("jButton1");

jButton1setText("连接");

jLabel3setBounds(new Rectangle(23, 57, 87, 28));

jLabel3setText("请输入信息");

jLabel3setFont(new javaawtFont("宋体", 0, 14));

jTextField3setBounds(new Rectangle(114, 60, 314, 24));

jButton2setText("发送");

jButton2setActionCommand("jButton1");

jButton2setBorder(BorderFactorycreateEtchedBorder());

jButton2setFont(new javaawtFont("Dialog", 0, 14));

jButton2setBounds(new Rectangle(440, 58, 73, 25));

jScrollPane1setBounds(new Rectangle(23, 92, 493, 189));

contentPaneadd(jLabel1, null);

contentPaneadd(jTextField1, null);

contentPaneadd(jLabel2, null);

contentPaneadd(jTextField2, null);

contentPaneadd(jButton1, null);

contentPaneadd(jLabel3, null);

contentPaneadd(jTextField3, null);

contentPaneadd(jButton2, null);

contentPaneadd(jScrollPane1, null);

jScrollPane1getViewport()add(jTextArea1, null);

jButton1addActionListener(this);

jButton2addActionListener(this);

thisaddWindowListener(new WindowAdapter(){

public void windowClosing(WindowEvent e){

try{

socketclose();instrclose();osclose();Systemexit(0);

}catch(Exception ex){

JOptionPaneshowMessageDialog(null,extoString());

}

}

});

}

public static void main(String arg[]){

JFramesetDefaultLookAndFeelDecorated(true);

Client frm=new Client();

frmsetVisible(true);

}

}