起因是因為日誌裡經常報出鎖等待超時的錯誤，並且這個是環環相扣的，乙個鎖等待會直接引發另外的鎖等待，所以危害非常嚴重，影響非常深遠。尋找原因發現是c3p0報出了deadlock，如下圖所示：
可以看出來scatteredacquiretask，也就是獲取連線的任務，全部卡在那不動了。那顯然是無法獲取新的資料庫連線了。正好前一天剛剛進行過架構上的調整——從應用直連mysql變化到中間新增了一層cobar（關於cobar，它是乙個mysql**中介軟體，用來處理分庫）。猜測就是切換到cobar的問題，但是究竟是什麼問題呢？下面我們來一起分析一下：
首先是切換到cobar前的伺服器結構圖：
n臺應用 –> 1臺mysql
下面是新增cobar後的：
n臺應用 –> 2臺cobar -> n臺mysql
那麼兩者之間到底有什麼區別呢？我在本地做了乙個測試，將c3p0的初始連線數設定到5000，也就是模擬在大量的連線請求下資料庫的反應，看看是否會出現scatteredacquiretask卡住的情況。5000個連線建立完成了，但是出乎意料的是，我用show processlist檢視mysql執行緒時，居然並沒有看到執行緒的增長，而是和剛才一樣。到這裡我差不多已經意識到了問題所在，為了證實這一點，我又用直連資料庫的方式起了5000個連線，這次資料庫連線果斷就上去了。恩，看到這裡大家應該也都猜到了吧，與cobar建立連線，並不表示與mysql建立連線，其實在我們的應用到mysql這段道路上存在著兩個「池」，乙個是我們應用和cobar之間的資料庫連線池，還有乙個是cobar和mysql之間的連線池。應用和cobar之間的連線數並不存在瓶頸，並且我們也知道它們之間是用nio通訊的。但是cobar和mysql之間呢？oh，由於cobar只實現了一半的nio，所以和mysql之間還是走的bio。
這裡還需要說明的一點是，我們公司的cobar伺服器是dba來搭建和維護的。所以對我們後端開發來說所有的配置都是不透明的，我們不熟悉cobar的配置也不知道有哪些東西可配置。但是憑藉剛才的猜想，已經差不多知道瓶頸就是cobar和mysql之間。
並且事後在檢視cobar的alarm日誌時，發現出問題的時間段內正好打出如下的日誌，也更加證實了我的猜想！
記使用sed的一次坑
sed做為linux下的三劍客，自然功能強大，但是如果使用不當，反而適得其反，今天就因為這個命令採了很深坑，分析一下原因，以諫後來者。情景回顧 專案中使用的乙個python爬蟲採用的是多執行緒併發爬取，輸入為乙個存放url的檔案，因為程式隨時可能停止，所以每次重啟程式的時候需要將以爬取過的url去除...
記hibernate一次坑
在使用hibernate反轉工程時有乙個坑放在這裡，避免大家跳進去。本人用的是myeclipse2017ci，在使用hibernate反轉工程生成原始dao方法時碰到的bug。在方法public account findbyid long id 中有一段 及其坑爹 log.debug getting...
記Ansible的一次坑
兩台虛擬機器 a 主機名為ansible b 主機名為web 當a執行ansible web m shell a echo 時 結果為ansible,當執行ansible web m shell a echo 結果卻為ansible只是換了個引號結果卻不相同。這是因為ansible的工作過程如下 書...