前言
繼上一篇協助調教批次程式處理緩慢與OOM問題之後，程式也進行到了測試階段。因為引用了多執行須改寫程式碼，其中有些邏輯的簡化調整，目前進行大資料量的測試，以及比對新舊程式產出結果階段。
遭遇問題
在測試過程中，因為需要額外的檔案產出，當中因多執行序競爭產生了檔案鎖定的問題，讓程式無法正常運行。這是因為在多執行序的環境中，當多個執行緒同時嘗試訪問同一個檔案時，會導致檔案鎖定的問題。這種情況下，只有一個執行緒能夠成功訪問檔案，而其他執行緒則會被阻塞，直到該檔案被釋放。
一開始沒考慮到大量資料在多執行緒同時寫入檔案的過程中，會導致死鎖情況的發生，因此從原本設計不斷開檔寫入資料的方式進行了調整，改為使用非同步寫入的方式，所有欲寫入資料放入BlockingQueue裡面，再交由獨立執行緒進行處理，以解決問題。
進行效能測試
目前測試結果據說原程式原本處理3百多萬筆資料需要花費5個多鐘頭(實際時間周一可得到確認)，而在調整後的程式中，經過測試後發現，處理3百多萬筆資料只需要花費1個多鐘頭的時間。這樣的效能提升是相當可觀的，周一我會再進一步進行調整後程式測試，看是否能降到1個鐘頭內處理完成。
同事的建議
過程中有同事建議為何不使用Store Procedure來進行資料的處理，這樣可以減少資料傳輸的時間，並且能夠更有效地利用資料庫的效能。我不否認這個建議是值得考慮的，因為在某些情況下，使用Store Procedure可以顯著提高效能，特別是在處理大量資料時。
但一個好的效能調教方式是需要根據具體情況進行調整的，並且應該考慮到系統的整體架構和需求。原本交給我的程式使用Java來處理資料，在處理效能議題上，我會選擇優先對原Java程式進行評估和調整，如何更好地利用現有的系統架構和資源，以達到最佳效能。並非接到一個效能調教的需求，就直接選擇Store Procedure來進行處理。
我認為較好的效能調教方式
好的效能調教方式應該是根據具體情況進行調整的，並且應該考慮到系統的整體架構和需求。以下是我認為較好的效能調教方式：
- 了解系統架構：在進行效能調教之前，應該先了解系統的整體架構和需求，以便選擇最合適的調教方式。
- 分析效能瓶頸：在進行效能調教之前，應該先分析系統的效能瓶頸，以便選擇最合適的調教方式。
- 選擇合適的調教方式：根據系統的整體架構和需求，選擇最合適的調教方式，例如使用Store Procedure、Java程式碼優化等。
- 測試和驗證：在進行效能調教之後，應該進行測試和驗證，以確保系統的效能得到了提升。
- 持續監控和調整：在系統運行過程中，應該持續監控系統的效能，以便及時調整和優化系統的效能。
在接手到的程式如果是使用Java來處理資料的話，我會優先對原Java程式進行評估和調整，將其效能提升至最佳狀態。若還是沒法達到需求的話，再考慮使用Store Procedure來進行處理。這樣的方式可以更好地利用現有的系統架構和資源，以達到最佳效能。畢竟使用Store Procedure或是用AP程式碼來處理資料，都是為了達到最佳的效能。若是原本的程式碼已經達到需求，那麼使用Store Procedure來進行處理就沒有必要了。
選用AP或Store Procedure來進行效能調教的方式，沒有絕對的好或壞，只有根據具體情況進行調整的方式。在不同架構下，應該根據實際需求和系統特性來選擇最合適的方案。
若遇到任何效能問題都用Store Procedure來進行處理，這樣的方式是不可取的。一來沒有分析過原本AP程式碼的效能瓶頸，二來也許調整了其他部分的效能後，問題就能得到解決。只用單一方案解決問題也會失去學習的機會。