每週總結第 1 期（20190610-20190616）

hello，各位很久不見啦。因爲換工做，找房子這一系列事情都推在了一塊兒，因此最近停更了一個多月。如今全部的事情都已塵埃落定，我也能夠安安靜靜的碼字（裝X）啦。

從這周開始，多了一個系列是每週的總結，今天是第一期哦。每週總結主要是平時工做中遇到的問題，有時候百度了很久才找到的答案，不記錄一下，下次又要花時間百度啦。

話很少說，咱開始啦。

.split(".")爲何不起做用？

首先來講一下背景，須要查詢名稱爲「XXXX」的數據，而且爲第二級路徑，他的路徑bh爲String類型的，以"."隔開。數據結構簡化以下：

作法一目瞭然啊，先經過名稱查詢全部知足條件的記錄，而後for循環這個list，若是路徑用split生成的String數據長度爲2，那就是要找到的記錄。

因而我就愉快的寫代碼（bug）啦，而後就華麗麗的踩坑了。

找到了名稱爲「XXXX」的數據list，接下來就是遍歷啦。而後我發現split出來的length始終爲0。

迅速百度，找到了答案。

裏面的參數要的是正則表達式，點在正則表達式中.是有意義的 正則表達式，原本是要寫成\.，但由於是JAVA中，\又是轉義符，因此要再加一個，就成了 \\.

因此用.split("\\.")或者[.]就行。

106 comparison method violates its general contract

今天羣裏貼了一張圖，說線上環境報錯了，我一看，就是我寫的bug啊，但是本地跑的，沒啥問題的。具體問題以下圖。

百度了一波，知道了原來我本地使用的jdk1.6的版本，而線上環境使用的是jdk1.7的版本，這個報錯正好是jdk1.7以上版本會出現的。

下面舉個例子：

@Override
public int compareTo(xxx o) {
   return this.getPublishTime().getTime() < o.getPublishTime().getTime() ? 1 : -1;
}複製代碼

上圖的代碼在jdk1.6的版本是正確的，由於1.6的版本沒有對排序大小進行嚴格的校驗，只有1和-1，沒有0。而1.7的版本使用了新的排序算法timsort，是對排序大小進行嚴格校驗的。簡單來講，這個算法在實現過程當中明確須要用嚴格的單調遞增或者遞減來保證算法的穩定性。

因此在上述代碼加上判斷，多返回0值就行。