2020.8.18
上午10:00，開始召開回顧會議。
經理讓大家先評價一下之前專案中做的好的地方與不好的地方，然後進行了總結。
其中本人感覺印象較深的幾點如下：
1.專案初期任務拆分與任務時間預估的不太好，出現了專案後期才發現有任務沒有人做、臨時找人補做的情況；還出現了有人做完後沒有任務、有人的任務需要大量時間才做完的情況。
2.每天早晨的站會效果比較好，大家可以提出問題，共同解決；還可以正確把握專案進度。
3.評審會議前對測試資料的處理不好，由於資料較多導致評審會議上執行大批量任務時執行不完，流程無法走通；應該提前清空一次測試資料，並準備少量的測試資料，在評審會議上跑通一次流程才行。
4.svn提交**時要寫明需求號，並且盡可能減少commit次數，否則會導致後期從開發**merge到生產**時遇到困難。（由於merge時是按照每一次commit去合併的，如果次數較多會導致需要合併很多次；如果沒有寫明需求號，會無法確定這次commit是否可以進行**合併）
回顧會議上午11:30結束，緊接著下午14:00就召開了新需求會議。
會議中提出了12個新需求，各個需求基本互不相關，其中預計開發時間最長的需求有10天（2周），也就是1-2人負責乙個需求，大概2周可以全部開發完。
會議上提到，所有需求與完成進度都要登記到內網上的敏捷任務版中；如果有需求變更，要向領導反應，領導會將其修改為下乙個開發流程中的新需求（也就是這次不管需求變更的事情，否則會導致開發混亂，完成時間延期）。
16:30會議結束後，大家將新需求登記到了敏捷任務版上，然後準備明天確認自己要領哪個需求。
關於對大批量的特殊處理，也就是進行了sql優化（使用foreach，將原本j**a中的迴圈移動到sql中等）、資料庫表使用索引、使用定時任務+手動處理錯誤的邏輯這些了，j**a**中並沒有怎麼特殊處理，甚至連事務都沒有用到（起碼本人自己沒有用到）。
至此，大批量推送專案日記告一段落。
大批量推送專案日記（二） 遇到的問題與解決方法
2020.8.4 今天，本人將自己負責的模組基本開發完了。本人負責的模組是，從資料庫中查詢出待推送的資料來，呼叫推送介面給使用者推送訊息，之後更新資料庫。雖然涉及到了大批量推送，但是本人的 暫時還沒有進行相應特殊處理 準備先把基本功能實現了，然後再說。暫時使用簡單的執行緒 for迴圈的方法實現的。遇...
Spring Hibernate處理大批量資料
原文 關於使用spring hibernate進行大批量資料的插入和更新，它的效能和使用jdbc preparedstatement的batch批量操作以及資料庫的儲存過程操作幾乎可以一樣高。在hibernate的官方文件裡說到了batchprocessing。spring hibernate大批量...
關於SXSSFWorkbook匯出大批量資料的問題
前段時間做了乙個匯出大批量資料的功能，但是由於資料過多使用sxssfworkbook會出現記憶體溢位的問題，主要有兩個地方容易溢位。1.乙個是從資料看讀取資料到記憶體時溢位，基本資料超過20w或者2m時會溢位 這個時候改 xms1024m xmx1024m xx permsize 512m xx m...