為了得到最大的性能，一般數據庫都有并發機制，不過帶來的問題就是數據訪問的沖突。為了解決這個問題，大多數數據庫用的方法就是數據的鎖定。

數據的鎖定分為兩種方法，第一種叫做悲觀鎖，第二種叫做樂觀鎖。什么叫悲觀鎖呢，悲觀鎖顧名思義，就是對數據的沖突采取一種悲觀的態度，也就是說假設數據 肯定會沖突，所以在數據開始讀取的時候就把數據鎖定住。而樂觀鎖就是認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖 突與否進行檢測，如果發現沖突了，則讓用戶返回錯誤的信息，讓用戶決定如何去做。

先從悲觀鎖開始說。在SqlServer等其余很多數據庫中，數據的鎖定通常采用頁級鎖的方式，也就是說對一張表內的數據是一種串行化的更新插入機制，在 任何時間同一張表只會插1條數據，別的想插入的數據要等到這一條數據插完以后才能依次插入。帶來的后果就是性能的降低，在多用戶并發訪問的時候，當對一張 表進行頻繁操作時，會發現響應效率很低，數據庫經常處于一種假死狀態。而Oracle用的是行級鎖，只是對想鎖定的數據才進行鎖定，其余的數據不相干，所 以在對Oracle表中并發插數據的時候，基本上不會有任何影響。

注：對于悲觀鎖是針對并發的可能性比較大，而一般在我們的應用中用樂觀鎖足以。


Oracle的悲觀鎖需要利用一條現有的連接，分成兩種方式，從SQL語句的區別來看，就是一種是for update，一種是for update nowait的形式。比如我們看一個例子。首先建立測試用的數據庫表。

CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept


這里我們利用了Oracle的Sample的scott用戶的表，把數據copy到我們的test表中。首先我們看一下for update鎖定方式。首先我們執行如下的select for update語句。

select * from test where id = 10 for update

通過這條檢索語句鎖定以后，再開另外一個sql*plus窗口進行操作，再把上面這條sql語句執行一便，你會發現sqlplus好像死在那里了，好像檢 索不到數據的樣子，但是也不返回任何結果，就屬于卡在那里的感覺。這個時候是什么原因呢，就是一開始的第一個Session中的select for update語句把數據鎖定住了。由于這里鎖定的機制是wait的狀態(只要不表示nowait那就是wait)，所以第二個Session(也就是卡住 的那個sql*plus)中當前這個檢索就處于等待狀態。當第一個session最后commit或者rollback之后，第二個session中的檢 索結果就是自動跳出來，并且也把數據鎖定住。不過如果你第二個session中你的檢索語句如下所示。

select * from test where id = 10


也就是沒有for update這種鎖定數據的語句的話，就不會造成阻塞了。另外一種情況，就是當數據庫數據被鎖定的時候，也就是執行剛才for update那條sql以后，我們在另外一個session中執行for update nowait后又是什么樣呢。比如如下的sql語句。 由于這條語句中是制定采用nowait方式來進行檢索，所以當發現數據被別的session鎖定中的時候，就會迅速返回ORA-00054錯誤，內容是資 源正忙, 但指定以 NOWAIT 方式獲取資源。所以在程序中我們可以采用nowait方式迅速判斷當前數據是否被鎖定中，如果鎖定中的話，就要采取相應的業務措施進行處理。

select * from test where id = 10 for update nowait


那這里另外一個問題，就是當我們鎖定住數據的時候，我們對數據進行更新和刪除的話會是什么樣呢。比如同樣，我們讓第一個Session鎖定住id=10的那條數據，我們在第二個session中執行如下語句。

update test set value=2 where id = 10


這個時候我們發現update語句就好像select for update語句一樣也停住卡在這里，當你第一個session放開鎖定以后update才能正常運行。當你update運行后，數據又被你update 語句鎖定住了，這個時候只要你update后還沒有commit，別的session照樣不能對數據進行鎖定更新等等。

總之，Oracle中的悲觀鎖就是利用Oracle的Connection對數據進行鎖定。在Oracle中，用這種行級鎖帶來的性能損失是很小的，只是 要注意程序邏輯，不要給你一不小心搞成死鎖了就好。而且由于數據的及時鎖定，在數據提交時候就不呼出現沖突，可以省去很多惱人的數據沖突處理。缺點就是你 必須要始終有一條數據庫連接，就是說在整個鎖定到最后放開鎖的過程中，你的數據庫聯接要始終保持住。與悲觀鎖相對的，我們有了樂觀鎖。樂觀鎖一開始也說 了，就是一開始假設不會造成數據沖突，在最后提交的時候再進行數據沖突檢測。在樂觀鎖中，我們有3種

常用的做法來實現。

[1]第一種就是在數據取得的時候把整個數據都copy到應用中，在進行提交的時候比對當前數據庫中的數據和開始的時候更新前取得的數據。當發現兩個數據一模一樣以后，就表示沒有沖突可以提交，否則則是并發沖突，需要去用業務邏輯進行解決。

[2]第二種樂觀鎖的做法就是采用版本戳，這個在Hibernate中得到了使用。采用版本戳的話，首先需要在你有樂觀鎖的數據庫table上建立一個新 的column，比如為number型，當你數據每更新一次的時候，版本數就會往上增加1。比如同樣有2個session同樣對某條數據進行操作。兩者都 取到當前的數據的版本號為1，當第一個session進行數據更新后，在提交的時候查看到當前數據的版本還為1，和自己一開始取到的版本相同。就正式提 交，然后把版本號增加1，這個時候當前數據的版本為2。當第二個session也更新了數據提交的時候，發現數據庫中版本為2，和一開始這個 session取到的版本號不一致，就知道別人更新過此條數據，這個

時候再進行業務處理，比如整個Transaction都Rollback等等操作。在用版本戳的時候，可以在應用程序側使用版本戳的驗證，也可以在數據庫 側采用Trigger(觸發器)來進行驗證。不過數據庫的Trigger的性能開銷還是比較的大，所以能在應用側進行驗證的話還是推薦不用 Trigger。

[3]第三種做法和第二種做法有點類似，就是也新增一個Table的Column，不過這次這個column是采用timestamp型，存儲數據最后更 新的時間。在Oracle9i以后可以采用新的數據類型，也就是timestamp with time zone類型來做時間戳。這種Timestamp的數據精度在Oracle的時間類型中是最高的，精確到微秒(還沒與到納秒的級別)，一般來說，加上數據 庫處理時間和人的思考動作時間，微秒級別是非常非常夠了，其實只要精確到毫秒甚至秒都應該沒有什么問題。和剛才的版本戳類似，也是在更新提交的時候檢查當 前數據庫中數據的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本沖突。如果不想把代碼寫在程序中或者由于別的原因無法把代碼寫在 現有的程序中，也可以把這個時間戳樂觀鎖邏輯寫在Trigger或者存儲過程中。

Oracle悲觀鎖和樂觀鎖