前言
最近个人事情比较多（搬家、换工作、短暂休息）所以一直也没有顾得上博客更新，恰好最近收到一封邮件提醒了我。
也是时候写一篇文章来聊聊参与开源项目的事（最近也确实进入了笔荒期）。
ps:第一次收到这样的中秋节礼物，加上 Dubbo 社区的活跃及阿里的重视度，还在做 RPC 或微服务技术选型的朋友可以考虑 Dubbo。
参与开源
现在具体来聊聊参与开源的事；
日常几乎所有的开发者都会享受到开源项目所带来的便利甚至是收益，受限于环境早在十几年前甚至几年前开源活动一直都是有国外开发者主导。
但这几年国内互联网公司逐渐国际化扩大影响力也很大程度的提高了我们的开发水平，以 BAT 为首出现了许多优秀的开源项目。
现在甚至参与开源项目还能另辟蹊径的拿到大厂 offer，所以其实不少朋友都想参与其中，可能这事给人的第一感觉就不太容易，所以现在还卡在第一步。
具体步骤
以下是以我个人经验总结的几大步骤：
-
发现问题或自荐 feature。
-
fork 源码。
-
本地开发、自测。
-
发起 pull request。
-
等待社区 CodeReview。
-
跟进社区意见调整代码。
-
审核通过，合并进 master分支，完成本次贡献。
Dubbo的流程来具体聊聊。
发现问题或自荐 feature
feature；前者相对起来更加容易一些。
What？
一个 Dubbo 服务启动要两个小时！
invalid标签认为不是问题，或者是使用姿势不对也是有可能的。
fork 源码，本地开发
Dubbo服务非常缓慢，经过定位是
main线程阻塞在了获取本机 ip 处。
InetAddress.getLocalHost().getHostAddress()，但又需要知道它阻塞了多久才好判断是否超时。
main线程是否已经完成任务了，以下便是我第一次 pr 的内容。
-
额外声明了大小为 1 的线程池。
-
再声明了一个 volatile标志用于判断主线程是否有完成任务。
-
声明了一个 condition 用于新线程做等待。
-
最后只需要运行这个线程用于判断这个标志即可。
如何自测
mvn clean install将包安装到本地才能在其他项目中依赖进去进行测试。
mvn clean install将自己修改的代码安装到本地时，大概率是会出问题的（也可能是我姿势不对），这样就会导致新建的项目中依赖不了自己新增的代码。
不过再提交时得注意不要把这个版本号提交上去了。
发起 pull request
pull request了，不要大意，这里还得有一个地方需要注意，那就是代码换行符的问题。
git会认为这次修改是删除后重来的，这样会给
code review带来巨大的麻烦。
git确认为你是推翻了重来，导致审核起来根本不知道你改了哪些地方。
git的全局配置，可以参考这里。
git config --global core.autocrlf truegit config --global core.autocrlf inputgit config --global core.autocrlf false
Code Review
pr发起后便可等待社区审核了。
code review的过程，所有人都可以参与其中头脑风暴，其中也不乏技术大牛，不知不觉便能学到不少东西。
类似案例
Dubbo中也有用到。
TCP网络包的发送过程，本身就是异步的。
Dubbo在你不知道的情况下做了异步转同步，这样看起来就像是一个同步方法。
Dubbo自身调用了
get()方法用于同步获取服务提供者的返回结果。
isDone()函数返回的是是否已经拿到了服务提供者的返回值而已。
总结
荐
阅
读
在看
本文分享自微信公众号 - Java后端（web_resource）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
相关文章
暂无评论...
致力于称为最好的程序员导航网站