跟闪电侠学Netty：Netty 即时聊天实战与底层原理

基本上写了个大概，要深入还是需要看一遍源码，自己调调看

一本比较好的netty入门资料

通俗易懂，配上关键代码讲解，一目了然，对netty的基础使用有了一定的了解，结合实践，相信一定可以很快的熟练使用

首先刚开始NettyClient 源码中的connect方法就因为retry不是最终变量报错了 作为一本已经出版的书籍 源代码没有普适性 已经没有想跟着敲下去想法了

完全是 Netty api 介绍 ，和网络编程相关的底层原理基本没有

在传统的IO模型中，每个连接创建成功之后都需要由一个线程来维护，每个线程都包含一个while死循环，那么1万个连接对应1万个线程，继而有1万个while死循环，这就带来如下几个问题：1.线程资源受限：线程是操作系统中非常宝贵的资源，同一时刻有大量的线程处于阻塞状态，是非常严重的资源浪费，操作系统耗不起。2.线程切换效率低下：单机CPU核数固定，线程爆炸之后操作系统频繁进行线程切换，应用性能急剧下降。3.除了以上两个问题，在IO编程中，我们看到数据读写是以字节流为单位的。 为了解决这3个问题，JDK在1.4版本之后提出了NIO。 ◆ 而在NIO模型中，这么多while死循环转换为一个死循环，这个死循环由一个线程控制，那么NIO又是如何做到一个线程一个while死循环就能监测1万个连接是否有数据可读的呢？ ◆ 这就是NIO模型中Selector的作用，一个连接来了之后，不会创建一个while死循环去监听是否有数据可读，而是直接把这条连接注册到Selector上。 ◆ IO读写是面向流的，一次性只能从流中读取一字节或者多字节，并且读完之后流无法再读取，需要自己缓存数据。而NIO的读写是面向Buffer的，可以随意读取里面任何字节数据，不需要自己缓存数据，只需要移动读写指针即可。 我们还是先对照NIO来解释一下核心思路。1.NIO模型中通常会有两个线程，每个线程都绑定一个轮询器Selector。在这个例子中，serverSelector负责轮询是否有新连接，clientSelector负责轮询连接是否有数据可读。2.服务端监测到新连接之后，不再创建一个新线程，而是直接将新连接绑定到clientSelector上，这样就不用IO模型中的1万个while循环死等。3.clientSelector被一个while死循环包裹着，如果在某一时刻有多个连接有数据可读，那么通过clientSelector.select(1)方法可以轮询出来，进而批量处理。4.数据的读写面向Buffer。 总之，强烈不建议直接基于JDK原生NIO来进行网络开发，下面是笔者总结的原因。1.JDK的NIO编程需要了解很多概念，编程复杂，对NIO入门非常不友好，编程模型不友好，ByteBuffer的API简直“反人类”。2.对NIO编程来说，一个比较合适的线程模型能充分发挥它的优势，而JDK没有实现，需要自己实现，就连简单的自定义协议拆包都要自己实现。3.JDK的NIO底层由Epoll实现，该实现饱受诟病的空轮询Bug会导致CPU占用率飙升至100%。4.项目庞大之后，自行实现的NIO很容易出现各类Bug，维护成本较高，上面这些代码笔者都不能保证没有Bug。 下面是笔者总结的使用Netty而不使用JDK原生NIO的原因。1.使用JDK原生NIO需要了解太多概念，编程复杂，一不小心就Bug横飞。2.Netty底层IO模型随意切换，而这一切只需要做微小的改动，改改参数，Netty可以直接从NIO模型变身为IO模型。3.Netty自带的拆包/粘包、异常检测等机制让你从NIO的繁重细节中脱离出来，只需要关心业务逻辑即可。4.Netty解决了JDK很多包括空轮询在内的Bug。5.Netty底层对线程、Selector做了很多细小的优化，精心设计的Reactor线程模型可以做到非常高效的并发处理。6.自带各种协议栈，让你处理任何一种通用协议都几乎不用亲自动手。7.Netty社区活跃，遇到问题随时邮件列表或者Issue。8.Netty已经历各大RPC框架、消息中间件、分布式通信中间件线上的广泛验证，健壮性无比强大。

很一般，基本就是api的使用讲解。

由浅入深，结合实际案例，一步一步带领读者了解并使用 netty，后面又深入分析了 netty 的整体架构和源码，读完整体感觉是：不会觉得太吃力，也不会觉得过于简单，适合入门者，也适合想要深入学习的。对于想学习、使用 netty 的读者来说，这是一本不可多得的好书，

难以置信一本出版书籍的代码错误百出，豆瓣评分9.7你也是敢刷

在学城找到了系列文章，目前看完了前7讲。对入门者来说挺友好的。