1.使用多线程处理高并发的缺点资源消耗（线程本身占用的资源+线程切换带来的系统开销），以及由于硬件和软件的限制，操作系统支持的线程数是有限的，这也抑制了系统的吞吐量。以餐饮为例，吃饭是每个人的事件。他会先看菜单再点菜。就像一个网站会有很多请求，要求服务器做一些事情。我们的服务人员需要处理这些用餐事件。以餐饮为例，多线程处理的方式会是这样的：一个人来吃饭，一个服务员去上菜，然后客人看菜单点菜。服务员将菜单交给厨师。两个人来吃饭，两个服务员来服务……五个??人来吃饭，五个服务员来服务……这就是多线程的处理方式。当一个事件来临时，会有一个线程来服务。显然，这种方式在人少的时候会有很好的用户体验。每位客人都感觉自己是贵宾，并有专人服务。如果餐厅一直这样最多同时接待5位顾客，这家餐厅可以继续很好地服务。有个好消息，因为这家店的服务好，吃的人多了。会同时有10个顾客，老板很开心，但是服务员只有5个，这样无法提供一对一的服务，会留下一些顾客。老板又请了5个服务员，现在好了，大家又可以享受VIP待遇了。越来越多的人对这家餐厅感到满意，顾客也越来越多。同时前来就餐的人数达到了20人。人们不能存钱。我应该怎么办？老板想了想，10个服务员可以接待20个顾客。服务员只需要更加勤奋。服务完一位顾客后，还有时间服务另一位顾客。老板综合考虑后决定使用10个服务人员的线程池~~~但是这种方式有一个严重的缺点，就是如果服务员正在服务的客户点菜速度慢，其他客户可能必须等待很长时间。一些脾气暴躁的客人可能会迫不及待地离开。来，直接上demo代码：编译&运行：然后用浏览器直接访问：http://192.168.1.152:80看运行效果。2.更高效的实施。Reactor模式的老板后来发现客户点餐速度慢，大部分服务员都在等客户点餐。事实上，他们并没有做太多的工作。老板当老板当然有点不一样。我终于找到了一个新的方法，那就是：顾客点餐的时候，服务员可以跟其他顾客打招呼。”，立马就有服务员上菜了。哎，然后老板有了这个新方法之后，裁员了，只剩下一个服务员了！这就是用单线程做多线程，这就是Reactor设计模式，实际的餐厅都是用Reactor模式来服务的，有些设计的模式其实是来自现实生活，Reactor模式主要是为了提高系统的吞吐量，用有限的资源处理更多的事情。在单核机器上，多线程不会提高系统性能，除非发生一些阻塞。否则线程切换的开销会减慢处理速度。就像你自己做两件事，1.削苹果。2.切西瓜。然后你就可以了一个一个的，我觉得你会一个一个的做，如果这个时候你用多线程，一会儿削苹果，一会儿切西瓜，你可以比较一下哪个更快，这就是为什么多线程在单核机器上可能会更慢。Reactor模式Reactor这个词翻译成中文确实没有合适的翻译。很多地方称之为reactormode，但更多的时候好像直接叫做reactormode。事实上，我认为称之为响应者模式更好。通过了解，这个模式更像是守卫，等待你的召唤，或者叫做召唤兽。并发系统往往采用reactor模式来代替常用的多线程处理方式，以节省系统资源，提高系统吞吐量。Reactor模式在Linux系统的高性能编程中对应的实现是Epoll，其工作原理如下：仍然是同步的；2）编程比较简单，可以最大程度避免复杂的多线程和同步问题，避免多线程/进程切换开销；3）可扩展性，通过增加Reactor实例的数量，方便充分利用CPU资源；4）复用性，reactor框架本身与具体的事件处理逻辑无关，复用性高。3.epoll多路复用IO多路复用APIEPOLL1。创建一个EPOLL句柄intepoll_create(intsize);2。添加、修改或删除对EPOLL对象感兴趣的事件3。收集epoll监听的事件中已经发生的事件intepoll_wait(intepfd,structepoll_event*events,intmaxevents,inttimeout)关键结构：4.epoll实例实现实例实现在了解了epoll的工作原理和api之后，我们使用epoll通过以下例程来实现前面的例子：编译运行：
