榆木，一個閱歷無數（踩坑）的技術宅男，喜歡了解新技術卻不愛太鉆研新技術（因為懶，猿屆反面角色一枚）。14年畢業至今，在Java開發這條道路上可謂是坑過好些人、也埋過好些坑、也被坑過好些次。因為懶，沒有針對他遇到過的問題做過太多的筆記（記錄一些棘手問題的解決方法還是個不錯的習慣），只是習慣性的去分析為什麽出現這樣的問題，我們該怎麽去避免重復出現。在這裏榆木share一下第一次做獨立需求的過程。

榆木·Java開發工程師

要成為一個合格的Java程序猿，獨立完成需求是一個必須經歷的階段，在這個過程中可能會遇到很多問題，要學會合理的利用資源（官方文檔、社區論壇等）去解決問題。在這個階段應該是踩坑最多、收獲最多、成長最快的階段。

在榆木入職的前3個月裏，做的都是一些改bug、完善需求的活，他不需要太多思考，根據客戶說的做就成了。三個月之後他的公司順利拿下了該客戶的二期項目，由於人手不夠，再加上他在一期維護的時候對業務比較熟悉，老大便讓榆木獨自承擔該項目前置子系統的全部需求。剛開始的時候榆木是很激動的，隨之而來的卻是不知所措。

榆木都是如何踩坑又填坑的呢？分享一下他的幾點經驗，希望對開發者有所幫助。

如何同時開啟兩個SVN服務

因為公司資源不夠，老大就要求在原有的服務器上再弄一個SVN服務，於是他開始各種搗騰，可是不管怎麽樣就是沒有辦法同時起來兩個服務。怎麽辦，只能找哥哥（google）幫忙咯，因為SVN服務的啟動（/etc/init.d/svnserve start ）是包含一些默認參數，如 --listen-port指定服務端口 默認是3691，如果要同時起兩個SVN服務只需要在啟動時指定兩個不同的listen-port就OK了。

如下，問題解決：

/etc/init.d/svnserve start   -d -r /svn/repo  第一次第一個庫啟動  默認3691 /etc/init.d/svnserve --listen-port 9999 -d -r /svn/svndata  第二次指定端口啟動

問題搞定，緊接著就是緊張的代碼開發，事情有點想不到的順利，後端接口順利完工通過測試，榆木開始和前端對接聯調，好激動，搞不好可以提前完成任務了。劈裏啪啦的搞完就開始測試了。

fastJson序列化問題

所謂沒有遇到過bug的程序猿就不是正常的程序猿，一點都不意外，問題來了。同一個對象賦值給HashMap中不同的key 傳到前端後，第二個value竟然不能被正常解析....... 他自己寫的代碼必須不能慫，有問題那就解決問題，於是榆木開始找問題所在，開始模擬數據，發現返回結果如下：

{"o1":{"age":16,"name":"o1"},"2":{"$ref":"$.o1"}}

很容易就能看出來，第二value在這個返回結果中用類似指針的方法（"$ref":"$.o1"）表示它和“o1”的值一樣，看起來像是同一個對象的循環引用哦，那是不是可以把這個循環引用禁止呢？答案是可以的。（有必要說明一下，這裏使用的是fastJson）通過SerializerFeature指定禁用循環依賴就可以了。修改前代碼如下：

public static void test1() {         TestObject object = new TestObject("o1", 16);         Map<String, TestObject> map = new HashMap<String, TestObject>();         map.put("o1", object);         map.put("o2", object);         System.out.println(new String(JSON.toJSONBytes(map)));     }

輸出結果：{"o1":{"age":16,"name":"o1"},"o2":{"$ref":"$.o1"}}

在一個集合對象中存在多條相同數據時，將ist集合對象轉化為json對象輸出到前臺時，JSON默認對第二條數據處理時用"$ref":"$.object".<這裏object指第一條數據>，這樣的json轉化結果輸出到前臺肯定是不可以使用的，好在JSON有提供禁止關閉引用循環檢測的方法，只需要在轉化的時候加上SerializerFeature.DisableCircularReferenceDetect 就可以解決了。修改後代碼如下：

