「我正在参与掘金会员专属活动-源码共读第一期，点击参与」
前言
源码阅读其实在工作中也是经常的事，但我毕竟是安卓开发，后端技术我真不是很了解，不过既然掘金提供了这么一个学习的机会，那我自然不会放过，今天就让我们开启源码共读的篇章吧，希望这不同的眼界探索可以在这截然不同的领域会有所收获，为自身技术带来启发。
正篇
本章是根据源码共读活动提供的小册学习任务（源码共读第一期｜掘金会员专属活动 - 赵小饼 - 掘金课程 (juejin.cn)）学习收获而得，内容是有关Netty的，总共七块任务以及一个额外任务，本篇是完成第一个任务。
事先申明，本人从未接触过相关内容，如果在分析过程中有问题，望各位积极指正！
导入项目与准备工作
根据文章给出的git克隆命令：
git clone https://github.com/arthur-zhang/netty-study.git
复制代码我使用其URL地址（github.com/arthur-zhan… ）在GitHub Desktop软件上获取了相应项目库
后面发现家中电脑中没有安装IDEA，只有Android Studio，所以还需要安装IDEA，直接官网安装社区版免费的（Download IntelliJ IDEA: The Capable & Ergonomic Java IDE by JetBrains）就可以。
安装好IDEA后我们打开拉到本地的项目：
作者很贴心的为我们分好了任务结构以及附带README.md文件方便查看任务目标，我一般选择project files(项目文件)形式的目录，我安装的IDEA默认安装了简体中文插件，有点不适应，但官方推荐就安了，安装好要重启一遍才能显示中文版
接着我们可以看到一行要求导入netty的建议在你打开MyServer.java文件时，我们确定后等待完成即可
全部完成我们就能进入源码阅读任务阶段了
断点调试
第一个任务是进行断点调试，这在工作中也经常使用，一般出现日志缺少或需要知道某一结构的具体运行情况时，我们通过在相应位置断点，就可以查看运行时这个区域的相应情形，甚至可以模拟数据来分析相应情况，这在我之前的文章中也提到（我奇怪的安卓开发历程（内含本人不太成熟的技术观）（三） - 掘金 (juejin.cn)），虽然我是使用Android Studio的，但AS也是IDEA的魔改，所以都差不多。
但本任务中是使用断点看调用堆栈，据我了解，调用堆栈可以一句一句溯源该语句运行的逻辑;
我们可以在MyServer文件中Ctrl+F查询“bind”（Windows系统中），然后定位到该使用语句，在该语句左侧如上图红框处点击鼠标打断点，红色圆代表该处有断点
运行查看
但netty需要服务端和客户端，这里demo是Netty echo server的，所以可以如下操作：
服务端在netty依赖添加好后运行MyServer文件即可
如果依赖添加中途关掉了，下次也可以自己在maven文件处右击鼠标选meavn添加好：
客户端方面，我们在windows系统上先在控制面版上打开Telnet客户端功能,接着直接Win+R，然后cmd,输入命令
telnet localhost 8888
复制代码下面nc方法未成功，且作者电脑运行IDEA中突然抽风一次,自动重启了而且重启商标画面变红，有点后怕，暂时建议读者如果没有试过就不要试试，或者等评论区大佬有正确方法再尝试
客户端也可以用nc（netcat）方式，Windows系统需要先下载（netcat 1.11 for Win32/Win64 (eternallybored.org)）
会触发病毒提醒，需要运行在设备上，然后执行操作，再重新下载，解压文件
将nc.exe 复制到C:\Windows\System32的文件夹下
作者nc方式未成功，目前原因未解决
命令类似
nc -l -p 8888
复制代码调试断点，分析结果
我们在main()方法出点击绿色三角形然后选择调试（debug）：
调试完成后结果如下：
可以把光标对到bind代码处，然后Ctrl+单击鼠标可以跳到源码处，如果没有下载，会有提示：
至此我成功发现自己没找到任务要求bind的正确位置，但方法同理，我们看看要求在哪个地方断点：
原来是ServerSocketChannelImpl类，我们全局搜索一下，Ctrl+Shift+R,再选择最后一个范围，可以查看所有含该关键词的代码：
在这个类的第8个bind关键词搜索到我们任务需要的地方，再打断点
这次再调试，成功，我们找到了任务所需要的调试任务栈：
backlog参数分析
接下来我们看看打印的backlog参数，
可以看到默认为0
然后我们在源码中可以定位到unixBind和netBind方法
发现该参数小于1时会在Net.listen（...,...）方法中第二个参数转为值50。
到这里看字面意思是网络监听文件描述器，有点懵，去查了一下网上的博客，有如下解释：
backlog影响的accept队列大小
客户端把数据放到accept队列，JVM再从accept队列取。
如果accept队列太小，JVM取数据不够快，那么accept队列就会溢出 （来源：(36条消息) Java NIO ServerSocketChannel backlog原理、源码解读与默认值_疯狂的技术爱好者的博客-CSDN博客） 不知道靠不靠谱，又看了一下listen方法是native方法：
而且四处使用都一样的逻辑：
上述的解释有点靠谱，暂时分析到此处。
总结
这次因为包含安装和环境搭建过程，所以总用时较长，阅读源码千万不能钻牛角尖，我们可以在不清楚的地方多查查搜索引擎,看看大神博客，结合起来，才能收获更多，断点的方式也能更好的回溯我们的方法调用过程，在开发维护的时候还是很方便的，源码阅读第一次使用，在文中没有展现出来，我们其实可以从栈底部到顶部依次去看到如何跳到bind方法的：
如上图，我们从main方法开始向上一行行点击就能找到运行的跳转逻辑，最终到达断点处bind方法。
除此以外，肯定也有很多实用其他方法，等待我们去发现，也希望掘友们能够提出自己的使用方法，集思广益，才能更利于技术发展！