最近解決了乙個生產bug，bug的原因很簡單，就是清理快取的方式不對。本來沒啥好說的，但是考慮到我們有時候確實會在一些小問題上栽跟頭，最終決定把這個小故事拿出來跟大家分享下。
風起常規操作
和以往一樣，我查起了生產log，發現是資料庫鎖表了。客戶是業務型公司，一般不會出現多人同時操作的情況，資料量也不大，生產上從來沒有出現過，倒是我本地除錯的時候經常因為性子急多點幾次導致鎖表，因此感覺這個問題很好解決，讓管理員把鎖解了就行了。
雲湧
沒有鎖了，讓客戶再試下，客戶的反饋「還是報錯」，沒道理啊。再查日誌，發現已經沒有了堆疊資訊，為啥還不行呢。
沒辦法只能看那個時間段所有的log，發現有一行「map快取中有資料，可能多人同時操作」。
查下**，發現**中為了防止同一條資料多人同時操作，加了map作為快取，資料記錄的pk作為key和value。
（記住這個圖，後面會考）
每次操作的時候將資料put進map，處理完後remove掉。如果map中有相關kv就表示這條記錄有人正在操作，則其他人不能操作，拋提示資訊。
於是乎問客戶「多人同操乎？」，得到的答覆是「否」，納尼？怎可能。日誌是不會騙人的啊
再查**
針對map再把**看一遍，看它put和remove的地方，還有日誌列印的地方。終於發現乙個問題，
map的清理動作是在try裡面正常處理後做的，如果出現異常就不能正常清理了，而map定義的時候為了物件間共享定義成了靜態成員變數，
剛才的鎖表拋了異常，當時已經put進入到map裡面的kv就一直沒有機會清掉了，也就是說只要服務不重啟，問題會一直堅定的陪著你。
對症下藥
1.跟領導申請緊急重啟服務，保證業務正常進行。
2.修改問題**，將報錯放到finally塊。
3.橫展開調查其他類似**是不是也存在這個問題，一併修改。
風平浪靜
問題解決，對方表示感謝，我也回覆不客氣，一切回歸平靜。
總結
其實這個快取清理的問題本身很簡單，大家都懂，就和釋放資料庫連線等情況一樣，需要放到finally塊裡面，
這個即使**拋異常了也能正常釋放或清理。但是就是擼這段**的時候，因為這樣那樣的原因一時沒有想到。
如果公司有**review的環節的話會好很多，如果沒有review，那麼在寫完**後最好自己review一遍。
否則，萬一出現類似的問題真的有點尷尬，正如題目所說「清快取的姿勢不對，真的會出生產bug哦」。
希望你我今後都能避免這種情況的發生。
使用快取的正確姿勢
快取是現在系統中必不可少的模組，並且已經成為了高併發高效能架構的乙個關鍵元件。這篇部落格我們來分析一下使用快取的正確姿勢。一般來說，快取有以下三種模式 通俗一點來講就是，同時更新快取和資料庫 cache aside 更新模式 先更新快取，快取負責同步更新資料庫 read write through ...
如何清weblogic的快取
有的說清 bea user projects domains internal domain servers adminserver tmp wl user目錄就行了，而有的說要清 bea user projects domains internal domain servers adminserv...
firefox chrome的DNS快取清除方法
通過設定hosts檔案可以強制指定網域名稱對應的ip，當修改hosts檔案，想要瀏覽器生效，最直接的方法關閉瀏覽器後重新開啟 如果不想重啟瀏覽器，只需要清空瀏覽器的dns快取即可。清空dns快取在chrome firefox下很容易做到。具體操作如下 chrome 在瀏覽器的位址列中輸入 chrom...