做服务的网站,如何利用div做网站,龙岩网吧,学做网站的书籍为什么要阅读源码#xff1f;1.在通用型基础技术中提高技术能力在 JAVA 领域中包含 JAVA 集合、Java并发(JUC)等#xff0c; 它们是项目中使用的高频技术#xff0c;在各种复杂的场景中选用合适的数据结构、线程并发模型#xff0c;合理控制锁粒度等都能显著提高应用程序的… 为什么要阅读源码1.在通用型基础技术中提高技术能力在 JAVA 领域中包含 JAVA 集合、Java并发(JUC)等 它们是项目中使用的高频技术在各种复杂的场景中选用合适的数据结构、线程并发模型合理控制锁粒度等都能显著提高应用程序的可用性、健壮性非常容易凸显出自己的技术实力更容易受到领导的认可助力职场。当然通过阅读源码并不是知晓原理的唯一方法但作为一个名程序员、直面代码亲自感受代码的魅力或许会显得的更加直接。2.在重点领域打造自己的亮点我所在公司使用了 Dubbo、RocketMQ我也有幸参与到这些技术栈的运用与运维积累了丰富的使用经验为了突出在这两个领域的优势我详细阅读了它们的源码在CSDN和公众号等知识分享平台发布了大量的技术文章成体系的剖析其实现原理、架构设计理念理论与实战相结合让我成为在Dubbo、RocketMQ领域当仁不让的技术专家团队中的核心骨干。同时由于文章是成体系的被出版社相中邀请出书《RocketMQ技术内幕》一书应运而生从而成为我职业技能列表中非常亮眼的名片形成公认的技术影响力具备一定的“品牌溢价”能力。当然 也可以等到出了问题再看源码“投入产出比”更高但这是个被动过程如果生产环境由于并发不高那可能一年、两年你都遇不到真正的问题经验积累非常慢 工作了4、5年有可能还比不过工作2、3年的人。所以如果是你想快速打造亮点的话还是需要主动阅读源码成体系掌握其设计理念、实现原理。3.从优秀的源码中学习设计和编码学习编程的过程其实就是一个模仿的过程 优秀的源码都是大师级作品极具营养可以看到大师们是如何抽象接口的如何应用SOLID原则的还有很多非常有用的编程技巧。例如JUnit是从模式开始构建系统 其中你可以看到大量的设计模式的应用这些都是活生生的案例比干巴巴地看那些设计模式理论或者简单的例子不知道好到哪里去了。如何阅读源码我根据多年的阅读经验整理了这么一套方法了解这款软件的使用场景、以及架构设计中将承担的责任。寻找官方文档从整体上把握这款软件的设计理念。搭建自己的开发调试环境运行官方提供Demo示例为后续深入研究打下基础。先主干流程再分支流程注意切割逐个击破。接下来分享一下我在阅读 RocketMQ 源码时的一些经历尽量让上述理论具有画面感。1.了解 RocketMQ的应用场景MQ的使用场景是比较清晰的它的两大基本职责是解耦与削峰填谷。举一个最简单的场景新用户注册送积分、送优惠券场景其原始架构设计通常如下可以看出用户注册和发优惠券送积分是紧耦合的 随着业务不断发展活动部门提出在春节期间用户注册不送积分发优惠券而是赠送一个新春礼包如果基于上述架构的话需要去改动用户注册的主流程违背了设计模式中的对修改关闭、对扩展开放的设计理念。MQ的出现可以很好地解决上面的问题图片通过引入MQ用户注册主流程只需要完成注册逻辑并向MQ发送一条消息然后活动模块送积分、送优惠券、送礼包只需要订阅MQ中的消息进行对应的处理。这样消息注册主流程会非常的简单不管活动种类如何变化注册流程无需更改这样就实现了解耦。2.通读官方文档从全局把握其设计理念了解使用场景以后接下我们可以去查阅官方文档主要包括用户设计文档架构设计用户使用手册等从全局了解其设计理念。图片通过通读官方文档不仅可以得出MQ的整体脉络例如NameServer路由发现、消息发送、消息存储、消息消费、消息过滤也能对顺序消费零拷贝、同步刷盘、异步刷盘等“高端大气上档次”的高级特性产生兴趣与好奇驱动我们去阅读其源码探究其实现细节使得我们在阅读源码中进行一定的自我思考成为了可能。3.搭建开发调试环境不同的系统搭建方式也不同我这里有一篇手把手教你安装RocketMQ与IDEA Debug环境搭建。4.先主干再分支在搭建好本地开发环境后切忌直接用Debug去跟踪消息发送的整体流程因为这个流程实在是太长了从比较粗粒度来看其流程如下图所示如果大家想一次性将上述流程的源码全部看一遍几乎是不可能的。因为消息发送高可用设计、消息存储、刷盘、同步等机制每个点详细展开的工作都是海量的我们没有这么多连续的时间所以适当的拆分非常有必要。经过这样一分解就能专注理解其某一块的设计原理所需要的连续时间也能大大减少一口一口“吃”最终完成整个体系的理解。这还带来了一个额外的好处分批次输出多篇文章提高了文章产出提高了成就感。源码阅读误区源码阅读是手段但一定不是目的。我在面试过程中发现好多候选者在谈到某一项技术时首先不是介绍其原理而是一下子具体到某个类啥的这些类是如何如何工作等等其实这是不太妥当的源码阅读的目的是主要是深入理解其设计理念、工作机制方便我们在实际使用过程中对其成体系的认识加强对它的驾驭能力做到提前规避风险。其次源码阅读非常不建议一上来就直接DEBUG。如果一开始就使用DEBUG很容易会迷失在代码的各个分支中缺乏全局视角从而变得没有头绪极大的增加了源码理解的难度很容易让我们半途而废。最后学习一门技术并一定要深入源码特别是非主流非重点打造的领域。对于此类我们通常只需根据阅读官方文档了解其使用场景、能解决什么问题理解其设计理念、工作机制灵活运用解决具体问题即可。阅读源码很容易放弃怎么办阅读源码是枯燥的一个人孤军奋战很容易放弃尤其是遇到问题的时候 如何才能坚持下去把它读完呢我的答案是坚持但允许短暂的修整、停留然后反复发起冲刺拼抢直到攻克这个“山头”。因为一旦放弃就将前功尽弃一旦突破自身能力能得到一个质的飞跃。我在阅读Netty源码时就遇到了难题当时刚刚写完Netty的内存泄露检测准备开始研究内存分配机制 这一块儿非常抽象涉及的数据结构复杂需要掌握二叉树与数组之间如何映射、牵扯到大量的位运算等等让我在探究其原理时寸步难行怎么办呢放弃当一周、两周都无法取得突破时人很容易想到这样持续投入时间又没有回报 是不是在浪费时间其实我想过放弃但转念一想放弃后我会做什么呢玩游戏看电视既然是玩游戏、看电视不更是浪费时间吗想清楚这一层后继续攻关继续突破就成了唯一的选择。当然遇到难题了偶尔放松一两天重新调整状态也是非常必要的。短暂的休整可以让我们变得不那么焦躁有利于我们重新整理思路重新发起冲刺。当时遇到难题时采取哪些措施有利于我们攻克难题呢1、向“度娘”求救在阅读源码时可以将看不懂的代码直接COPY一小段到百度上去搜索可能会有大牛已经对这些代码做过解读能起到指点作用。当时经过我的搜索发现Netty的内存分配算法并不是首创而是对 jemalloc 算法的实现通过查阅相关的技术文档可以从整体上理解Netty的内存分配算法。2、Debug Netty追求极致的性能采用了大量的位运算由于平时工作中很少会使用位运算看起来比较吃力为了弥补这方面的不足使用DEBUG模式结合运行时数据去理解位运算更容易开窍。经过上面的努力花了10天时间Netty的内存分配机制慢慢被我解开经过分解我写了一系列文章来描述Netty内存分配迈过了这道坎后面的源码阅读效率变得非常高效。通过攻克一个个难题最终从量变引发质变逐渐形成一条自己的源码阅读理论后续的源码分析RocketMQ、Dubbo、ElasticJob、Sentinel、Kafka等专栏就变得非常简单了。源码阅读的三层境界初级记流水账我初期的源码阅读文章基本上是记流水账例如对源码一样一行加注释只关注底层实现细节但并未形成更高层次认知对其设计理念没有提炼与深度领悟。中级能提问、思考、提炼随着技术类文章的持续分享 我认识了很多大牛发现和他们交流的时候发现他们一开始并不会说细节而是讲设计理念。这就要求我们在阅读源码的时候多思考并反问自己如果自己实现的话该如何着手如何设计带着疑问去研究源码。通过对比思考会对其背后的理念有了更深刻的理解。高级思考、质疑、验证不管是哪个开源框架都会存在BUG或者实现并不合理的地方如果大家在阅读源码的时候能够深入思考 合理质疑并能通过验证证明自己的观点然后与官方取得联系交流共同促进社区的发展说明我们的能力、思考得到了极大的提升。思考与质疑是源码阅读的一个升华比如我在看Sentinel 熔断时对其提出的质疑。一个“用户信息查找”服务被部署到了三个机器上。其中192.168.1.3这个机器有一段时间负载过高响应时间过长发往它的请求有30%都失败了。而30%恰恰是Sentinel设置的熔断错误率 于是Sentinel认为整个“用户信息查找”服务不可用了熔断了。这明显是不合理的因为192.168.1.4和192.168.1.5这两个机器还活着呢本质上这是因为熔断错误率被定义到了服务级别 服务 - 熔断错误率在对这个问题进行思考的时候我认为在配置熔断规则的时候需要细化应该把熔断错误率定义到资源组级别[服务 , 机器] - 熔断错误率这样当一个机器上的服务提供者被熔断后不影响其他机器保证了真正的高可用。通过与官方联系我这个想法得到了其作者的肯定反向促进了社区的发展。总结源码阅读并不是目的只是手段。对于通用型基础技术诸如JAVA集合、并发、需重点打造为亮点的领域建议大家阅读其源码成体系深入细节掌握其工作机制增强其驾驭能力拥有提前规避风险的能力。
往期推荐
想读Spring源码先从这篇「 极简教程」开始不要再用main方法测试代码性能了用这款JDK自带工具Socket粘包问题的3种解决方案最后一种最完美关注我每天陪你进步一点点
