为什么需要Netty?(一)

为什么需要Netty?

• 假如你的系统要支撑高并发的用户场景，你可能会进行搜索如何搭建高性能的Java网络编程，你可能会看到Netty是一款异步的事件驱动的网络应用程序框架，支持快速地开发可维护的高性能的面向协议的服务器和客户端

• 接着你的下一步多半是阅读一些博客，看一些例子，然后写点代码试试，如果掌握了网络通信编程的技术，遇到的问题可能会少点，否则你可能看不懂在说些什么

• 高性能系统不仅要求超一流的编程技巧，还需要几个复杂领域(网络编程、多线程处理和并发)的专业知识，Netty优雅地处理了这些领域的知识，使得我们可以将精力放在业务处理上，而不是关注网络编程方便的非业务逻辑

• Netty的架构方法和设计原则是:每个小点都和它的技术性内容一样重要，穷其精妙。
  1.关注点分离——业务和网络逻辑解耦
  2.模块化和可复用性
  3.可测试性作为首要的要求

• 早期的网络编程中，需要花费大量的事件取学习复杂的C语言套接字库，去兼容不同的操作系统。尽管Java引入了足够多的Socket Facade(门面)来隐藏一些棘手的细节问题，但是创建一个复杂的客户端/服务端协议仍然需要大量的样板代码(以及相当多的底层研究才能使它整个流畅地运行起来)

package esay;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;

/**
 * @author xieh
 * @date 2024/02/01 22:56
 */
public class JavaBIOExapmle {

    public static void main(String[] args) throws IOException {
        // 创建一个新的ServerSocket，用以监听指定端口上的连接请求，
        ServerSocket serverSocket = new ServerSocket(2222);
        // 对accept()方法的调用将被阻塞，直到一个连接建立
        Socket clientSocket = serverSocket.accept();
        // 这些流对象都派生于该套接字的流对象
        BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));

        PrintWriter out = new PrintWriter(clientSocket.getOutputStream());

        String request = null;
        String response = null;
        // 处理循环开始
        while ((request = in.readLine()) != null) {
            // 如果客户端发送了Done则退出处理循环
            if ("Done".equals(request)) {
                break;
            }

            // 请求被传递给服务器的处理方法
            response = processRequest(request);
            // 服务器的响应被发送给了客户端
            out.println(response);
            // 继续执行处理循环
        }
    }

    private static String processRequest(String request) {
        return null;
    }

}

• 最早期地Java API(java.net)只支持本地系统套接字库提供地所谓地阻塞函数BIO
  这段代码片段只能同时处理一个链接，要管理多个并发客户端，需要为每个新的客户端Socket创建一个新的Thread,这种方案的影响

1.在任何时候都可能有大量的线程处于休眠状态，只是等待输入或者输出数据就绪，这可能算是一种资源浪费。

2.需要为每个线程的调用栈都分配内存，其默认值大小区间为64kb-1mb

3.即使JVM可以在物理上支持非常大的数量，但是远在到达该极限之前，上下文切换所带来的开销就会带来麻烦

这种并发方案对于支撑中小数量的客户端来说还算可以接收，但是为了支撑100 0000或者更多的并发连接所需要的资源会使得它很不理想