a事務讀取到b事務尚未提交的更改資料，並在這個資料的基礎上進行操作。如果恰巧b事務回滾，那麼a事務讀到的資料根本是不被承認的。
時間轉賬事務a
轉賬事務b
t1開始事務
t2開始事務
t3查詢賬戶餘額為1000
t4取出500，餘額改為500
t5查詢賬戶餘額為500
t6撤銷事務，餘額恢復1000
t7匯入100，把餘額改為600
t8提交事務
不可重複讀是指a事務讀取了b事務已經提交的更改資料。假設a在取款事務過程中，b往賬戶轉了100元，a兩次讀取賬戶的餘額發生不一致。
時間取款事務a
轉賬事務b
t1開始事務
t2開始事務
t3查詢賬戶餘額為1000
t4查詢賬戶餘額為1000
t5取出100，把餘額改為900
t6提交事務
t7查詢賬戶餘額為900（和t4查詢的不一致）
a事務讀取到b事務提交的新增資料，這時a事務將出現幻想讀的問題。幻想讀一般發生在計算統計資料的事務中。
時間統計金額事務a
轉賬事務b
t1開始事務
t2開始事務
t3統計總存款數為1000
t4新增乙個存款賬戶，存入100
t5提交事務
t6統計總存款數為1100
a事務撤銷時，把已經提交的b事務的更新資料覆蓋了。
時間取款事務a
轉賬事務b
t1開始事務
t2開始事務
t3查詢賬戶餘額為1000
t4查詢賬戶餘額為1000
t5匯入100，把餘額改為1100
t6提交事務
t7取出100，把餘額改為900
t8撤銷事務
t9餘額恢復為1000
a事務覆蓋b事務已經提交的資料，造成b事務所做的操作丟失。
時間轉賬事務a
取款事務b
t1開始事務
t2開始事務
t3查詢賬戶餘額為1000
t4查詢賬戶餘額為1000
t5取出100，把餘額改為900
t6提交事務
t7匯入100
t8提交事務
t9把餘額改為1100
續 高併發存在的問題？
執行緒安全問題的根源？可見性 主要是快取引起的，由於cpu快取 記憶體 io磁碟 有序性 指令重排可能引起的執行緒安全 其實可見性和有序性是分不開的程式的執行cpu可能會打亂指令優化執行順序，但是這樣會導致cpu中的資料可能會亂掉 class volatileexample public void ...
DateFormat工具類存在併發問題
也是今天踩了乙個坑才去了解到的。併發問題主要是在format 和parse 兩個方法中，因為這兩個方法中會去呼叫calendar.settime 如果dateformat物件被靜態全域性變數引用，calendar就乙個，併發下的settime當然會有問題。我們常用的 dateformat是datef...
Redis在高併發下存在的問題
描述 在某些特定環境下，無論是先更新redis還是更新資料庫，兩者的資料都有可能不一致。解決方案1 雙寫模式 解決方案2 失效模式 最終解決方案 無論是雙寫模式還是失效模式，都會導致快取的不一致問題。即多個例項同時更新會出事，怎麼辦？如果是使用者緯度資料 訂單資料 使用者資料 這種併發機率非常小，不...