最近的項目，為了保障絕對的一致性，使用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;
報錯的概率并不高，在我們的系統中，大概只有2%的概率左右出現。
單獨執行這段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;
兩個事務同時開啟，當執行到level_1的時候停住，注意觀察數據庫的輸出
level_1
這個時候一切正常
我們繼續往下執行事務A，如圖
level_2.png
我們發現事務A卡住了。
再繼續執行事務B，死鎖出現了。
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繼續執行update操作時，由于事務A又擁有id = 1的讀鎖A，因此進入互相等待狀態，造成死鎖。
解決方案：
1 將select操作改為select for update，直接加寫鎖。
2 在業務層將此種類事務串行化。
