工作總結
發表時間：2026-04-232026年試用期轉正工作總結。
接手核心模塊的第三周，凌晨兩點，值班電話響了。監控顯示，某數據解析服務的CPU占用率從15%直線拉到了98%，響應時間從300ms變成4.5秒，而且還在漲。我坐在工位前，手邊是下午倒的那杯咖啡，早涼了。運維群里有人@我：“是不是新版本的問題？”我沒急著回復，先開了三個終端：一個看top，一個看jstat -gcutil，一個準備dump堆內存。
問題定位比想象中快。jstat輸出顯示，YGC次數正常，但FGC每分鐘達到了12次，單次暫停2.1秒。這不對勁。jmap -histo:live的結果讓我皺了眉——java.util.HashMap$Node的實例數超過了42萬個，其中絕大多數來自一個叫ContextHolder的類。翻代碼，發現每次請求都會新建一個解析上下文存入HashMap，但只有正常流程走了release()，異常路徑直接返回，占用的資源沒人管。并發一上來，HashMap越堆越大，GC自然扛不住。
改法不復雜：第一，在finally塊里強制調用release()，無論是否拋異常；第二，把HashMap換成Guava的CacheBuilder，設置60秒過期，最大容量5000；第三，寫了一個定時任務，每10秒掃描一次未關閉的上下文，數量超過100就往日志里打一條WARN。上線后壓測，同樣800并發，響應時間P99穩定在420ms，FGC降到了每小時不到2次。這個事讓我養成了一個習慣——以后但凡涉及資源持有類的代碼，先問一句：異常路徑釋放了嗎？
不過，真正讓我記住教訓的，不是這次性能優化，而是一次定時任務的翻車。
試用期第二個月，主管讓我優化一個凌晨跑的日志聚合任務。原腳本跑40分鐘，我看了SQL，發現索引用不上，全表掃描。重寫之后，加了覆蓋索引，又改成分批查詢，壓測環境跑12分鐘就完了。我挺得意，周五晚上直接發了上線單。周六早上還沒睡醒，手機就炸了——數據庫CPU 95%，持續了20分鐘。沖到公司，打開慢查詢日志，發現新SQL里多了一行我根本沒注意到的SELECT ... FOR UPDATE。為了“保證數據一致性”，我順手加了行鎖，結果把整張統計表鎖了20分鐘。而早高峰，另一個寫入業務正好要更新同一張表，全部堵死。
主管沒罵我，只說了句：“下次改SQL之前，先把鎖影響范圍評估一下，寫出來。”那天下著小雨，我坐在工位上，把FOR UPDATE的觸發條件、鎖粒度、持有時間一條條列出來，貼在團隊文檔庫里。后來我又加了一條硬性規定：所有涉及大批量更新或行鎖的腳本，必須在預發環境跑一次并發模擬，輸出“鎖影響評估報告”才能上線。這條規定，現在還在用。
設備維護方面也有一件事值得提。一臺工控機頻繁重啟，系統日志只有“watchdog timeout”四個字。廠家說換主板。我沒同意，拿了熱成像儀掃了一圈，發現南橋芯片旁邊一顆電容表面溫度比旁邊的高了12℃。示波器一量，紋波超標三倍。換掉那顆電容，機器連續跑了43天沒再重啟。這事兒讓我明白一個道理：故障排查不能只盯著日志，硬件層面的溫度、電壓、振動這些物理量，有時候才是真兇。
轉正答辯前一周，有個運維同事在群里@了我：“新版本跑了三天，一個告警都沒有，穩了。”就這一句話，我覺得比什么評語都實在。
回頭捋這三個月，真正沉淀下來的東西，不是某個具體的代碼片段，而是幾條能復用的操作習慣：
- 【讀書筆記吧】編輯們的行業風向標:
- 采購轉正試用期工作總結?|?試用期轉正答辯工作總結?|?采購試用期轉正工作總結?|?安檢試用期轉正工作總結?|?2026年試用期工作總結?|?試用期轉正工作總結
排查故障先畫范圍。比如那次CPU飆升，我第一步不是看代碼，而是用top -H -p找線程號，再用printf "%x\n"轉成十六進制，最后到jstack里定位具體代碼行。三步下來，問題出在哪個類的哪一行，清清楚楚。這叫“二分法”——不是猜，是拿工具切。
質量驗收要量化，不寫“性能良好”。每次壓測，我會在報告里明確寫：95%請求在200ms內完成，連續72小時無內存泄漏，FGC次數不超過5次。數字擺在那，過就是過，不過就是不過。
技術復盤必須輸出動作。那次鎖表事故之后，我不光記住了“不要亂加FOR UPDATE”，還寫了一個檢查腳本，自動掃描SQL里的鎖關鍵字并告警。每條反思，最后都要落到一個可執行的工具或規范上，不然就是白反思。
試用期結束了，但那些凌晨查日志、現場焊電容、一條條核對SQL鎖范圍的日子，已經把“嚴謹”兩個字磨進了骨頭里。現在手里攥著三份自己寫的檢查清單、兩個自動化腳本、一套壓測模板，下次再遇到類似問題，不用慌，照著流程走就行。
- 想了解更多【工作總結】網的資訊，請訪問：工作總結
