服務是正常的，有個service有的時候能依賴，有的時候沒有找到依賴(no named bean 'XXXXservice' defined)

 1、 排查思路一: 服務是正常的，偶爾找不到依賴，懷疑是部署的問題，通知運維重新部署，問題依然存在；

 2、 排查思路二: 檢視代碼重新驗證，本地再次驗證，測試環境再次驗證一切正常的，懷疑是生産代碼沒有部署上去，

 但是服務偶爾是正常的，兩個思路有點互斥，但是是排查問題，隻能看生産的部署代碼，拉生産代碼反編譯檔案，發現代碼确實是最新的,

 問題依然存在，繼續排查;

 3、 排查思路三: 生産項目部署環境，單台伺服器，兩個tomcat,nginx做的負載均衡; 由上面排查思路一可猜想到是否是某個tomcat的代碼沒有更新的，

 找運維确認，用的多執行個體部署，這裡多執行個體指的就是兩個tomcat用的一個路徑的代碼，運維确認沒問題，不然服務會一直報錯的；

 4、 排查思路四: 堅持自己的想法，按照自己的思維排查，不受其它人的幹涉，其它的人提供的資訊隻是用于問題定位;繼續排查，

 找運維切換tomcat，tomcat逐個測試，最後發現一個tomcat是正常的，和測試環境一樣的，

 另外一個tomcat一直報依賴沒有定義(no named bean 'XXXXservice' defined)，如此這樣問題已經定位:負載均衡的一個tomcat的代碼還是老代碼；

 5、問題解決:  經過以上，問題已經定位，接下來就是問題解決了。思路:既然兩個tomcat用的一個代碼路徑，為什麼一個是新代碼，一個是老代碼呢？

 顯然這是tomcat的緩存代碼，需要清理tomcat的緩存，清理tomcat緩存，觀察背景日志，發現問題解決！

 總結: 最後排查下來發現問題很簡單，就是tomcat的緩存，其實問題很簡單，但是這個問題本人卻排查了一天半，排查過來是繁瑣的，但是結果卻是美好的，

 總算排查出來解決了。但是仔細回想，如果不一步步定位問題，誰又能一下子确認具體問題所在呢，排查問題就是經驗累積的過程，相信下次在碰到這類奇葩問題，

 定位問題應該更快了。不管怎樣，這次排查問題雖曆時時間長，但是從中擷取的經驗還是很多的，感覺吃了一塊大肉！！