【問題】在以前的系統開發中，經常遇到乙個同樣問題，就是多個使用者同時併發操作一條記錄，這次在交易系統開發過程中,又出現了這樣問題。比如交易商a提交單子，由審核人員b審核，此時a正在修改單位，b也正在檢視這條記錄，a先修改儲存後b再審核儲存，導致b審核通過的記錄不是他所看到的。
【分析】仔細考慮問題，大概分析了三個方法， 並確定了乙個可行的方案，可能還有不完善的地方，但解決現有問題還是綽綽有餘的。
最先想的是在交易業務**中用lock對修改方法加鎖，執行時注入單例，並且對方法加同步鎖，保證了業務資料的正確性， 但是效率低下，使用者在使用中不方便，背離了系統可以併發操作的原則。
然後考慮使用悲觀鎖，這次執行時注入原型，併發操作效率提高， 但是，在同步處理資料庫表時又造成鎖表,這樣併發效率依舊很低。
最後考慮樂觀鎖， 只是一種資料版本校驗機制，它不做資料庫層次上的鎖定，需要在要併發操作的主表中加入乙個"version"字段或者「lastupdatetime」，如果研究過oracle的scn應該有異曲同工之妙，它的原理是這樣：執行時注入原型，這時資料表並不鎖住，只是每次update或insert時將version更新， 當下次update,insert時，會校驗version，如果不一致，此時提示資訊已經修改過了，並且在事務控制下rollback，這樣，保證了資料的正確性，並且也不影響併發操作的效率。但是出現的問題是：如果a讀了資料，未來及更新，b先更新了資料， 那麼他將提交不上資料，因為version已經失效，這樣就造成了a重新讀取資料，重新填寫單據資訊。 這也是樂觀鎖乙個缺點，可以在更新前臨時儲存a填寫的資料，再在跳轉頁中載入這些資料，保證了交易商不用麻煩再次輸入這些資料，更新成功則清空這些臨時資料
【結果】
樂觀鎖在併發操作問題上，保證了業務效率和資料的正確性，基本可以採用這種方案解決交易中併發問題。
●悲觀鎖：指在應用程式中顯式地為資料資源加鎖。悲觀鎖假定當前事務操
縱資料資源時，肯定還會有其他事務同時訪問該資料資源，為了避免當前
事務的操作受到干擾，先鎖定資源。儘管悲觀鎖能夠防止丟失更新和不可
重複讀這類併發問題，但是它會影響併發效能，因此應該很謹慎地使用悲
觀鎖。
●樂觀鎖：樂觀鎖假定當前事務操縱資料資源時，不會有其他事務同時訪問
該資料資源，因此完全依靠資料庫的隔離級別來自動管理鎖的工作。應用
程式採用版本控制手段來避免可能出現的併發問題。
LR 多使用者多業務併發
使用lr錄製指令碼時，有很多方法都可以模擬使用者的真實使用狀態，例如 1 lr think time 函式的使用可以模擬使用者瀏覽的操作 2 模擬network speed runtime setting下的network speedsimulation 可以模擬使用者訪問速度為最大頻寬 自定義頻寬...
多使用者操作乙個資料表時的併發性操作
我們寫乙個資料庫表時一般都是單使用者的。這個問題不大會發現。假如 trans結構如下 ticid ticbh ticdate 我們呼叫procaddticid newticid pprcaddticid.upd endnew pprcaddticid rules out ticid source f...
C 併發操作 多執行緒
c 11 新標準中引入了幾個標頭檔案來支援多執行緒程式設計 thread 包含std thread類以及std this thread命名空間。管理執行緒的函式和類在 中宣告.atomic 包含std atomic和std atomic flag類，以及一套c風格的原子型別和與c相容的原子操作的函式...