怎樣刪除網(wǎng)站虛擬主機(jī)內(nèi)容,自己做網(wǎng)站商城需要營業(yè)執(zhí)照嗎,網(wǎng)站建設(shè)月薪,移動互聯(lián)網(wǎng)開發(fā)平臺有哪些如果將悲觀鎖#xff08;Pessimistic Lock#xff09;和樂觀鎖#xff08;PessimisticLock 或 OptimisticLock#xff09;對應(yīng)到現(xiàn)實(shí)生活中來。悲觀鎖有點(diǎn)像是一位比較悲觀#xff08;也可以說是未雨綢繆#xff09;的人#xff0c;總是會假設(shè)最壞的情況#xff0c;避免…如果將悲觀鎖Pessimistic Lock和樂觀鎖PessimisticLock 或 OptimisticLock對應(yīng)到現(xiàn)實(shí)生活中來。悲觀鎖有點(diǎn)像是一位比較悲觀也可以說是未雨綢繆的人總是會假設(shè)最壞的情況避免出現(xiàn)問題。樂觀鎖有點(diǎn)像是一位比較樂觀的人總是會假設(shè)最好的情況在要出現(xiàn)問題之前快速解決問題。在程序世界中樂觀鎖和悲觀鎖的最終目的都是為了保證線程安全避免在并發(fā)場景下的資源競爭問題。但是相比于樂觀鎖悲觀鎖對性能的影響更大什么是悲觀鎖悲觀鎖總是假設(shè)最壞的情況認(rèn)為共享資源每次被訪問的時候就會出現(xiàn)問題(比如共享數(shù)據(jù)被修改)所以每次在獲取資源操作的時候都會上鎖這樣其他線程想拿到這個資源就會阻塞直到鎖被上一個持有者釋放。也就是說共享資源每次只給一個線程使用其它線程阻塞用完后再把資源轉(zhuǎn)讓給其它線程。像 Java 中synchronized和ReentrantLock等獨(dú)占鎖就是悲觀鎖思想的實(shí)現(xiàn)。public void performSynchronisedTask() { synchronized (this) { // 需要同步的操作 } } private Lock lock new ReentrantLock(); lock.lock(); try { // 需要同步的操作 } finally { lock.unlock(); }一鍵獲取完整項(xiàng)目代碼java高并發(fā)的場景下激烈的鎖競爭會造成線程阻塞大量阻塞線程會導(dǎo)致系統(tǒng)的上下文切換增加系統(tǒng)的性能開銷。并且悲觀鎖還可能會存在死鎖問題影響代碼的正常運(yùn)行。什么是樂觀鎖樂觀鎖總是假設(shè)最好的情況認(rèn)為共享資源每次被訪問的時候不會出現(xiàn)問題線程可以不停地執(zhí)行無需加鎖也無需等待只是在提交修改的時候去驗(yàn)證對應(yīng)的資源也就是數(shù)據(jù)是否被其它線程修改了具體方法可以使用版本號機(jī)制或 CAS 算法。像 Java 中java.util.concurrent.atomic包下面的原子變量類比如AtomicInteger、LongAdder就是使用了樂觀鎖的一種實(shí)現(xiàn)方式CAS實(shí)現(xiàn)的。// LongAdder 在高并發(fā)場景下會比 AtomicInteger 和 AtomicLong 的性能更好 // 代價就是會消耗更多的內(nèi)存空間空間換時間 LongAdder longAdder new LongAdder(); // 自增 longAdder.increment(); // 獲取結(jié)果 longAdder.sum();一鍵獲取完整項(xiàng)目代碼java高并發(fā)的場景下樂觀鎖相比悲觀鎖來說不存在鎖競爭造成線程阻塞也不會有死鎖的問題在性能上往往會更勝一籌。但是如果沖突頻繁發(fā)生寫占比非常多的情況會頻繁失敗和重試悲觀鎖的開銷是固定的這樣同樣會非常影響性能導(dǎo)致 CPU 飆升。不過大量失敗重試的問題也是可以解決的像我們前面提到的LongAdder以空間換時間的方式就解決了這個問題。理論上來說悲觀鎖通常多用于寫比較多的情況下多寫場景競爭激烈這樣可以避免頻繁失敗和重試影響性能悲觀鎖的開銷是固定的。不過如果樂觀鎖解決了頻繁失敗和重試這個問題的話比如LongAdder也是可以考慮使用樂觀鎖的要視實(shí)際情況而定。樂觀鎖通常多于寫比較少的情況下多讀場景競爭較少這樣可以避免頻繁加鎖影響性能。不過樂觀鎖主要針對的對象是單個共享變量參考java.util.concurrent.atomic包下面的原子變量類。篇幅限制下面就只能給大家展示小冊部分內(nèi)容了。整理了一份核心面試筆記包括了Java面試、Spring、JVM、MyBatis、Redis、MySQL、并發(fā)編程、微服務(wù)、Linux、Springboot、SpringCloud、MQ、Kafc需要全套面試筆記及答案【點(diǎn)擊此處即可/免費(fèi)獲取】https://docs.qq.com/doc/DQXdYWE9LZ2ZHZ1ho如何實(shí)現(xiàn)樂觀鎖樂觀鎖一般會使用版本號機(jī)制或 CAS 算法實(shí)現(xiàn)CAS 算法相對來說更多一些這里需要格外注意。版本號機(jī)制一般是在數(shù)據(jù)表中加上一個數(shù)據(jù)版本號version字段表示數(shù)據(jù)被修改的次數(shù)。當(dāng)數(shù)據(jù)被修改時version值會加一。當(dāng)線程 A 要更新數(shù)據(jù)值時在讀取數(shù)據(jù)的同時也會讀取version值在提交更新時若剛才讀取到的 version 值為當(dāng)前數(shù)據(jù)庫中的version值相等時才更新否則重試更新操作直到更新成功。舉一個簡單的例子假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個 version 字段當(dāng)前值為 1 而當(dāng)前帳戶余額字段balance為 $100 。操作員 A 此時將其讀出version1 并從其帳戶余額中扣除 $50 $100-$50 。在操作員 A 操作的過程中操作員 B 也讀入此用戶信息version1 并從其帳戶余額中扣除 $20 $100-$20 。操作員 A 完成了修改工作將數(shù)據(jù)版本號version1 連同帳戶扣除后余額balance$50 提交至數(shù)據(jù)庫更新此時由于提交數(shù)據(jù)版本等于數(shù)據(jù)庫記錄當(dāng)前版本數(shù)據(jù)被更新數(shù)據(jù)庫記錄version更新為 2 。操作員 B 完成了操作也將版本號version1 試圖向數(shù)據(jù)庫提交數(shù)據(jù)balance$80 但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn)操作員 B 提交的數(shù)據(jù)版本號為 1 數(shù)據(jù)庫記錄當(dāng)前版本也為 2 不滿足 “ 提交版本必須等于當(dāng)前版本才能執(zhí)行更新 “ 的樂觀鎖策略因此操作員 B 的提交被駁回。這樣就避免了操作員 B 用基于version1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作員 A 的操作結(jié)果的可能。CAS 算法CAS 的全稱是Compare And Swap比較與交換用于實(shí)現(xiàn)樂觀鎖被廣泛應(yīng)用于各大框架中。CAS 的思想很簡單就是用一個預(yù)期值和要更新的變量值進(jìn)行比較兩值相等才會進(jìn)行更新。CAS 是一個原子操作底層依賴于一條 CPU 的原子指令。原子操作即最小不可拆分的操作也就是說操作一旦開始就不能被打斷直到操作完成。CAS 涉及到三個操作數(shù)V要更新的變量值(Var)E預(yù)期值(Expected)N擬寫入的新值(New)當(dāng)且僅當(dāng) V 的值等于 E 時CAS 通過原子方式用新值 N 來更新 V 的值。如果不等說明已經(jīng)有其它線程更新了 V則當(dāng)前線程放棄更新。舉一個簡單的例子線程 A 要修改變量 i 的值為 6i 原值為 1V 1E1N6假設(shè)不存在 ABA 問題。i 與 1 進(jìn)行比較如果相等 則說明沒被其他線程修改可以被設(shè)置為 6 。i 與 1 進(jìn)行比較如果不相等則說明被其他線程修改當(dāng)前線程放棄更新CAS 操作失敗。當(dāng)多個線程同時使用 CAS 操作一個變量時只有一個會勝出并成功更新其余均會失敗但失敗的線程并不會被掛起僅是被告知失敗并且允許再次嘗試當(dāng)然也允許失敗的線程放棄操作。Java 語言并沒有直接實(shí)現(xiàn) CASCAS 相關(guān)的實(shí)現(xiàn)是通過 C 內(nèi)聯(lián)匯編的形式實(shí)現(xiàn)的JNI 調(diào)用。因此 CAS 的具體實(shí)現(xiàn)和操作系統(tǒng)以及 CPU 都有關(guān)系。sun.misc包下的Unsafe類提供了compareAndSwapObject、compareAndSwapInt、compareAndSwapLong方法來實(shí)現(xiàn)的對Object、int、long類型的 CAS 操作/** * CAS * param o 包含要修改field的對象 * param offset 對象中某field的偏移量 * param expected 期望值 * param update 更新值 * return true | false */ public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object update); public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update); public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);一鍵獲取完整項(xiàng)目代碼java篇幅限制下面就只能給大家展示小冊部分內(nèi)容了。整理了一份核心面試筆記包括了Java面試、Spring、JVM、MyBatis、Redis、MySQL、并發(fā)編程、微服務(wù)、Linux、Springboot、SpringCloud、MQ、Kafc需要全套面試筆記及答案【點(diǎn)擊此處即可/免費(fèi)獲取】https://docs.qq.com/doc/DQXdYWE9LZ2ZHZ1ho樂觀鎖存在哪些問題ABA 問題是樂觀鎖最常見的問題。ABA 問題如果一個變量 V 初次讀取的時候是 A 值并且在準(zhǔn)備賦值的時候檢查到它仍然是 A 值那我們就能說明它的值沒有被其他線程修改過了嗎很明顯是不能的因?yàn)樵谶@段時間它的值可能被改為其他值然后又改回 A那 CAS 操作就會誤認(rèn)為它從來沒有被修改過。這個問題被稱為 CAS 操作的ABA問題。ABA 問題的解決思路是在變量前面追加上版本號或者時間戳。JDK 1.5 以后的AtomicStampedReference類就是用來解決 ABA 問題的其中的compareAndSet()方法就是首先檢查當(dāng)前引用是否等于預(yù)期引用并且當(dāng)前標(biāo)志是否等于預(yù)期標(biāo)志如果全部相等則以原子方式將該引用和該標(biāo)志的值設(shè)置為給定的更新值。public boolean compareAndSet(V expectedReference, V newReference, int expectedStamp, int newStamp) { PairV current pair; return expectedReference current.reference expectedStamp current.stamp ((newReference current.reference newStamp current.stamp) || casPair(current, Pair.of(newReference, newStamp))); }一鍵獲取完整項(xiàng)目代碼java循環(huán)時間長開銷大CAS 經(jīng)常會用到自旋操作來進(jìn)行重試也就是不成功就一直循環(huán)執(zhí)行直到成功。如果長時間不成功會給 CPU 帶來非常大的執(zhí)行開銷。如果 JVM 能支持處理器提供的 pause 指令那么效率會有一定的提升pause 指令有兩個作用可以延遲流水線執(zhí)行指令使 CPU 不會消耗過多的執(zhí)行資源延遲的時間取決于具體實(shí)現(xiàn)的版本在一些處理器上延遲時間是零?？梢员苊庠谕顺鲅h(huán)的時候因內(nèi)存順序沖而引起 CPU 流水線被清空從而提高 CPU 的執(zhí)行效率。只能保證一個共享變量的原子操作CAS 只對單個共享變量有效當(dāng)操作涉及跨多個共享變量時 CAS 無效。但是從 JDK 1.5 開始提供了AtomicReference類來保證引用對象之間的原子性你可以把多個變量放在一個對象里來進(jìn)行 CAS 操作.所以我們可以使用鎖或者利用AtomicReference類把多個共享變量合并成一個共享變量來操作?？偨Y(jié)高并發(fā)的場景下激烈的鎖競爭會造成線程阻塞大量阻塞線程會導(dǎo)致系統(tǒng)的上下文切換增加系統(tǒng)的性能開銷。并且悲觀鎖還可能會存在死鎖問題影響代碼的正常運(yùn)行。樂觀鎖相比悲觀鎖來說不存在鎖競爭造成線程阻塞也不會有死鎖的問題在性能上往往會更勝一籌。不過如果沖突頻繁發(fā)生寫占比非常多的情況會頻繁失敗和重試這樣同樣會非常影響性能導(dǎo)致 CPU 飆升。樂觀鎖一般會使用版本號機(jī)制或 CAS 算法實(shí)現(xiàn)CAS 算法相對來說更多一些這里需要格外注意。CAS 的全稱是Compare And Swap比較與交換用于實(shí)現(xiàn)樂觀鎖被廣泛應(yīng)用于各大框架中。CAS 的思想很簡單就是用一個預(yù)期值和要更新的變量值進(jìn)行比較兩值相等才會進(jìn)行更新。樂觀鎖的問題ABA 問題、循環(huán)時間長開銷大、只能保證一個共享變量的原子操作。