12-volatile關(guān)鍵字使用場(chǎng)景

volatile關(guān)鍵字使用場(chǎng)景

Java 語(yǔ)言中的 volatile 變量可以被看作是一種 “程度較輕的 synchronized”;與 synchronized 塊相比,volatile 變量所需的編碼較少雳刺,并且運(yùn)行時(shí)開(kāi)銷也較少,但是它所能實(shí)現(xiàn)的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile 變量的模式,并強(qiáng)調(diào)了幾種不適合使用 volatile 變量的情形额嘿。

synchronized和volatile的區(qū)別

鎖提供了兩種主要特性:互斥(mutual exclusion) 和可見(jiàn)性(visibility)×哟欤互斥即一次只允許一個(gè)線程持有某個(gè)特定的鎖册养,因此可使用該特性實(shí)現(xiàn)對(duì)共享數(shù)據(jù)的協(xié)調(diào)訪問(wèn)協(xié)議,這樣揣云,一次就只有一個(gè)線程能夠使用該共享數(shù)據(jù)捕儒”校可見(jiàn)性要更加復(fù)雜一些邓夕,它必須確保釋放鎖之前對(duì)共享數(shù)據(jù)做出的更改對(duì)于隨后獲得該鎖的另一個(gè)線程是可見(jiàn)的 —— 如果沒(méi)有同步機(jī)制提供的這種可見(jiàn)性保證,線程看到的共享變量可能是修改前的值或不一致的值阎毅,這將引發(fā)許多嚴(yán)重問(wèn)題焚刚。

volatile 變量具有 synchronized 的可見(jiàn)性特性,但是不具備原子特性扇调。這就是說(shuō)線程能夠自動(dòng)發(fā)現(xiàn) volatile 變量的最新值矿咕。volatile 變量可用于提供線程安全,但是只能應(yīng)用于非常有限的一組用例:多個(gè)變量之間或者某個(gè)變量的當(dāng)前值與修改后值之間沒(méi)有約束。因此碳柱,單獨(dú)使用 volatile 還不足以實(shí)現(xiàn)計(jì)數(shù)器捡絮、互斥鎖或任何具有與多個(gè)變量相關(guān)的不變式(Invariants)的類(例如 “start <=end”)。

出于簡(jiǎn)易性或可伸縮性的考慮莲镣,您可能傾向于使用 volatile 變量而不是鎖福稳。當(dāng)使用 volatile 變量而非鎖時(shí),某些習(xí)慣用法(idiom)更加易于編碼和閱讀瑞侮。此外的圆,volatile 變量不會(huì)像鎖那樣造成線程阻塞,因此也很少造成可伸縮性問(wèn)題半火。在某些情況下越妈,如果讀操作遠(yuǎn)遠(yuǎn)大于寫操作,volatile 變量還可以提供優(yōu)于鎖的性能優(yōu)勢(shì)钮糖。

正確使用 volatile 變量的條件

您只能在有限的一些情形下使用 volatile 變量替代鎖梅掠。要使 volatile 變量提供理想的線程安全,必須同時(shí)滿足下面兩個(gè)條件:

  • 對(duì)變量的寫操作不依賴于當(dāng)前值店归。
  • 該變量沒(méi)有包含在具有其他變量的不變式中瓤檐。

實(shí)際上,這些條件表明娱节,可以被寫入 volatile 變量的這些有效值獨(dú)立于任何程序的狀態(tài)挠蛉,包括變量的當(dāng)前狀態(tài)。

第一個(gè)條件的限制使 volatile 變量不能用作線程安全計(jì)數(shù)器肄满。雖然增量操作(x++)看上去類似一個(gè)單獨(dú)操作谴古,實(shí)際上它是一個(gè)由讀取-修改-寫入操作序列組成的組合操作稠歉,必須以原子方式執(zhí)行掰担,而 volatile 不能提供必須的原子特性。實(shí)現(xiàn)正確的操作需要使 x 的值在操作期間保持不變怒炸,而 volatile 變量無(wú)法實(shí)現(xiàn)這點(diǎn)带饱。(然而,如果將值調(diào)整為只從單個(gè)線程寫入阅羹,那么可以忽略第一個(gè)條件勺疼。)

