1.java框架学习方式有哪些？
2.Github 源码阅读神器推荐
3.一次 Netty 代码不健壮导致的码学大量 CLOSE_WAIT 连接原因分析
java框架学习方式有哪些？
1、打好基础是码学重中之重基础部分可能很枯燥，但是码学一定要耐心坚持下去。因为打基础好比是码学在造轮子造汽车，没有打好基础在后面的码学学习就好比走路，可以说后面遇到的码学普洱源码百分之七八十的问题都是基础没学好造成的。
2、码学多看官方文档多读源码
一定要看JDK相关类库、码学常用框架各种功能的码学源码，去了解其底层实现的码学原理。总的码学来说这个也是在打基础的部分，Java基础非常扎实才能看懂，码学在我们学习一个类的码学源码时，肯定会衍生出其他各种各样的码学问题，供我们来了解和学习，码学这也就是我们下一步学习的目标和方向。慢慢的，我们就会学习更多的知识，并积累更多的经验。
3、系统性学习，循序渐进
不要急于求成，每个知识点都要看，并且每个知识点都要勤加练习。有的同学在学习过程中觉得这个知识点简单，就跳着学习，其实这是个很大的问题，知识点细节必须要了解。我们学习Java需要循序渐进，一步一步来，不能操之过急。
4、遇到问题
遇到不会做的问题，当然不能置之不理。slide插件源码先在网上查，目前网络上针对很多问题都有完美的解决方案，如果网上没有类似的问题，那可能是你犯了什么小错误。也不要在这个问题上花费太多时间，这需要一定的学习技巧。Java中的知识有很强的相关性，有不懂的地方，可以用其他周边相关知识再回过头来理解，这样既不会耽误学习进度，又能理解自己不懂的地方
1）jvm有很多种，其实jvm是一个标准，sun做的那个叫hotspot，作者就是后来v8的作者lars bak，其他公司也做过jvm，其中做得比较好的有bea的jrockit，其他的包括ibm的r9，apple的jvm等在内，都做得不行，所以jvm主要是整合淘汰掉这些做得不好的jvm(s)，整合成一个统一的openjdk。
2）java是典型的oop语言，其执行效率的优化，最早就是lars bak等人从smalltalk等长期优化的经验中总结出来并apply到hotspot上去滴，而smalltalk在早期apple机上搞出了那种拖拖拽拽就开发出app的做法，后来vc，delphi之类的其实都是抄袭或者说借鉴apple的smalltalk的做法，jobs说微软从头到尾都在抄袭apple是空穴来风，这里空穴来风跟王垠使用的空穴来风是一个意思，有趣的是，java的gui并没有继承这种搞法，反而对这种拖拖拽拽就作出app的做法批判有加，到今天，免费c 源码其实java的gui都还不能真正做到拖拖拽拽就作出来，问题很多，个人建议对于纯java的gui开发，还是以写代码为主。
3）jee也是一个或者说是一堆标准，知乎上有些人把maven，jenkins都算做jee是不对滴，jee的标准核心是ejb，其实就是一个xml配置化的java文件，这个标准在4的时候，达到了顶峰状态，几乎所有的挨踢大厂都主动支持该标准，之后开始走下坡路，支持的厂越来越少。
4）java和javascript的关系比很多人认为的要密切，javascript里面的java这四个字母可不是白叫的，比如js的版权和商标都控制在oracle手里，oracle对于js的支持甚至超过其对java的支持，并且喜欢捆绑销售，比如jvm里面就有一个js引擎。
5）jvm里面除了js engine以外还有一个浏览器排版引擎webkit，就是apple safari和google chrome用的那个那个。
6）java支持绝大多数脚本语言，你能叫得上名字的脚本语言，几乎都可以在jvm上执行，比如常见的js，ruby，python，甚至php，lua，只不过除了js以外你需要找到相关的脚本引擎。
7）spring的版权被控制在vmware手里，其实spring的交友相亲源码那一大堆东西，本质上是一个非标准的jee实现，比如在jee里面用的inject，在spring里面就是autowire，当然spring曾经深刻滴影响了jee，所以有些东西比如di标准，是spring影响下制定出来的，所以spring的做法会比较特例一点。
8）maven上的jars数量前两天突破万，其他语言的类库，排名第二的是npm，大概数量是maven的十分之一，也就是几十万，不知道现在突破万没有，然后是gem，也就是ruby那个，大概是十几万，下来是python的module，大概数量级是几万，没突破十万。
9）java的标准是由一个叫做jcp的组织制定的，所有标准需要经过jcp的执行委员会通过方可执行，jcp几乎包括了你所知道的绝大多数知名挨踢公司和组织，比如google，apple，ibm，intel，arm，red hat，twitter等，还有一些教育机构，比如我国的北京大学，阿里最近一次申请jcp执行委员会成员资格，似乎投票不通过，当面付 源码最近一次执行委员会新增两个成员是arm和jetbrains。
）微软也曾经是jcp甚至是java的主要贡献者，但是利益驱使下，想扩展java，从而破坏java跨平台的特性，所以跟sun闹翻，其本质原因就是想让客户写的java代码跟windows绑定，sun坚决不同意，闹翻，今天回头看这个结果，只能说：双输，sun挂了，微软的ria也离挂不太远了，silverlight已经放弃了，比起当年ie自带有jvm的支持来说，那完全就是两回事。
）除了微软以外，jcp还缺少一个重要组织apache，因为apache跟oracle也闹翻了，oracle似乎并不在乎开源组织，而更在意商业公司的支持。
）java曾经有一个内置的数据库，9之后被剥离。
）j2me是j2se的子集。
）vert.x作者tim fox最早在vmware做spring时候看到了node.js，萌生出了制作支持多核的node.x的想法，并在离开vmware后加入red hat将其实现，vmware看到后开始耍无赖，claim node.x后来改叫vert.x的版权，不惜跟red hat打官司，后来各方妥协，将其交给eclipse foundation。
）oracle在收购bea之前，一开始的目标并不是bea和bea的weblogic，而是jboss，但是jboss表现出了极为有种的一面，在oracle收购成功之前，投入了red hat的怀抱，因为都是开源组织，从此jboss成了red hat的一个子部门，oracle收购jboss失败之后，转向bea，庄思浩气死了，但是没用，最后还是被恶意收购。
）sun在玩不下去之前最早尝试接触的目标是ibm，ibm嫌太贵，放弃之后，被转手给了oracle。（Java学习交流QQ群： 我们一起学Java！）
）vert.x的作者tim fox在离开red hat之前曾经发过twitter抱怨，外人比如我们，猜测是因为red hat内部已经有了一个jboss，所以跟vert.x在应用上有了重叠，所以导致tim fox的出走，但是出走之后，red hat答应对vert.x做持续性的战略投入，所以vert.x core的几个developers，其实拿的是red hat的工资，但是vert.x的版权并不在red hat手里，而在eclipse foundation手里。
）vert.x的几个核心开发人员都是google summer of code的导师，每年年初时候会招收在校大学生搞项目。
）教育机构相关：scala的作者马丁是德国人，eth的博导，groovy的主要***是法国人，jruby背后是东京大学，jboss的作者是法国大学校x的校友，x就是伽罗瓦考不进去的那所大学，伽罗瓦进不了x，所以改读巴黎高师，tim fox毕业于帝国理工，主席去的那个，netty作者trustin lee是acm银牌，现在line工作，毕业于sky里面的延世大学，kotlin是毛子公司jetbrains的作品，看linkedin，很多人毕业自圣彼得堡大学，spring作者rod johnson是悉尼大学的音乐博士，hibernate作者gavin king是澳洲莫那什大学的数学本科毕业生，james gosling这种cmu和calgory的估计烂大街了，sun是斯坦福大学网络的意思，夹带两个私货，aspectj有一个维护小组在mcgill，hbase跟waterloo关系密切。
）java早期被人认为慢，跟java坚持不用硬件加速渲染有关，死活就是不肯接入directx和opengl，7之后总算开窍，搞了一个图形引擎接入了directx／opengl。
）casssandra是facebook做失败的项目，被贡献给了apache之后老树开花。
）groovy被贡献给了apache，现在叫做apache groovy，ceylon被贡献给了eclipse，现在叫做eclipse ceylon。
）netflix现在是java shop，之前是用.net的。
先想到这么多，有空再写。
Github 源码阅读神器推荐
一款高效阅读和学习源码的开源项目，source-code-hunter（doocs.github.io/source-code-hunter），为源码阅读爱好者提供便利。
借助source-code-hunter，用户能够系统化阅读各种框架的源码，包括spring全家桶、Mybatis系列、Netty、dubbo等，以及中间件、JDK源码解析。
该项目为初学者和源码学习者提供了学习心得，帮助他们建立学习模式，避免无用阅读，加速学习进程。
对于没有源码阅读经验的用户，建议先阅读学习心得，了解学习方法和思考。在日常学习中，先通过视频了解源码的大致设计和功能点，再结合source-code-hunter阅读源码，同时使用本地调试跟踪实现，提升学习效率。
source-code-hunter涵盖了常见框架的源码解析，为用户提供了丰富的学习资源，帮助用户深入理解源码逻辑，提高编程技能。
一次 Netty 代码不健壮导致的大量 CLOSE_WAIT 连接原因分析
我们线上存在一个 Dubbo 服务，遇到大量 CLOSE_WAIT 状态的连接，始终无法消失，因此进行了原因分析。 CLOSE_WAIT 状态出现在被动关闭方，收到对端 FIN 包后回复 ACK，但未发送 FIN 包之前。问题在于服务没有回复 FIN，原因可能是收到了 FIN 包却未发送响应，通过抓包验证了这一情况。 问题核心在于为什么没有回复 FIN。Dubbo 服务底层使用 Netty，作为普通的 TCP 服务端，关键在于 FIN 包的回复。 分析显示，如果服务没有发送 FIN 包，可能原因有： 1. 半连接队列或全连接队列积压，通过 ss 命令查看全连接队列大小和等待 accept 的连接个数。 2. LISTEN 状态的 socket，Recv-Q 表示等待用户进程 accept 的连接个数，Send-Q 表示全连接队列最大容纳的连接数。 非 LISTEN 状态的 socket，Recv-Q 表示 receive queue 字节大小，Send-Q 表示 send queue 字节大小。 通过 ss 命令确认 Recv-Q 为 0，全连接队列无积压。 嫌疑指向 Netty 没有注册事件，导致收到 FIN 包后无动于衷。 进一步发现，凌晨 1 点业务实例加载大量数据导致堆内存占满，持续进行 fullgc。Netty 线程出现 OOM 异常。在 org.jboss.netty.channel.socket.nio.NioServerBoss#process 方法中，Netty 调用 accept 取走连接，第 行尝试注册事件时抛出 java.lang.OutOfMemoryError 异常。 因此，Netty 处理不健壮，try-catch 包裹了 accept 连接和注册事件逻辑，在 OOM 异常处理时，未能成功注册事件或关闭连接，导致连接存在但不被监听处理。 推荐相关视频学习：LinuxC++零拷贝的实现 用户态协议栈 ntytcp
支撑互联网的基石 TCP/IP，5个方面全面解析
TCP/IP协议栈深度解析丨实现单机百万连接丨优化三次握手、四次挥手
LinuxC++后台服务器开发架构师免费学习地址
为模拟问题复现，可使用字节码注入或直接重构 Netty 源码。本地拥有 Netty 源码，采用重构方法更快。重新构建项目后，使用 nc 模拟健康检查握手并断开连接，CLOSE_WAIT 状态连接持续存在直至 Netty 进程退出。再次 nc 断开连接，新增 CLOSE_WAIT 状态。由于服务持续进行健康检查，导致 OOM 期间 CLOSE_WAIT 状态不断增加。 问题核心：Netty 代码不够健壮，尝试捕获异常时，未能正确处理连接注册事件或关闭连接，导致连接存在且未被监听。 修改方式：在 catch 处理 throwable 时关闭连接即可，最新版本的 Netty 代码这部分逻辑已优化，将 accept 和注册事件拆分。有兴趣的读者可以尝试。 学习 TCP、网络编程是解决类似问题的关键。
