Practitioner

但是对于每次服务端的Handler，如果都要加@Sharable，就会非常不好扩展，Netty里面提供了一个没有任何业务功能的并且标注为@Sharable的类:ChannelInitializer, 每个业务handler只需要重写其initChannel()方法即可,我们可以改造一下NettyClientSync和NettyServerSync的代码，并用Netty推荐的写法来修改。Netty+最朴素的阻塞的方式来实现一版客户端和服务端通信的代码，然后再重构成Netty官方推荐的写法。

此外BIO模型还有一个非常严重的问题，因为是阻塞模型，所以客户端在和服务端建立连接后，如果迟迟不发送数据，服务端线程开销花费很多。服务端每次用两端口循环多次去和服务端建立连接，我们可以观察服务端建立连接的速度,通过服务端打印的信息可以感知到连接的速度。的时候，即有新的客户端连接进来，我们把这个client加入到列表中，然后遍历clients，去消费客户端的请求。再次运行客户端，并切换到服务端查看打印日志，速度比前面的BIO快了非常多。问题，即来了多少客户端就启动多少个线程，会导致服务端内存爆掉。

而epoll，可以看成是SELECT和POLL的增强，在调用select/poll时候，都需要把fd集合从用户态拷贝到内核态，但是epoll调用epoll_ctl时拷贝进内核并保存，之后每次epoll_wait不做拷贝，而且epoll采用的是事件通知方式，每当fd就绪，系统注册的回调函数就会被调用，将就绪fd放到rdllist里面。，获取能读写数据的客户端，当客户端数量非常多的时候，服务端要轮询所有连接的客户端拿数据（调用），很多调用是无意义的，这样会导致频繁的用户态切换成内核态，导致性能变差。

mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用。才能做内存映射），即：把内核的pagecache和文件的数据地址空间映射起来。方法，可以修改文件内容的指针，从而可以方便读取和修改文件中的任意位置。通过mmap生成的且是堆外的和文件映射的内存区域。方法就等同于File中的。

allocate分配方式产生的内存开销是在JVM中的，allocateDirect分配方式产生的开销在JVM之外，也就是系统级的内存分配。3、经常复用DirectByteBuffer对象，即经常写入数据到DirectByteBuffer中，然后flip，再读取出来，最后clear，反复使用该DirectByteBuffer对象。所以在创建一个对象的情况下，HeapByteBuffer并没有什么优势，所以，开发中要使用ByteBuffer时，直接用DirectByteBuffer就行了）

启动三个客户端连接这个服务端, 然后再服务端执行netstat -ntap。内核已经为客户端和服务端建立了连接并完成了三次握手，在服务端使用。超过了服务端设置的最大连接数，服务端就不再继续向客户端发送报文。文件描述符6u就对应了服务端和客户端连接的一个Socket。在创建服务端的时候，我们指定了一个参数：backlog=2。服务端收到报文后，向客户端发送确认的报文，服务端进入。在具体的编程中，服务端和客户端都有很多配置的参数。无法执行，即：服务端此时是无法接收客户端的。方法，导致服务端其实没办法执行。

可以用于跟踪和分析进程执行时中系统调用和耗时以及占用cpu的比例。脚本，先停止之前执行的脚本（防止生成文件太多），然后执行。是主线程生成的系统调用，查看这个文件，可以看到，系统调用。常用来跟踪进程执行时的系统调用和所接收的信号。切换成带buffer的执行，大约执行10秒。同时，我们写一个带 buffer 的代码。为主线程的系统调用，打开这个文件可以看到。首先，写一个不带 buffer 的代码。，大大减少了系统调用，所以速度更快。在执行的时候，系统调用的次数。执行大约10秒后，停止执行。

将N个FD分组（这里的FD就是Socket连接），每一组一个selector,将一个selector压到一个线程上（最好的线程数量是: cpu核数或者cpu核数*2)假设有100w个连接，如果有四个线程，那么每个线程处理25w个。考虑有一个fd执行耗时，在一个线性里会阻塞后续FD的处理，同时，考虑资源利用，充分利用cpu核数。其他事件不注册写事件。由于其处理是线性的，且我们要开很多个线程来处理，所以。数组，一个用于分配服务端，一个用于分配每次客户端的。，即我们每次启动的服务端，另外一类就是连接服务端的。