大多數(shù)編程情形都會(huì)與這兩個(gè)條件的其中之一沖突,使得 volatile 變量不能像 synchronized 那樣普遍適用于實(shí)現(xiàn)線程安全捏鱼。以下代碼顯示了一個(gè)非線程安全的數(shù)值范圍類执庐。它包含了一個(gè)不變式 —— 下界總是小于或等于上界。

非線程安全的數(shù)值范圍類:

@NotThreadSafe 
public class NumberRange {
    private int lower, upper;
 
    public int getLower() { return lower; }
    public int getUpper() { return upper; }
 
    public void setLower(int value) { 
        if (value > upper) 
            throw new IllegalArgumentException(...);
        lower = value;
    }
 
    public void setUpper(int value) { 
        if (value < lower) 
            throw new IllegalArgumentException(...);
        upper = value;
    }
}

這種方式限制了狀態(tài)變量的范圍导梆,因此將 lower 和 upper 字段定義為 volatile 類型不能夠充分實(shí)現(xiàn)類的線程安全轨淌;從而仍然需要使用同步迂烁。否則,如果湊巧兩個(gè)線程在同一時(shí)間使用不一致的值執(zhí)行 setLower 和 setUpper 的話递鹉,則會(huì)使范圍處于不一致的狀態(tài)盟步。例如,如果初始狀態(tài)是 (0, 5)躏结,同一時(shí)間內(nèi)址芯,線程 A 調(diào)用 setLower(4) 并且線程 B 調(diào)用 setUpper(3),顯然這兩個(gè)操作交叉存入的值是不符合條件的窜觉,那么兩個(gè)線程都會(huì)通過(guò)用于保護(hù)不變式的檢查谷炸,使得最后的范圍值是 (4, 3) —— 一個(gè)無(wú)效值。至于針對(duì)范圍的其他操作禀挫,我們需要使 setLower() 和 setUpper() 操作原子化 —— 而將字段定義為 volatile 類型是無(wú)法實(shí)現(xiàn)這一目的的旬陡。

性能考慮

使用 volatile 變量的主要原因是其簡(jiǎn)易性:在某些情形下,使用 volatile 變量要比使用相應(yīng)的鎖簡(jiǎn)單得多语婴。使用 volatile 變量次要原因是其性能:某些情況下描孟,volatile 變量同步機(jī)制的性能要優(yōu)于鎖。

很難做出準(zhǔn)確砰左、全面的評(píng)價(jià)匿醒,例如 “X 總是比 Y 快”,尤其是對(duì) JVM 內(nèi)在的操作而言缠导。(例如廉羔,某些情況下 JVM 也許能夠完全刪除鎖機(jī)制,這使得我們難以抽象地比較 volatile 和 synchronized 的開(kāi)銷僻造。)就是說(shuō)憋他,在目前大多數(shù)的處理器架構(gòu)上,volatile 讀操作開(kāi)銷非常低 —— 幾乎和非 volatile 讀操作一樣髓削。而 volatile 寫操作的開(kāi)銷要比非 volatile 寫操作多很多竹挡,因?yàn)橐WC可見(jiàn)性需要實(shí)現(xiàn)內(nèi)存界定(Memory Fence),即便如此立膛,volatile 的總開(kāi)銷仍然要比鎖獲取低揪罕。

volatile 操作不會(huì)像鎖一樣造成阻塞,因此宝泵,在能夠安全使用 volatile 的情況下好啰,volatile 可以提供一些優(yōu)于鎖的可伸縮特性。如果讀操作的次數(shù)要遠(yuǎn)遠(yuǎn)超過(guò)寫操作鲁猩,與鎖相比坎怪,volatile 變量通常能夠減少同步的性能開(kāi)銷。

正確使用 volatile 的模式

