前言
最近個人事情比較多（搬家、換工作、短暫休息）所以一直也沒有顧得上博客更新，恰好最近收到一封郵件提醒了我。
也是時候寫一篇文章來聊聊參與開源項目的事（最近也確實進入了筆荒期）。
ps:第一次收到這樣的中秋節禮物，加上 Dubbo 社區的活躍及阿里的重視度，還在做 PRC 或微服務技術選型的朋友可以考慮 Dubbo。
參與開源
現在具體來聊聊參與開源的事；
日常幾乎所有的開發者都會享受到開源項目所帶來的便利甚至是收益，受限于環境早在十幾年前甚至幾年前開源活動一直都是有國外開發者主導。
但這幾年國內互聯網公司逐漸國際化擴大影響力也很大程度的提高了我們的開發水平，以 BAT 為首出現了許多優秀的開源項目。
現在甚至參與開源項目還能另辟蹊徑的拿到大廠 offer，所以其實不少朋友都想參與其中，可能這事給人的第一感覺就不太容易，所以現在還卡在第一步。
具體步驟
以下是以我個人經驗總結的幾大步驟：
- 發現問題或自薦
feature。 - fork 源碼。
- 本地開發、自測。
- 發起
pull request。 - 等待社區
Code Review。 - 跟進社區意見調整代碼。
- 審核通過，合并進
master分支，完成本次貢獻。
下面我會結合最近一次參與 Dubbo 的流程來具體聊聊。
發現問題或自薦 feature
首先第一步自然要搞清楚自己本次貢獻的內容是什么？通常都是解決某個問題或者是提交一個新的 feature ；前者相對起來更加容易一些。
當然這個問題可以是自己使用過程中發現的，也可以是 Issues 列表中待解決的問題。
以本次為例，就是我在使用過程中所發現的問題，也提交了相關 Issue 并寫了一篇文章記錄并解決了該問題：What？一個 Dubbo 服務啟動要兩個小時！
值得注意的是在提交 Issue 之前最好是先在 Issue 列表中通過關鍵字檢索下是否已經有相關問題，避免重復。
同時提交之后也許社區會進行跟進，被打上 invalid 標簽認為不是問題，或者是使用姿勢不對也是有可能的。
fork 源碼，本地開發
當確定這是一個待修復的問題時就可以著手開發了。
首先第一步自然是將源碼拷貝一份到自己倉庫中。
接著只需要 clone 自己倉庫中的源碼到本地進行開發。
先回顧下我遇到的這個問題。
簡單來說就是啟動 Dubbo 服務非常緩慢，經過定位是 main 線程阻塞在了獲取本機 ip 處。
所以當時我提出的方案是：在獲取本機 ip 時加上超時時間，一旦超時便拋出異常或者是再次重試，但起碼得有日志方便用戶定位問題。
問題是主線程會一直阻塞在此處 InetAddress.getLocalHost().getHostAddress()，但又需要知道它阻塞了多久才好判斷是否超時。
所以只能再額外開啟一個線程，定時去檢測 main 線程是否已經完成任務了，以下便是我第一次 pr 的內容。
這次的重點不是討論這里具體的技術細節，所以簡單說下步驟：
- 額為聲明了大小為 1 的線程池。
- 再聲明了一個
volatile標志用于判斷主線程是否有完成任務。 - 聲明了一個 condition 用于新線程做等待。
- 最后只需要運行這個線程用于判斷這個標志即可。
如何自測
開發完成后下一步就是自測，由于這類項目是作為一個基礎包依賴于其他的項目才能運行的，所以通常我們還得新建一個項目來配合做全流程測試（單測除外）。
這里我覺得還是有幾個小技巧值得注意。
第一個是版本號；因為在本地測試，所以需要使用 mvn clean install 將包安裝到本地才能在其他項目中依賴進去進行測試。
但由于我們從官方拉出來的代碼版本都已經發布到了 maven 中央倉庫中（不管是 release 還是 snapshot），所以我們本地倉庫中肯定已經存在這幾個版本的 jar 包。
一旦我們執行 mvn clean install 將自己修改的代碼安裝到本地時，大概率是會出問題的（也可能是我姿勢不對），這樣就會導致新建的項目中依賴不了自己新增的代碼。
所以我通常的做法是修改版本號，這個版本號是從來沒有被官方發布到中央倉庫中的，可以確保自己新增的代碼會以一個全新版本安裝到本地，這樣我們再依賴這個版本進行測試即可。
不過再提交時得注意不要把這個版本號提交上去了。
發起 pull request
自測完成后便可發起 pull request 了，不要大意，這里還得有一個地方需要注意，那就是代碼換行符的問題。
一旦換行符與源倉庫的不一致時，git 會認為這次修改是刪除后重來的，這樣會給 code review 帶來巨大的麻煩。
就像這樣，明明我改動的行數并不多，但 git 確認為你是推翻了重來，導致審核起來根本不知道你改了哪些地方。
最簡單的方法就是設置自己 git 的全局配置，可以參考這里。
# 提交時轉換為LF，檢出時轉換為CRLF
git config --global core.autocrlf true
# 提交時轉換為LF，檢出時不轉換
git config --global core.autocrlf input
# 提交檢出均不轉換
git config --global core.autocrlf false
確認沒問題后便可點擊這里發起 pull request，后面按照引導執行即可。
當然各個項目之間還會有自己定制的貢獻流程，最好就是查看官方的貢獻指南。
http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html
Code Review
pr 發起后便可等待社區審核了。
在這過程中要充分和社區進行交流，有可能你的方案和社區的想法并不一致。
比如像我這次：
最終通過溝通加上自己后面的思考覺得還是社區的方案更加輕便合理一些，達成一致之后社區便將這次 pr 合并進 master 中。
其實整個過程我覺得最有意義的便是 code review 的過程，所有人都可以參與其中頭腦風暴，其中也不乏技術大牛，不知不覺便能學到不少東西。
類似案例
雖然我之前的方案沒有被采納，但類似的用法（一個線程監控其他線程）還是不少，正好在 Dubbo 中也有用到。
便是其中核心的服務調用，默認情況下對使用者來說這看起來是一個同步調用，也就是說消費方會等待 PRC 執行完畢后才會執行后續邏輯。
但其實在底層這就是一個 TCP 網絡包的發送過程，本身就是異步的。
只是 Dubbo 在你不知道的情況下做了異步轉同步，這樣看起來就像是一個同步方法。
如圖中的紅框部分，Dubbo 自身調用了 get() 方法用于同步獲取服務提供者的返回結果。
邏輯其實也挺簡單，和我上文的方案類似，只是這里的 isDone() 函數返回的是是否已經拿到了服務提供者的返回值而已。
總結
本次總結了參與開源的具體步驟，其實也挺簡單；就如官方所說哪怕是提個 Issue，修改一個錯別字都算是參與，所以不要想的太難。
最后還簡單分析了 Dubbo 調用過程中的異步轉同步的過程，掌握這些操作對自己平時開發也是很有幫助的。
你的點贊與分享是對我最大的支持
