最近的項目，為了保障絕對的一致性，使用SERIALIZABLE作為隔離級別。
然后就爆出了很詭異的死鎖婶肩。
報錯log如下：
org.springframework.dao.DeadlockLoserDataAccessException: PreparedStatementCallback; SQL [xxxxx]; Deadlock found when trying to get lock;
try restarting transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
1461 2017-04-17 21:58:26.550 ERROR pool-7-thread-2
我們的sql大概是這樣的：
begin;
select * from table_a where id = 6;
INSERT INTO xxx (xxxxx) ON DUPLICATE KEY UPDATE xxxxx;
UPDATE table_a SET column_a = GREATEST(column_a, 0) WHERE id = 6;
commit;
報錯的概率并不高，在我們的系統(tǒng)中貌夕，大概只有2%的概率左右出現(xiàn)律歼。
單獨執(zhí)行這段sql并不會有任何問題，因此定位了許久啡专。后來靈光一下险毁，同時開啟兩個事務來模擬這個操作。
方式如下：
//準備工作
1 set session transaction isolation level SERIALIZABLE;
2 create table user (id int PRIMARY KEY, age int) engine = innodb;
3 insert into user values(1, 2);
分別開啟兩個事務
//事務A
begin;
select * from user wherer id = 1;
//A level_1
update user set age = 3 where id = 1;
//A level_2
commit;
//事務B
begin;
select * from user wherer id = 1;
//B level_1
update user set age = 3 where id = 1;
//B level_2
commit;
兩個事務同時開啟们童，當執(zhí)行到level_1的時候停住畔况，注意觀察數(shù)據(jù)庫的輸出
level_1
這個時候一切正常
我們繼續(xù)往下執(zhí)行事務A，如圖
level_2.png
我們發(fā)現(xiàn)事務A卡住了慧库。
再繼續(xù)執(zhí)行事務B跷跪，死鎖出現(xiàn)了。
dead_lock.png
原因：
究其原因齐板，是SERIALIZABLE隔離級別讀寫鎖競爭導致的吵瞻。
在SERIALIZABLE級別下，不會使用mysql的mvcc機制甘磨，而是在每一個select請求下獲得讀鎖橡羞，在每一個update操作下嘗試獲得寫鎖。
在我們的例子中济舆，在level_1中卿泽，事務A獲得了id = 1的讀鎖A。
而在同時滋觉，事務B獲得id = 1的讀鎖B签夭。
在事務A level_2時，事務A嘗試獲得id = 1的寫鎖椎瘟，這個時候覆致，由于id = 1處不僅有事務A的讀鎖，還有事務B的讀鎖肺蔚，因此事務A的update操作獲取鎖被阻塞。
此時儡羔，當事務B繼續(xù)執(zhí)行update操作時宣羊，由于事務A又擁有id = 1的讀鎖A璧诵，因此進入互相等待狀態(tài)，造成死鎖仇冯。
解決方案：
1 將select操作改為select for update之宿，直接加寫鎖。
2 在業(yè)務層將此種類事務串行化苛坚。
