事物的安全問題

寫

丟失更新：指一個事務去修改資料庫，另一個事務也修改資料庫，最後的那個事務，不管提交還是回滾都會造成前面一個事務的資料更新丟失。

解決辦法：悲觀鎖和樂觀鎖

悲觀鎖

指事務在一開始就認為丟失更新一定會發生，這是一件很悲觀的事情。具體步驟如下:

1)所有事務在執行操作前，先查詢一次資料， 查詢語句如下：

        select * from student  for update  ;           後面的for update 其實是資料庫鎖機制 、 一種排他鎖。

2) 哪個事務先執行這個語句， 哪個事務就持有了這把鎖， 可以查詢出來資料， 後面的事務再執行這條語句，不會有任何資料顯示，就只能等著。 

3) 一直等到前面的那個事務提交資料後， 後面的事務資料才會出來，那麼才可以往下接著操作。

這有點像男生去上衛生間似的， 如果誰先來，誰就可以進去蹲著， 後面來的人，得等著。 只有裡面的人出來了，才能進去。 這其實就是 java 中的同步的概念

樂觀鎖

指從來不會覺得丟失更新會發生。那麼它的具體做法是什麼呢？

要求程式設計師在資料庫中新增欄位，然後在後續更新的時候，對該欄位進行判定比對，如果一致才允許更新。例子如下：

1） 資料庫表中，額外添加了一個version欄位， 用於記錄版本， 預設從0 開始， 只要有針對表中資料進行修改的，那麼version就+1.

2） 開啟A事務， 然後開啟B事務 。 

3） A 先執行資料庫表操作。 因為以前都沒有人修改過。 所以是允許A事務修改資料庫的，但是修改完畢，就把version的值變成  1 了 。

4）B事務， 這時候如果想執行修改，那麼是不允許修改的。 因為B事務以前是沒有查詢過資料庫內容的，所以它認為資料庫版本還是0 。 但是資料庫的版本經過A修改，已經是1了。所以這時候不允許修改， 要求其重新查詢 。

5） B重新查詢後， 將會得到version 為 1的資料，這份資料就是之前A 事務修改的資料了， B 在進行修改，也是在A的基礎上修改的。 所以就不會有丟失更新的情況出現了。

樂觀鎖的機制 ，其實是通過比對版本或者比對欄位的方式來實現的， 這與大家在未來的學習中，或者在工作中，使用到的版本控制軟體【SVN , GIT】機制是一樣的。