很多并發(fā)性專家事實(shí)上往往引導(dǎo)用戶遠(yuǎn)離 volatile 變量廓握,因?yàn)槭褂盟鼈円仁褂面i更加容易出錯(cuò)搅窿。然而,如果謹(jǐn)慎地遵循一些良好定義的模式隙券,就能夠在很多場(chǎng)合內(nèi)安全地使用 volatile 變量男应。要始終牢記使用 volatile 的限制 —— 只有在狀態(tài)真正獨(dú)立于程序內(nèi)其他內(nèi)容時(shí)才能使用 volatile —— 這條規(guī)則能夠避免將這些模式擴(kuò)展到不安全的用例。

模式 #1:狀態(tài)標(biāo)志

也許實(shí)現(xiàn) volatile 變量的規(guī)范使用僅僅是使用一個(gè)布爾狀態(tài)標(biāo)志娱仔,用于指示發(fā)生了一個(gè)重要的一次性事件沐飘,例如完成初始化或請(qǐng)求停機(jī)。

很多應(yīng)用程序包含了一種控制結(jié)構(gòu)牲迫,形式為 “在還沒(méi)有準(zhǔn)備好停止程序時(shí)再執(zhí)行一些工作”耐朴,舉個(gè)例子:

volatile boolean shutdownRequested;
 
...
 
public void shutdown() { shutdownRequested = true; }
 
public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}

很可能會(huì)從循環(huán)外部調(diào)用 shutdown() 方法 —— 即在另一個(gè)線程中 —— 因此,需要執(zhí)行某種同步來(lái)確保正確實(shí)現(xiàn) shutdownRequested 變量的可見(jiàn)性盹憎。(可能會(huì)從 JMX 偵聽(tīng)程序筛峭、GUI 事件線程中的操作偵聽(tīng)程序、通過(guò) RMI 陪每、通過(guò)一個(gè) Web 服務(wù)等調(diào)用)影晓。然而,使用 synchronized 塊編寫循環(huán)要比使用 volatile 狀態(tài)標(biāo)志編寫麻煩很多檩禾。由于 volatile 簡(jiǎn)化了編碼挂签,并且狀態(tài)標(biāo)志并不依賴于程序內(nèi)任何其他狀態(tài),因此此處非常適合使用 volatile盼产。

模式 #2:一次性安全發(fā)布(one-time safe publication)

缺乏同步會(huì)導(dǎo)致無(wú)法實(shí)現(xiàn)可見(jiàn)性饵婆,這使得確定何時(shí)寫入對(duì)象引用而不是原語(yǔ)值變得更加困難。在缺乏同步的情況下戏售,可能會(huì)遇到某個(gè)對(duì)象引用的更新值(由另一個(gè)線程寫入)和該對(duì)象狀態(tài)的舊值同時(shí)存在啦辐。(這就是造成著名的雙重檢查鎖定(double-checked-locking)問(wèn)題的根源,其中對(duì)象引用在沒(méi)有同步的情況下進(jìn)行讀操作蜈项,產(chǎn)生的問(wèn)題是您可能會(huì)看到一個(gè)更新的引用芹关,但是仍然會(huì)通過(guò)該引用看到不完全構(gòu)造的對(duì)象)。

臭名昭著的雙重檢查鎖定(dcl):

// 不安全的雙重檢查鎖定
public class Singleton {  
    private static Singleton instance = null;  
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {  
            synchronized(Singleton.class) { 
                if (instance == null) {  
                    instance = new Singleton();  
                }  
            }  
        }  
        return instance;  
    }
}

Doug Lea 在他的文章中寫道:“根據(jù)最新的 JSR133 的 Java 內(nèi)存模型紧卒,如果將引用類型聲明為 volatile侥衬,雙重檢查模式就可以工作了”。如以下代碼所示:

    // 在引用類型聲明加上volatile關(guān)鍵字
    private volatile static Singleton instance = null;  

注:實(shí)現(xiàn)單例設(shè)計(jì)模式更推薦使用 initialization-on-demand holder(延遲初始化占位類模式):

public class Something {
    private Something() {}

