這是發生在我身上的乙個bug，困擾了我三天，已經讓我多次懷疑人生。因為我這個工作是資料準備階段，後續還有一系列工作需要依賴我這些初始資料，壓力很大，感謝某人在這個時候給我的鼓勵，雖然只是寥寥幾句。這件事記起來僅為日後提醒自己不再犯相同的錯誤。
簡單來說，我做的是乙個資料同步任務，將資料從es的乙個type經過轉換和操作同步到另乙個type中，下面統一說a同步到b，而且這個同步是週期性執行的，下面通過乙個流程圖：
迴圈的部分的流程圖不標準，大家懂意思就可以，程式其實很簡單，除了引用的工具類，我就用了乙個類就完成了上面的操作，每乙個過程是乙個方法，方法結束後也會列印相應日誌，而且測試網經過測試也是沒問題的（這句話是不是很熟悉，如果你經常這麼說，那就小心了），結果到了生產網就出事了，具體兩個奇怪現象：
首次同步的時候，b端少資料
再次同步的時候，b端有重複資料
因為b端開始是沒資料的，所以出現上面兩個問題只可能是我程式的問題。
出現問題後，我直接蒙了，心想絕對不可能，然後一遍一遍的看程式，因為就乙個類，所以看了好多遍，因為重複資料我是絕對認為不可能的，所以我的關注點就放在了怎麼可能有重複，我的思路是兩邊全部查出來，以主機名加ip為key，value為本身，放到map中。然後進行比較的。
我把整個處理類重新寫了一遍，去掉了其中用到的lambda表示式，現在想想有點可笑，我懷疑lambda表示式有bug。
我把所有處理路徑列印上日誌，數量也都列印出來。
經過這樣後，依然沒有發現問題，資料平白無故丟失，重複資料出現的莫名其妙，因為生產網不能隨意測試，所以每次出錯都很難過，而測試網又復現不了（測試網資料是偽造的），心都碎了，最後又重新看**，決定列印最詳細的日誌。主要是兩個地方：
map的put操作前，先containskey一下，如果有，列印日誌說已有資料
之前列印數量日誌的，全部列印實際內容
第二步，按我之前的風格，是絕對不會這麼做的，感覺太低階，但是這麼實在是沒有辦法了，然後重新測試，仔細看日誌，發現乙個異常現象，資料實際內容沒有看，太多了，異常的是出現大量的已有資料的日誌，這點引起我的注意，我核實過資料來源，我這邊提示重複的資料，在資料來源處只有乙個，然後我就去看我的工具類，查詢工具類，發現了問題，程式如下：
batchsize在前邊定義的為1000，及1000個批次查詢一次仔細看標紅那一行，我終於找到錯誤原因了，我的同步類沒有錯，查詢es的工具類寫錯了，改了以後重試才可以。******************************==
public
static listqueryall(string index,string types)
else
//通過 from 和 size 查詢資料 並放到result中
from +=size;
} return
result;
}
平時積累一些工具類，確實可以大大減少一般開發的工作量，但是一定要經過嚴格的測試，不然基於對工具類的信任，很少會懷疑工具類會出錯。
對於資料處理，如果假定不會有相同資料，也要containskey一些，因為往往會有意想不到的資料產出，這種情況下出錯了還不好查詢。
學習演算法遇到的疑難雜症
1 delete動態陣列 如果delete的時候出現執行時錯誤，可能是之前發生過陣列越界 int main delete a return 0 2 快排 在座標向中靠攏的時候除了比較和當前選中的數的大小外，還要判斷邊界 while i j 3 歸併排序 最後一步合併時，臨時陣列和目標陣列的下標不是同...
程式設計遇到的疑難雜症集合
看了很多年csdn，從沒寫過文章。前段時間群裡說如果把我會的東西寫出來，能幫到很多人。所以這次嘗試著寫寫。如有錯誤，還請指正。ora 01861 literal does not match format string 2019 12 30 錯誤 to date begindate 00 00 00...
mybatis foreach的疑難雜症
背景 今天寫 的時候，寫了一段sql，如下所示 select product name,product type,subscription id,product period,subscription begin,interest begin,interest end,subscription st...