1. Netty中的所有IO操作都是异步执行的。
Callback + Furture
2. Netty实际上是使用多线程处理IO事件,多线程编程会有同步的问题,而同步是会影响程序性能的.Netty会保证程序处理事件不会有同步….how? ---- 当用户注册一个channel之后,Netty将这个channel绑定到EventLoop,并且在这个channel的生命周期内始终被绑定,所以一个指定的channel中的所有IO始终都是由同一个线程来执行。
--- 然后channel到底是个啥? 一个客户端的连接就是一个channel么?多个channel对应一个EventLoop么?
按照书上说的,一个EventLoopGroup中有多个EventLoop,每个EventLoop在生命周周期内只和一个Thread绑定(理解为,EventLoop就是一个Thread,是专门用来处理某个事件的),一个Channel只能注册一个EventLoop,反之不对.
所以,一个给定的channel的IO操作都是由相同的Thread执行的,所以不存在同步问题—why?
3. ServerBootstrap用于服务端,Bootstrap是用于客户端.
------前者用来绑定本地端口,后者用来连接远程主机,注意下指定的端口号要相同
------前者有两个EventLoopGroup,后者只有一个。EventLoopGroupA唯一的目的就是接受连接然后交给EventLoopGroupB,用同一个也行
-----一个EventLoopGroup中包含了一个或者多个EventLoop
4. channelpipeline说明
当一个Channel被创建时,会自动分配专属的channelpipeline,channelHandler的执行顺序是由他们添加的顺序决定的,并将数据传递给下一个handler(怎么传递?)
5. channel说明
所有的IO操作都是用channel实现的,每个channel会被分配一个pipeline和一个channelconfig(包含该channel的所有配置) … 为了保证pipeline内部的handler可以按顺序执行,所以channel实现了compare接口(一样会报错)
Zero-copy技术: 仅在NIO &Epoll的时候支持,少了一步从内核空间到用户空间的拷贝 ----要求操作系统要支持
6. ByteBuf说明
可以理解为封装了Java Nio的ByteBuffer类,并在此之上提供了更加多的功能.
Netty的数据容器吧…属于整个channel而不是里面的handler的?
----嗯…说清楚比较难,实际上手就比较好理解了
7. Channel -- handler/pipeline/handlercontext三者之间的关系
在pipeline中add/removehandle或者exceptioncaught调用时,入参都有一个handlercontext.
handlercontext使得handler能够和pipeline以及其他的handler进行交互, handler可以通知其所属的pipeline中的下一个同一超类型的handler,甚至可以修改handler的顺序.(不理解,修改顺序不应该是pipeline修改的么?)
每个handler都有与它相关联的handlercontext,handlercontext主要用于管理它所关联的channelhandler和在同一个pipeline中的其他channelhandler之间的交互!
(P85,多个pipeline中共享同一个handler没看明白—就是单纯的同步问题么?)
8. EventLoop的作用和线程模型
EventLoop接口继承了EventLoopGroup接口, 而后者最上面又继承了Executor接口
Executor.execute(Runablecommand)…. 所以说,一个EventLoop只和一个线程绑定,意思就是对象只能在一个线程中生成呗.
Netty线程模型的卓越性能取决于对于当前执行的Thread的身份的确认。即确定它是否是分配给当前Channel以及它的EventLoop的那一个线程.(这句话如何理解)
---- 个人理解为netty处理的时间并不是一个多任务事件,而是一个单任务事件,一个单线程任务就不会存在多个任务同步的问题– netty所解决的只是如何处理尽可能多的这种单任务事件
9. bootstrap
指的是应用程序对它进行配置,并使它运行起来的过程.
Ps: 多个不同的bootstrap可以共享同一个EventLoopGroup(避免产生额外的线程).比如在实际使用时,你设置的server作为转发服务器时,对于转发的下游,你其实是个client.