每週總結第1期(2019061020190616)

NO IMAGE

hello,各位好久不見啦。由於換工作,找房子這一系列事情都推在了一起,所以最近停更了一個多月。現在所有的事情都已塵埃落定,我也可以安安靜靜的碼字(裝X)啦。

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

話不多說,咱開始啦。

.split(“.”)為什麼不起作用?

首先來說一下背景,需要查詢名稱為“XXXX”的數據,並且為第二級路徑,他的路徑bh為String類型的,以”.”隔開。數據結構簡化如下:

每週總結第1期(2019061020190616)

做法一目瞭然啊,先通過名稱查詢所有滿足條件的記錄,然後for循環這個list,如果路徑用split生成的String數據長度為2,那就是要找到的記錄。

於是我就愉快的寫代碼(bug)啦,然後就華麗麗的踩坑了。

找到了名稱為“XXXX”的數據list,接下來就是遍歷啦。然後我發現split出來的length始終為0。

迅速百度,找到了答案。

裡面的參數要的是正則表達式,點在正則表達式中.是有意義的
正則表達式,本來是要寫成\.,但因為是JAVA中,\又是轉義符,所以要再加一個,就成了
\\.

所以用.split(“\\.”)或者[.]就行。

106 comparison method violates its general contract

今天群裡貼了一張圖,說線上環境報錯了,我一看,就是我寫的bug啊,可是本地跑的,沒啥問題的。具體問題如下圖。

每週總結第1期(2019061020190616)每週總結第1期(2019061020190616)

百度了一波,知道了原來我本地使用的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值就行。

相關文章

扒一扒InnoDB數據在硬盤上是如何存放的

探究MySQL各類文件

InnoDB體系架構

淺談MySQL的整體架構