    private static class LazyHolder {
        static final Something INSTANCE = new Something();
    }

    public static Something getInstance() {
        return LazyHolder.INSTANCE;
    }
}

模式 #3:獨(dú)立觀察(independent observation)

安全使用 volatile 的另一種簡(jiǎn)單模式是:定期 “發(fā)布” 觀察結(jié)果供程序內(nèi)部使用跑芳。例如轴总,假設(shè)有一種環(huán)境傳感器能夠感覺(jué)環(huán)境溫度。一個(gè)后臺(tái)線程可能會(huì)每隔幾秒讀取一次該傳感器博个,并更新包含當(dāng)前文檔的 volatile 變量怀樟。然后,其他線程可以讀取這個(gè)變量盆佣,從而隨時(shí)能夠看到最新的溫度值往堡。

使用該模式的另一種應(yīng)用程序就是收集程序的統(tǒng)計(jì)信息械荷。清單 4 展示了身份驗(yàn)證機(jī)制如何記憶最近一次登錄的用戶的名字。將反復(fù)使用 lastUser 引用來(lái)發(fā)布值虑灰,以供程序的其他部分使用吨瞎。

清單 4. 將 volatile 變量用于多個(gè)獨(dú)立觀察結(jié)果的發(fā)布

public class UserManager {
    public volatile String lastUser;
 
    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}

該模式是前面模式的擴(kuò)展;將某個(gè)值發(fā)布以在程序內(nèi)的其他地方使用,但是與一次性事件的發(fā)布不同,這是一系列獨(dú)立事件辙喂。這個(gè)模式要求被發(fā)布的值是有效不可變的 —— 即值的狀態(tài)在發(fā)布后不會(huì)更改。使用該值的代碼需要清楚該值可能隨時(shí)發(fā)生變化崖叫。

模式 #4:“volatile bean” 模式

volatile bean 模式適用于將 JavaBeans 作為“榮譽(yù)結(jié)構(gòu)”使用的框架。在 volatile bean 模式中拍柒,JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨(dú)立屬性的容器心傀。volatile bean 模式的基本原理是:很多框架為易變數(shù)據(jù)的持有者(例如 HttpSession)提供了容器,但是放入這些容器中的對(duì)象必須是線程安全的斤儿。

在 volatile bean 模式中剧包,JavaBean 的所有數(shù)據(jù)成員都是 volatile 類型的,并且 getter 和 setter 方法必須非常普通 —— 除了獲取或設(shè)置相應(yīng)的屬性外往果,不能包含任何邏輯疆液。此外,對(duì)于對(duì)象引用的數(shù)據(jù)成員陕贮,引用的對(duì)象必須是有效不可變的堕油。(這將禁止具有數(shù)組值的屬性,因?yàn)楫?dāng)數(shù)組引用被聲明為 volatile 時(shí)肮之,只有引用而不是數(shù)組本身具有 volatile 語(yǔ)義)掉缺。對(duì)于任何 volatile 變量,不變式或約束都不能包含 JavaBean 屬性戈擒。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean:

清單 5. 遵守 volatile bean 模式的 Person 對(duì)象

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;
 
    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }
 
    public void setFirstName(String firstName) { 
        this.firstName = firstName;
    }
 
    public void setLastName(String lastName) { 
        this.lastName = lastName;
    }
 
    public void setAge(int age) { 
        this.age = age;
    }
}

模式 #5:開(kāi)銷較低的讀-寫鎖策略

目前為止眶明,您應(yīng)該了解了 volatile 的功能還不足以實(shí)現(xiàn)計(jì)數(shù)器。因?yàn)?++x 實(shí)際上是三種操作(讀筐高、添加搜囱、存儲(chǔ))的簡(jiǎn)單組合,如果多個(gè)線程湊巧試圖同時(shí)對(duì) volatile 計(jì)數(shù)器執(zhí)行增量操作柑土,那么它的更新值有可能會(huì)丟失蜀肘。

