Netty进阶学习（一）：学习一个新技术的大致思路是什么？

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第22天，点击查看活动详情。

背景

1. 任何一件事，先去尽可能搜寻资料，分析一下，然后多想想，千万别这里试一下，那里试一下。

2. 如何学习一门新的技术？这里的新技术是指Java生态系统的框架技术，比如Netty，Springboot, Corda之类的。不具体指什么编程语言。不过，我倒是觉得，当学习一门编程语言的时候，直接上手一个用此编程语言写的框架就行了。但是，这也只是学一些，基本的语法和稍微高阶一点儿的知识。从了解的角度来说，是可以的；从构建项目，解决问题的角度来说，是不可行的，还有很长的路。因为任何一门编程语言，不是那点儿语法知识呀。

过程

1. 寻找官网，了解大致架构及其概念设计。Netty官网 一开始，概念的理解是非常难的，因为全是这个框架定义的概念，只是在这个框架中表达了此含义。大的架构组件上的概念是需要记住的。核心层是哪些组件，传输层是哪些，协议层支持哪些。

2. 在githup上寻找源码，并clone下来。大致浏览一下wiki，阅读README.md的简短说明。Netty源码

3. 查看源码大致的目录结构，找到一些核心的项目，大致理解一下核心项目之间的关系。 buffer模块是对Java nio包下的ByteBuffer进一步封装，优化一些处理方式。核心类ByteBuf。

codec模块就是一些各种数据的处理，比如xml格式的数据处理，smtp（简单邮件传输协议的数据格式处理），目的：解决TCP的粘包和拆包问题。

example，这个模块，几乎是任何一门技术都会默认提供的。拷贝里面的代码，进行修修改改。目的：学此技术开发者，如何使用。

handler, 这个模块，就是Netty为了简化开发者的开发难度，提供一些默认的处理器。就是写好了的handler,开发者自己添加到pipeline中即可。 默认 NioEventLoopGroup 是平台独立的，既支持Linux也支持Windows。而上图的epoll和kqueue只支持Linux的。 目的：提供不同的I/O模型的支持。在实际情况中，有些I/O模型只支持windows，有些I/O模型支持Linux的，也跟操作系统的版本有关系。强烈推荐阅读： Comparing Two High-Performance I/O Design Patterns

4. 找到，example，尝试着跑起来。

5. 把example的代码，拷贝到自己的demo中，跑起来。

6. 找到已经写好的现成可用的代码（handler）。因为这些东西，在自己构建项目的时候，拿来就可用了，何必在写。

7. 在源码中设置断点，看看大致执行逻辑是什么样的？

8. 思考为什么是这样的，有些值怎么就有了？有类对象怎么就创建了？有想不明白的，就需要记录下来，慢慢去琢磨，慢慢就会弄明白的。（培养一个思维：带着问题去学习和思考）

9. 写一些文档，记录自己的学习过程和思考过程。总结其中一些好的代码，好的知识，易错的地方，需要注意的核心的地方。

10. 用在真实的项目中。跟同事讨论。

11. 写一个自己的心得教程，给公司的同事进行分享。

12. 一定有一个意识，就是，此技术的最佳实践是什么呀？

    Netty的线程模型。（boss group, worker group）

    取名（线程名，处理器名）

    监控（数据可视化）

    安全（ip过滤，黑白名单，SSL使用）

    限流（流量整形）

    自定义的授权（需要用户名和密码才能访问）

    保证内存不泄漏（引用计数）

    解决TCP的粘包和拆包问题（codec）

    读写空闲(keepalive)

    日志记录(LoggingHandler)

    需要思考这些问题，我们开发者应该如何去保证，而且需要有一个适用场景去调节它。

13. 会收获成就感、自信心、信心。其中，10和11会让我们理解的更深。如果没有这样的机会，那就一直写文档来输出自己的理解。12可用培养一种思维就是：做任何一件事其实是可以一直精进的。

其实，无论学什么技术，思路都大同小异。

小结

1. 舍得花时间。舍得花时间。舍得花时间。舍得花时间。

2. 读官方文档，是了解基本概念和设计思路。去找它源码，是看大致实现细节。打一个断点理解一段代码的执行流程，就理解了它的工作过程。

3. 去看框架源码，是如何处理一些问题的？写代码的时候，去模仿。甚至不需要模仿，直接拷贝过来，修改一下也就可以了。学习都是这样站在巨人的肩上的，不要想着，在没有任何基础知识和项目经验的情况下，靠自己去编码解决问题，也尝试过，但是永远也无法把问题考虑完备。框架就把能够考虑的问题考虑到了，能解决的问题都有最佳的解决方案，我们只需要去用，去理解它工作过程就行了。慢慢地，随着基础知识的累积和项目经验的丰富，有一天也许我们可以写出满足自己业务场景的框架代码，而考虑的问题，大致也就是好的框架代码，已经考虑过了；最佳的解决方案，也有了。

4. 规律：框架都有自己的目录结构。就像Linux操作系统一样，约定的目录结构。同理，其他任何框架技术都是这样考量的，有example，我们可以拷贝下来运行。有提供现成的解决方案的代码，拿来即用。

5. 还可以继续精进：反复思考，它是什么，解决什么问题，适用的场景，优点，缺点，能不能再此框架上做出一些细微的修改。细微修改就特别难，需要沉淀技术。

6. 最终结论：套路很重要，但是实践更重要。这些步骤能够走好，需要有一定的毅力。