public static void test1() {        TestObject object = new TestObject("s1", 16);        Map<String, TestObject> map = new HashMap<String, TestObject>();        map.put("o1", object);        map.put("o2", object);        SerializerFeature feature = SerializerFeature.DisableCircularReferenceDetect;        System.out.println(new String(JSON.toJSONBytes(map, feature)));    }

輸出結果如下：{"o1":{"age":16,"name":"o1"},"o2":{"age":16,"name":"o1"}}

到這裏問題就解決了。不久之後測試通過了，交付客戶測試版本，開始和中心聯調測試了。

OOM異常處理

榆木以為到這裏就萬事大吉了，然而是不可能的。聯調測試兩天之後，客戶反饋說：“我們的XXX報文數據已經往中心發過了呀，可是中心說他們沒有收到，你們查下是什麽問題唄！”客戶就是上帝呀，榆木和他的同事開始查詢日誌，發現有一些OOM的異常。異常產生的場景是在取數據-組報文-MQ轉發這個環節，然後就開始一個一個點的排查了。

榆木首先想到的可能原因有：

1、數據取出來生成報文這個過程都是在內存中做的，會不會是這裏數據太多導致？

2、會不會是報文生成過程產生了過多Object沒有來得及回收？

3、會不會是數據發送慢於報文生成的速到導致等待隊列爆滿？

然後開始針對性的做修改測試，他將一次性取數據生成報文的過程改成批量去做，然後測試運行一段時間沒有問題（排除 1）；在生成保溫過程中，將每一個轉化後的對象置為空Object=null，以便及時回收，測試運行一段時間沒有問題（排除2）；在第三點上面，他最先想的是增加線程數量（ 服務器開啟超線程、應用中增加線程數量）去提升處理速率，運行一段時間之後還是會出現OOM。怎麽辦呢？再次回到了等待隊列上面來，能不能在一定程度上對等待隊列做個限制呢？於是榆木在每次從MQ取消息之前增加了對等待隊列的深度的判斷，如果深度大於最大線程數量的2倍，就放棄本次MQ隊列消息的處理。然後繼續測試，問題沒有再出現。

查詢慢怎麽辦？

最終項目上線了，終於可以松一口氣了。可是有一天，榆木的老大說客戶反映部分查詢很慢，讓他去處理一下。榆木心裏想著，這個應該是個小問題，給數據表加索引就能搞定。到了客戶現場之後發現，原來的表是有索引的，可查詢還是慢，不得已只能去找原因了。不得不說，explain SQL是個不錯的命令，發現索引沒有生效，經過仔細的比對，發現該關聯查詢的關聯字段在兩個表中都有索引， 兩個表的字符集都是UTF8，但是排序規則一個是utf-bin（二進制存儲數據，大小寫區分）,一個是utf8_general_ci（大小寫不敏感），所以把數據排序規則改成一致索引生效，查詢速度也就上來了。

PS: mysql中的UTF-8編碼的排序規則說明

utf8_bin將字符串中的每一個字符用二進制數據存儲，區分大小寫。

utf8_genera_ci不區分大小寫，ci為case insensitive的縮寫，即大小寫不敏感。

utf8_general_cs區分大小寫，cs為case sensitive的縮寫，即大小寫敏感。

【寫在最後】

榆木整理了下這些年踩的坑，給自己也給正在和他掙紮在挨踢坑裏的小夥伴們一些啟發與鼓勵。持續學習是保持競爭力的前提；夯實的基礎是進階的墊腳石。擡頭走不獨行（exchange）、埋頭幹（code），就算被稱作屌絲，也還是要有夢想，萬一逆襲了呢。

如果你也願意分享你的故事，請加51CTO開發者QQ交流群 114915964聯系群主小官，期待你精彩的故事！

挨踢部落故事匯(32): Java深坑如何填？