? ? 從15年四月份開始，某項(xiàng)目組線上服務(wù)老反饋有服務(wù)掛掉問題，具體表現(xiàn)為服務(wù)不可用，但java進(jìn)程是存活狀態(tài)。經(jīng)排查，發(fā)現(xiàn)是大量寫操作線程在等待數(shù)據(jù)庫返回。當(dāng)時(shí)第一反映是數(shù)據(jù)表死鎖了，導(dǎo)致線程等待，因此先入為主地做了判斷，也如是交待項(xiàng)目組開發(fā)人員?，F(xiàn)在看來，技術(shù)人員最忌諱的是自以為是。

? ? 自此以為問題結(jié)束了，但4月份后，陸續(xù)會(huì)聽到類似的問題再出現(xiàn)，由于該項(xiàng)目我不直接處理，后續(xù)問題也未反饋到我手上，也不以為意，直到最近一個(gè)月，線上服務(wù)一再出問題，幾經(jīng)輾轉(zhuǎn)還是回到我手上了。

? ? 問題惡心的地方在于不能穩(wěn)定復(fù)現(xiàn)，折騰了一兩天，查了業(yè)務(wù)代碼，實(shí)在是太亂，加之現(xiàn)象十分詭異，通過oracle的視圖定位，竟然是select語句造成了行鎖，導(dǎo)致其他的update語句等待。查詢語句如下：

select ls.osuser os_user_name,ls.username?user_name,ls.type?lock_type,

o.object_name?object,decode(ls.lmode,1,null,2,'Row?Share',3,'Row?Exclusive',4,'Share',5,'Share?Row?Exclusive',6,'Exclusive',null)?lock_mode,o.owner,

ls.sid,ls.serial#?serial_num,ls.id1,ls.id2,ls.lockwait?from?sys.dba_objects?o,

(select?s.osuser,s.username,l.type,s.lockwait,l.lmode,s.sid,s.serial#,l.id1,l.id2??from?v$session?s,v$lock?l?where?s.sid=l.sid)?ls

where?o.object_id=ls.id1?and?o.owner<>'SYS'?order?by?o.owner,o.object_name

這個(gè)現(xiàn)象讓我十分崩潰，已經(jīng)超出了我的認(rèn)知能力，無法想象為何一個(gè)select語句能導(dǎo)致行鎖。沉下心來查oracle各種相關(guān)視圖，終于發(fā)現(xiàn)一點(diǎn)端倪：block session的狀態(tài)是inactive，這意味著block session已經(jīng)執(zhí)行完畢，只是未提交。這點(diǎn)通過java的線程也能得到佐證。為了進(jìn)一步驗(yàn)證，在oracle sqlplus開兩個(gè)客戶端，模擬相關(guān)操作，終于復(fù)現(xiàn)了一樣的場(chǎng)景。

? ? 接下來的事情變得簡(jiǎn)單些，排查java代碼中哪些事務(wù)未提交。最終發(fā)現(xiàn)，開發(fā)人員在使用nutz事務(wù)時(shí)，采用了非官方的寫法，而使用方式又有問題，導(dǎo)致事務(wù)未提交。