CAS非鎖怎樣實(shí)現(xiàn)單例的一個(gè)缺陷

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)CAS非鎖怎樣實(shí)現(xiàn)單例的一個(gè)缺陷，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

今天我們要說(shuō)的是，無(wú)鎖實(shí)現(xiàn)單例模式，以及這種 CAS 實(shí)現(xiàn)的單例的缺點(diǎn)。

傳統(tǒng)的 7 種單例模式大致如下：

它們都是用鎖來(lái)實(shí)現(xiàn)。但是如果在面試過(guò)程中面試官問(wèn)你如何使用非鎖來(lái)實(shí)現(xiàn)一個(gè)單例呢？

答案就是下圖這種實(shí)現(xiàn)。

這是網(wǎng)上一位大牛的實(shí)現(xiàn)，他的這種非鎖 CAS 實(shí)現(xiàn)的單例，挺好的。但是平時(shí)可能沒(méi)有人使用，比用鎖稍微復(fù)雜了一點(diǎn)，這也是為什么沒(méi)有被列入單例模式的 7 大寫法之中了。我在他的基礎(chǔ)上，也就是他的構(gòu)造方法里添加了兩行代碼。

我主要是想看看它到底是實(shí)例化了幾次。加上這兩行代碼，可以方便我觀察控制臺(tái)，和統(tǒng)計(jì)實(shí)例化的總次數(shù)。

然后，我的測(cè)試代碼如下：

關(guān)于 CountDownLatch 有不會(huì)的，可以看我的《CountDownLatch 壓測(cè)教程》一文。

我這里主要是想壓測(cè)一下，非鎖 CAS 單例模式是否會(huì)創(chuàng)建多次對(duì)象。

運(yùn)行上面的 main 方法，我截圖了一下最終結(jié)果。

CAS 以原子方式更新內(nèi)存中相應(yīng)的值，從而保證了多線程環(huán)境下共享變量更新操作的同步。的確，這種方式可以保證每次調(diào)用getInstance() 方法得到的一定是同一個(gè)實(shí)例。因此，從功能實(shí)現(xiàn)的角度來(lái)看，這種做法達(dá)到了預(yù)期的目的。但是，經(jīng)過(guò)分析和測(cè)試，卻發(fā)現(xiàn)這種方式有一些預(yù)期之外的弊?。嚎赡軙?huì)創(chuàng)建不止一個(gè)對(duì)象。

CAS 本身的操作的確是原子方式，但是包裝 CAS 指令的方法并非是全程同步的，當(dāng)然，在包含 CAS 指令的方法開(kāi)始調(diào)用之前，參數(shù)計(jì)算過(guò)程中更不是互斥執(zhí)行的！當(dāng)一個(gè)線程測(cè)試 instance.get() == null 得到 true 之后，往下它就一定會(huì)調(diào)用 new Singleton()。因?yàn)?，這并不是 CAS 方法的一部分，而是它的參數(shù)。在調(diào)用一個(gè)方法之前，需要先將其參數(shù)壓入棧，當(dāng)然，需要先計(jì)算參數(shù)表達(dá)式，因此，產(chǎn)生如上結(jié)果也就不難預(yù)料了。

CAS 與鎖的區(qū)別在于，它是非阻塞的，也就是說(shuō)，它不會(huì)去等待一個(gè)條件，而是一定會(huì)去執(zhí)行，結(jié)果要么成功，要么失敗。它的操作時(shí)間是可預(yù)期的。如果我們的目的是一定要成功執(zhí)行 CAS，那就需要不斷循環(huán)執(zhí)行直至成功，同時(shí)，建立在成功預(yù)期之上大量的準(zhǔn)備工作是值得的，但是，如果我們不希望操作一定成功，那為成功操作而做的準(zhǔn)備工作就浪費(fèi)掉了。

上述就是小編為大家分享的CAS非鎖怎樣實(shí)現(xiàn)單例的一個(gè)缺陷了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。