短时间内有大量的客户端的解决方案
创建线程是比较经典的一种服务器开发模型，给每个客户端分配一个线程来提供服务
- 但一旦短时间内有大量的客户端，并且每个客户端请求都是很快的，这个时候对于服务器来说，就会有比较大的压力
- 虽然创建线程比创建进行更轻量，但也架不住短时间内创建销毁大量的线程
所以引入线程池，来解决这样的问题
public void start() throws IOException { System.out.println("启动服务器"); //创建线程池 ExecutorService service = Executors.newCachedThreadPool(); while(true) { //建立连接 Socket clientSocket = serverSocket.accept(); //创建线程，每个线程去服务一个客户端 /*Thread t = new Thread(() -> { try { processConnection(clientSocket); } catch (IOException e) { throw new RuntimeException(e); } }); t.start();*/ //使用线程池 service.submit(() -> { try { processConnection(clientSocket); } catch (IOException e) { throw new RuntimeException(e); } }); } }
晚上 21:00开始比赛，可能就有几百万人涌入直播间
- 这瞬间几百万格客户端就连上服务器了
- 现代的服务器针对上述高并发场景，肯定是分布式（集群）方式来应对
- 一台服务器无论如何也是没法去应对几百万个客户端，所以就引入更多的服务器
线程池
- 客户端发一个请求之后就快速断开连接了
- 线程池解决的是这个问题
- 线程池本质上也是一个线程服务于一个客户端，使用线程池就是在复用线程
- 这样只能避免线程频繁创建和销毁，但如果同时有很多客户端，也需要有很多线程
ExecutorService service = Executors.newCachedThreadPool();
- 此处使用的是这个线程池，他的最大线程数是非常非常大的
- 而
newFixedThreadPool是需要指定最大线程数的，但如果固定线程数，就意味着同时只能处理这么多个客户端
IO 多路复用
- 客户端持续地发送请求处理响应，连接会保持很久
- 这样的场景下，使用多线程/线程池都不合适
- 每个客户端分配一个线程，对于一个系统来说，这里搞几百个线程，压力就非常大了
- 此时一个服务器可能要处理上万个，几十万个客户端
针对这个问题，还有一个方案能解决这个问题，虽然数目非常多，但仍然可以使用较少的线程，提供高效的服务——IO 多路复用
希望在进行网络服务器开发的时候，可以使用更少的线程，处理更多的客户端
- 虽然刚才是一个线程服务于一个客户端，实际上，每个这样的线程都可能会阻塞（客户端也不是持续地发请求的）
- 相比于处理请求的时间，大部分的时间可能都是在阻塞等待
- 如果可以让一个线程给多个客户端提供服务，那就正好了
- 比如给一个线程分配 1000 个客户端进行处理，同一时刻，可能只有几十个客户端需要处理请求
- 针对这样的情况，就需要操作系统内部提供支持了
IO 多路复用，也就是操作系统内核提供的功能（IO 多路复用具体的实现方案有很多种，最知名的就是 Linux 下的 epoll）
- epoll 就是在内核中，搞了一个数据结构，你可以把多个
Socket（每个Socket对应一个客户端）放到这个数据结构里 - 同一时刻，大部分的
Socket都是处于阻塞等待（没有数据需要处理），少数收到数据的Socket，epoll就会通过回调函数的方式，通知应用程序，这里有数据了 - 应用程序，就可以使用少量的线程，针对这里“有数据”的
Socket进行处理即可
比如你今晚，你想吃烧烤，你妈想吃饺子，你爸想吃炒菜
- 你自己去买，先买烧烤，等；再买饺子，等；再买炒菜，等；完成。——>单线程，花的时间是最多的
- 你们三个一起去买，各买各的，分别等；完成——>多线程，花的时间机会缩短很多，等待的时间是三者最大值，系统开销也会更大
- 你自己去买，你先去买烧烤，给老板说“好了叫我”；再去买饺子，给老板说“好了叫我”；再去买炒菜，给老板说“好了叫我”，此时一个线程同时等待三份饭——>IO 多路复用的方案，此时等待的时间相比于多线程方案，相差不大，但是只需要一个线程就可以了
- 最关键的就是老爸能够喊我，哪个客户端来数据了，操作系统就能通知到应用程序
- 服务器开发中最主流的方案，尤其是 IO 多路复用中的
epoll
