問題由來
假設在一個訂單系統中（以火車票訂單系統為例），用戶A，用戶B都要預定從成都到北京的火車票，A、B在不同的售票窗口均同時查詢到了某車廂卧鋪中、下鋪位有空位。用戶A正在猶豫訂中鋪還是下鋪，這時用戶B果斷訂購了下鋪。當用戶A決定訂下鋪時，系統提示下鋪已經被預訂，請重新選擇鋪位。在這個系統場景中，我們來探討一下，火車票系統是怎樣處理並發事件以及怎么利用鎖機制來避免重復訂票的。
設想的方案
方案1：
為了避免重復訂票，大部分人會想到在做訂票操作前，去數據庫查詢該鋪位是否已經被預訂，假設“鋪位”數據庫表增加標記字段FLAG（空閑：0；已預訂：1），如果查詢到鋪位的FLAG字段值為1,那么預訂就不成功，如果為0就成功預訂，並把FLAG置為1。這種方案如果在業務量很少的系統中，或許可行。但業務量較大時，特別是火車票這樣的業務量，就會出現問題。問題在，當用戶A、用戶B同時對同一鋪位預訂時，雖說是“同時”，但對於數據庫操作來說一定是有先后順序的，假設A在查詢該鋪位的FLAG時，值為0，准備預訂並將值設為1，而與此同時B已經預訂成功，並已將FLAG設為1。而A因為沒有即時查詢到FLAG=1，因此也預訂成功，又將FLAG設為1。
A FLAG=0 時刻=T1 （查詢）
B FLAG=0 時刻=T2 （查詢）
B FLAG=1 時刻=T3 （更新）
A FLAG=1 時刻=T4 （更新）
這樣就造成了重復訂票，在購票高峰期，使用這樣的方案，重復訂票不可避免。
方案2：
我們想到了利用數據庫的悲觀鎖來解決這個問題，設想假如用戶A查詢到想預訂的票，用戶B根本都查詢不到，只有A一個人能看到，那是不是沒有重復訂票的可能了，因為壓根沒人跟他搶。可以這樣實現這個方案：
select * from table where …… for update skip locked，該語句是查詢用戶指定條件的票信息，並加鎖（for update），如果有記錄已經被鎖則自動跳到下一條記錄（skip locked），這樣誰先查詢誰就可以慢慢的考慮要上鋪還是下鋪。但火車票系統是這樣做的嗎？顯然不是，因為這樣用戶體驗太不好，票實際還很多，但確看不到買不到，這顯然不合理。
方案3：
我們又想到了從程序層面來解決並發問題，最簡便的方式是利用synchronized來處理，但我們要知道一個大型系統必然是集群方式部署的，synchronized只能解決單節點環境的並發問題，要解決此問題還是必須依賴全局性的鎖機制。
方案4：
既然又回到了在數據庫上加鎖，我們又想一下如果我們在查詢時，使用樂觀鎖，但在預訂之前使用悲觀鎖會怎樣呢？例如我們查詢時：
select * from table where ……
用戶A、用戶B都查詢到了相同的票信息（中鋪和下鋪），用戶A或用戶B在預訂時做一次悲觀鎖：
select * from table where …… for update（只對預訂的票做悲觀鎖）
此時后者在預訂時，無法獲取該記錄的鎖，自然就無法預訂，避免了重復預訂的問題。
還有方案嗎……