然而,如果讀操作遠(yuǎn)遠(yuǎn)超過(guò)寫操作稽屏,您可以結(jié)合使用內(nèi)部鎖和 volatile 變量來(lái)減少公共代碼路徑的開(kāi)銷扮宠。清單 6 中顯示的線程安全的計(jì)數(shù)器使用 synchronized 確保增量操作是原子的,并使用 volatile 保證當(dāng)前結(jié)果的可見(jiàn)性狐榔。如果更新不頻繁的話坛增,該方法可實(shí)現(xiàn)更好的性能获雕,因?yàn)樽x路徑的開(kāi)銷僅僅涉及 volatile 讀操作,這通常要優(yōu)于一個(gè)無(wú)競(jìng)爭(zhēng)的鎖獲取的開(kāi)銷轿偎。

清單 6. 結(jié)合使用 volatile 和 synchronized 實(shí)現(xiàn) “開(kāi)銷較低的讀-寫鎖”

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;
 
    public int getValue() { return value; }
 
    public synchronized int increment() {
        return value++;
    }
}

之所以將這種技術(shù)稱之為 “開(kāi)銷較低的讀-寫鎖” 是因?yàn)槟褂昧瞬煌耐綑C(jī)制進(jìn)行讀寫操作典鸡。因?yàn)楸纠械膶懖僮鬟`反了使用 volatile 的第一個(gè)條件被廓,因此不能使用 volatile 安全地實(shí)現(xiàn)計(jì)數(shù)器 —— 您必須使用鎖坏晦。然而,您可以在讀操作中使用 volatile 確保當(dāng)前值的可見(jiàn)性嫁乘,因此可以使用鎖進(jìn)行所有變化的操作昆婿,使用 volatile 進(jìn)行只讀操作。其中蜓斧,鎖一次只允許一個(gè)線程訪問(wèn)值仓蛆,volatile 允許多個(gè)線程執(zhí)行讀操作,因此當(dāng)使用 volatile 保證讀代碼路徑時(shí)挎春,要比使用鎖執(zhí)行全部代碼路徑獲得更高的共享度 —— 就像讀-寫操作一樣看疙。然而,要隨時(shí)牢記這種模式的弱點(diǎn):如果超越了該模式的最基本應(yīng)用直奋,結(jié)合這兩個(gè)競(jìng)爭(zhēng)的同步機(jī)制將變得非常困難能庆。

總結(jié)

與鎖相比,Volatile 變量是一種非常簡(jiǎn)單但同時(shí)又非常脆弱的同步機(jī)制脚线,它在某些情況下將提供優(yōu)于鎖的性能和伸縮性搁胆。如果嚴(yán)格遵循 volatile 的使用條件 —— 即變量真正獨(dú)立于其他變量和自己以前的值 —— 在某些情況下可以使用 volatile 代替 synchronized 來(lái)簡(jiǎn)化代碼。然而邮绿,使用 volatile 的代碼往往比使用鎖的代碼更加容易出錯(cuò)渠旁。本文介紹的模式涵蓋了可以使用 volatile 代替 synchronized 的最常見(jiàn)的一些用例。遵循這些模式(注意使用時(shí)不要超過(guò)各自的限制)可以幫助您安全地實(shí)現(xiàn)大多數(shù)用例船逮,使用 volatile 變量獲得更佳性能顾腊。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市挖胃,隨后出現(xiàn)的幾起案子杂靶,更是在濱河造成了極大的恐慌,老刑警劉巖冠骄,帶你破解...
    沈念sama閱讀 217,657評(píng)論 6 505
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件伪煤,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡凛辣,警方通過(guò)查閱死者的電腦和手機(jī)抱既,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,889評(píng)論 3 394
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái)扁誓,“玉大人防泵,你說(shuō)我怎么就攤上這事蚀之。” “怎么了捷泞?”我有些...
    開(kāi)封第一講書人閱讀 164,057評(píng)論 0 354
  • 文/不壞的土叔 我叫張陵足删,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我锁右,道長(zhǎng)失受,這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書人閱讀 58,509評(píng)論 1 293
  • 正文 為了忘掉前任咏瑟,我火速辦了婚禮拂到,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘码泞。我一直安慰自己兄旬,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,562評(píng)論 6 392
  • 文/花漫 我一把揭開(kāi)白布余寥。 她就那樣靜靜地躺著领铐,像睡著了一般。 火紅的嫁衣襯著肌膚如雪宋舷。 梳的紋絲不亂的頭發(fā)上绪撵,一...
    開(kāi)封第一講書人閱讀 51,443評(píng)論 1 302
  • 那天,我揣著相機(jī)與錄音肥缔,去河邊找鬼莲兢。 笑死,一個(gè)胖子當(dāng)著我的面吹牛续膳,可吹牛的內(nèi)容都是我干的改艇。 我是一名探鬼主播,決...
    沈念sama閱讀 40,251評(píng)論 3 418
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼坟岔,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼谒兄!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起社付,我...
    開(kāi)封第一講書人閱讀 39,129評(píng)論 0 276
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤承疲,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后鸥咖,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體燕鸽,經(jīng)...
    沈念sama閱讀 45,561評(píng)論 1 314
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,779評(píng)論 3 335
  • 正文 我和宋清朗相戀三年啼辣,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了啊研。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 39,902評(píng)論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖党远,靈堂內(nèi)的尸體忽然破棺而出削解,到底是詐尸還是另有隱情,我是刑警寧澤沟娱,帶...
    沈念sama閱讀 35,621評(píng)論 5 345
  • 正文 年R本政府宣布氛驮,位于F島的核電站,受9級(jí)特大地震影響济似,放射性物質(zhì)發(fā)生泄漏矫废。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,220評(píng)論 3 328
  • 文/蒙蒙 一碱屁、第九天 我趴在偏房一處隱蔽的房頂上張望磷脯。 院中可真熱鬧蛾找,春花似錦娩脾、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書人閱讀 31,838評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至幻枉,卻和暖如春碰声,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背熬甫。 一陣腳步聲響...
    開(kāi)封第一講書人閱讀 32,971評(píng)論 1 269
  • 我被黑心中介騙來(lái)泰國(guó)打工胰挑, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人椿肩。 一個(gè)月前我還...
    沈念sama閱讀 48,025評(píng)論 2 370
  • 正文 我出身青樓瞻颂,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親郑象。 傳聞我的和親對(duì)象是個(gè)殘疾皇子贡这,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,843評(píng)論 2 354

推薦閱讀更多精彩內(nèi)容

  • Java8張圖 11、字符串不變性 12厂榛、equals()方法盖矫、hashCode()方法的區(qū)別 13、...
    Miley_MOJIE閱讀 3,704評(píng)論 0 11
  • 從三月份找實(shí)習(xí)到現(xiàn)在击奶,面了一些公司辈双,掛了不少,但最終還是拿到小米柜砾、百度湃望、阿里、京東、新浪喜爷、CVTE冗疮、樂(lè)視家的研發(fā)崗...
    時(shí)芥藍(lán)閱讀 42,246評(píng)論 11 349
  • 最近再讀萬(wàn)維鋼老師的《高手》一書 其中有個(gè)觀點(diǎn),讓我耳目一新檩帐。文章開(kāi)始拋出了一個(gè)很能吸睛的話題术幔。讀書跟精英到底...
    暫懸閱讀 368評(píng)論 0 0
  • 簡(jiǎn)介:遭到初戀的背叛,在職場(chǎng)的洗禮湃密,與藍(lán)顏扯不清理還亂的糾葛诅挑,看豪放女路小莫的成長(zhǎng)經(jīng)歷。難以自拔的初戀泛源,讓路小莫學(xué)...
    hi羽佳閱讀 390評(píng)論 0 0
  • 又到一年十月一拔妥,今年朋友圈里充斥著訂婚,結(jié)婚的消息达箍,羨慕又無(wú)能為力没龙,看看自己,真的是鮮明的對(duì)比缎玫。路上還在想為什么我...
    檸檬安然閱讀 133評(píng)論 0 0