說(shuō)說(shuō)我的看法，不對(duì)的地方請(qǐng)指正。
樂(lè)觀鎖的實(shí)現(xiàn)原理是cas操作，java中輕量級(jí)鎖也是基于cas實(shí)現(xiàn)的。
悲觀鎖最大的問(wèn)題就是阻塞問(wèn)題。
在深入理解java虛擬機(jī)中提到，輕量級(jí)鎖一般情況下是優(yōu)于重量級(jí)鎖（互斥鎖）的；如果在高并發(fā)鎖競(jìng)爭(zhēng)比較激烈的情況下輕量級(jí)鎖會(huì)由于長(zhǎng)時(shí)間自旋消耗cpu 從而使得輕量級(jí)鎖的性能比傳統(tǒng)的重量級(jí)鎖更慢。那么樂(lè)觀鎖中也有自旋和cas，所以高并發(fā)下樂(lè)觀鎖好像不是一種好的解決方案。
但是有些博文中提到 高并發(fā)下使用樂(lè)觀鎖更合適比如這篇文章中就提到高并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)使用樂(lè)觀鎖http://blog.csdn.net/amqvje/a...
問(wèn)題1，高并發(fā)下如何選擇？
問(wèn)題2 樂(lè)觀鎖有什么缺點(diǎn)？ 為什不都使用樂(lè)觀鎖。高并發(fā)下都是使用樂(lè)觀鎖，如果并發(fā)量不高，使用樂(lè)觀鎖感覺(jué)更不是問(wèn)題
4 回答
互換的青春
TA貢獻(xiàn)1797條經(jīng)驗(yàn) 獲得超6個(gè)贊
簡(jiǎn)單的來(lái)說(shuō)，一般情況下，樂(lè)觀鎖適合只有讀沒(méi)有寫(xiě)的操作，悲觀鎖適合于讀寫(xiě)混合的操作。如果寫(xiě)操作非常簡(jiǎn)單短小，比如增加訪問(wèn)人數(shù)，也可以用樂(lè)觀鎖，或者不需要確保讀到的數(shù)據(jù)是最新的時(shí)候。80%的情況下使用樂(lè)觀鎖確實(shí)是比較好的選擇。
CAS依靠硬件CPU指令支持去實(shí)現(xiàn)原子級(jí)操作，所以高并發(fā)的情況下一般會(huì)更快，但是這個(gè)快不是沒(méi)有缺點(diǎn)的，缺點(diǎn)就是有讀也有寫(xiě)的時(shí)候，CPU緩存失效率可能會(huì)增加，除非你的CPU是單核的（非Intel平臺(tái)的嵌入式）。
總而言之，要提升高并發(fā)性能，還是要實(shí)際測(cè)量出的數(shù)據(jù)說(shuō)明問(wèn)題，我上面提到的都是理論。希望對(duì)你有幫助。
繁星淼淼
TA貢獻(xiàn)1775條經(jīng)驗(yàn) 獲得超11個(gè)贊
沒(méi)工作之前我也是和題主相同的想法，實(shí)際工作中，其實(shí)兩者差別不大，真正高并發(fā)下系統(tǒng)耗時(shí)的地方永遠(yuǎn)是網(wǎng)絡(luò)連接，數(shù)據(jù)庫(kù)查詢以及線程的主動(dòng)睡眠，鎖帶來(lái)開(kāi)銷(xiāo)基本可以忽略不計(jì)
四季花海
TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超5個(gè)贊
關(guān)鍵問(wèn)題在于，事實(shí)是悲觀的還是樂(lè)觀的？
假如你的資源競(jìng)爭(zhēng)很激烈，并且無(wú)法共享的話，樂(lè)觀鎖不過(guò)是讓大量請(qǐng)求的希望落空罷了。
假如你的資源沒(méi)什么競(jìng)爭(zhēng)（這個(gè)和并發(fā)高低沒(méi)必然的關(guān)聯(lián)，業(yè)務(wù)的影響更大），那悲觀鎖意味著不必要地加鎖。如果原本是可共享的資源（比如資源支持多個(gè)只讀方），那么悲觀鎖意味著失去原本的可以使用的時(shí)間。
在深入理解java虛擬機(jī)中提到，輕量級(jí)鎖一般情況下是優(yōu)于重量級(jí)鎖（互斥鎖）的；如果在高并發(fā)鎖競(jìng)爭(zhēng)比較激烈的情況下輕量級(jí)鎖會(huì)由于長(zhǎng)時(shí)間自旋消耗cpu 從而使得輕量級(jí)鎖的性能比傳統(tǒng)的重量級(jí)鎖更慢。那么樂(lè)觀鎖中也有自旋和cas，所以高并發(fā)下悲觀鎖好像不是一種好的解決方案。
我并不了解 JVM。不過(guò)「樂(lè)觀鎖中也有自旋和cas」是什么意思？cas 就是自旋鎖的一種實(shí)現(xiàn)方式，為什么要并列呢？「也」是什么意思？悲觀鎖是個(gè)阻塞操作，沒(méi)有自旋，也不會(huì)持續(xù)消耗 CPU 的。
添加回答
舉報(bào)
0/150
提交
取消