你真的了解synchronized和volatile吗？

原文来自于公众号：三不猴子欢迎关注我的公众号，公众号内回复666获取面试资料，回复电子书获取200本PDF电子书

什么是cas？

cas：compare and swap 比较然后交换，它在没有锁的状态下可以保证多线程的对值得更新。我们可以看一下在jdk中对cas的应用：

/**
 * Atomically increments by one the current value.
 *
 * @return the updated value
 */
public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}


public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));

        return var5;
}

在Atomic原子类中的自增操作中就使用到了compareAndSwapInt，这里的cas的实现使用的native方法。用一张流程图来理解什么是cas。


image

我们先会存一下要修改的值，再修改之后再去看一下要修改的值是不是还是我们存的值如果是一致的则修改，我们在更新数据常用的乐观锁就是用的cas的机制。

在这里面有个ABA的问题：所谓ABA就是在线程A存了值之后，有个线程B对这个值进行修改，B修改了多次最后结果还是原来那个值，这就是ABA问题，此时需要根据业务场景判断这个值得修改是否需要感知。如果需要感知就可以给这个值再加上一个版本号。

我们用一段代码演示一下cas中ABA的问题吧

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * create by yanghongxing on 2020/5/8 11:03 下午
 */
public class ABA {
    private static AtomicInteger atomicInt = new AtomicInteger(100);

    public static void main(String[] args) throws InterruptedException {
        // 对一个AtomicInteger的值该两次，最后结果与之前相同
        Thread intT1 = new Thread(() -> {
            atomicInt.compareAndSet(100, 101);
            atomicInt.compareAndSet(101, 100);
        });
        
        Thread intT2 = new Thread(() -> {
            try {
                TimeUnit.SECONDS.sleep(1);
            } catch (InterruptedException e) {
            }
            boolean c3 = atomicInt.compareAndSet(100, 101);
            // true，执行成功
            System.out.println(c3);
        });
        intT1.start();
        intT2.start();
    }
}

使用jdk中的AtomicStampedReference可以解决这个问题。最后我们看一下cas实现原理，看一下最后native方法的源码 jdk8u: atomic_linux_x86.inline.hpp

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;

汇编指令 我们看这一条

__asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"

asm表示汇编指令，lock表示锁，if如果 mp（%4）表示cpu是多核， cmpxchgl表示 cmp exchange 全称 compare and exchange。
最终实现：

lock cmpxchg 指令

这条汇编指令(硬件指令)表示如果是多核CPU则加上锁。

Java对象在内存的布局

我们先了解一下Java对象在内存中的（详细）布局，这个布局与Java锁的实现息息相关。
使用工具：JOL = Java Object Layout

<dependencies>
    <!-- https://mvnrepository.com/artifact/org.openjdk.jol/jol-core -->
    <dependency>
        <groupId>org.openjdk.jol</groupId>
        <artifactId>jol-core</artifactId>
        <version>0.9</version>
    </dependency>
</dependencies>

使用示例

public class ShowJOL {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }
}

输出

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

OFFSET:从第几个位置开始
size:大小，单位字节，

TYPE DESCRIPTION：类型描述，上面的示例就是object header对象头，

VALUE：值

loss due to the next object alignment: 由于下一个对象对齐而造成的损失,我们看下面这张图。


image

markword：关于锁的信息。

class pointer: 表示对象是属于哪个类的。

instance data：字面理解实例数据，比如在在对象中创建了一个int a 就占4个字节，long b就占8个字节。

padding data：如果上面的数据所占用的空间不能被8整除，padding则占用空间凑齐使之能被8整除。被8整除在读取数据的时候会比较快。

对着这张图我们再看看上面JOL打印出来的数据，第一个和第二个都是markword各 4个字节，第三个是class pointer4个字节，本来还有 instance data 用来存成员变量的但是我们写的没有所以为0，这些总共加起来12个字节不能被8整除，所以我们要对齐加4个字节。（注这里的内存占用是默认开启字节压缩XX:+UseCompressedClassPointers -XX:+UseCompressedOops）

看完了这些东西我们再来执行一下下面的代码

/**
 * create by yanghongxing on 2020/5/11 11:52 下午
 */
public class ShowJOL {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }
}

执行结果：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

对比这个的输出和第一次我们打印的输出，我们可以得出结论synchronized锁的信息是记录在markword上。
我们做Java开发的经常听到的一句话就是synchronized是个重量级的锁，事实上一定是这样吗？我们可以通过分析markword看看synchronized加锁过程，在早期jdk1.0的时候jdk每次申请的就是重量级的锁，性能比较差，随着后面jdk的升级synchronized的性能有所提升，synchronized并不是一开始就加重量级的锁，而是有个慢慢升级的过程。先来看表格

image

偏向锁Biased Locking：Java6引入的一项多线程优化，偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程是不需要触发同步的，这种情况下，就会给线程加一个偏向锁。
如果在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程会被挂起，JVM会消除它身上的偏向锁，将锁恢复到标准的轻量级锁。
自旋锁：自旋锁的目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。一直在自旋也是占用CPU的，如果自旋的线程非常多，自旋次数也非常大CPU可能会跑满，所以需要升级。
重量级锁：内核态的锁，资源开销较大。内部会将等待中的线程进行wait处理，防止消耗CPU。

结合这张表格我们再写一个示例看看synchronized在没有锁竞争的情况下默认是怎么样的。

/**
 * create by yanghongxing on 2020/5/11 11:52 下午
 */
public class ShowJOL {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(Integer.toHexString(o.hashCode()));
        System.out.println(ClassLayout.parseInstance(o).toPrintable());

        synchronized (o) {
            System.out.println(Integer.toHexString(o.hashCode()));
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }
}

然后看输出:

5f8ed237

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 37 d2 8e (00000001 00110111 11010010 10001110) (-1898825983)
      4     4        (object header)                           5f 00 00 00 (01011111 00000000 00000000 00000000) (95)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           90 29 7d 06 (10010000 00101001 01111101 00000110) (108865936)
      4     4        (object header)                           00 70 00 00 (00000000 01110000 00000000 00000000) (28672)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

Disconnected from the target VM, address: '127.0.0.1:62501', transport: 'socket'

Process finished with exit code 0

我们在第一行打印了这个Object的hashcode的16进制编码，对比没有加锁的输出这hashcode是存在对象的markword中的。我们再看这个未加锁的markword的二级制值：00000001 00110111 11010010 10001110，看前8位的倒数3位也就001（口语描述不知道是不是准确）对比上面的表格也就是无锁状态，我们再看第二个markword的值000，对应表格就是轻量锁、自旋锁。我们再使用一个存在锁竞争的例子看看是怎么样的。

/**
 * create by yanghongxing on 2020/5/12 7:13 下午
 */
public class MarkwordMain {


    private static Object OBJ = new Object();

    private static void printf() {
        System.out.println(ClassLayout.parseInstance(OBJ).toPrintable());
    }

    private static Runnable RUNNABLE = () -> {
        synchronized (OBJ) {
            printf();
        }
    };

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 3; i++) {
            new Thread(RUNNABLE).start();
        }
        Thread.sleep(Integer.MAX_VALUE);
    }
}

这段代码中我们使用了三个线程去竞争打印这个内存分布的操作，看看输出结果，

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           5a 59 82 ef (01011010 01011001 10000010 11101111) (-276670118)
      4     4        (object header)                           f9 7f 00 00 (11111001 01111111 00000000 00000000) (32761)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           5a 59 82 ef (01011010 01011001 10000010 11101111) (-276670118)
      4     4        (object header)                           f9 7f 00 00 (11111001 01111111 00000000 00000000) (32761)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           5a 59 82 ef (01011010 01011001 10000010 11101111) (-276670118)
      4     4        (object header)                           f9 7f 00 00 (11111001 01111111 00000000 00000000) (32761)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

我们看到是010，对应表格就是重量级锁。

synchronized 锁升级时按照，new - 偏向锁 - 轻量级锁 （无锁, 自旋锁，自适应自旋）- 重量级锁的过程升级的。偏向锁 - markword 上记录当前线程指针，下次同一个线程加锁的时候，不需要争用，只需要判断线程指针是否同一个，所以，偏向锁，偏向加锁的第一个线程 。

有争用 - 锁升级为轻量级锁 - 每个线程有自己的LockRecord在自己的线程栈上，用CAS去争用markword的LockRecord的指针，指针指向哪个线程的LockRecord，哪个线程就拥有锁

自旋超过10次，升级为重量级锁 - 如果太多线程自旋 CPU消耗过大，不如升级为重量级锁，进入等待队列（不消耗CPU）-XX:PreBlockSpin

自旋锁在 JDK1.4.2 中引入，使用 -XX:+UseSpinning 来开启。JDK 6 中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。

自适应自旋锁意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。

synchronized实现原理

Java源代码级别

synchronized(对象)

字节码层级

使用idea插件jclasslib插件查看字节码，我们以之前代码为例

public class ShowJOL {
    public static void main(String[] args) {
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
    }
}
image
public class ShowJOL {
    public static void main(String[] args) {
        Object o = new Object();
        synchronized (o) {
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }
}
image

在字节码层面是以monitorenter作为开始锁的开始，以moniterexit作为结束。

汇编级别

我们使用hsdis工具对Java源码进行反编译为汇编代码

/**
 * create by yanghongxing on 2020/5/12 11:45 下午
 */
public class SynchronizedTest {

    private static int c;

    public static synchronized void sync() {
    }

    public static void noSynchronized() {
        int a = 1;
        int b = 2;
        c = a + b;
    }

    public static void main(String[] args) {
        for (int j = 0; j < 1000_000; j++) {
            sync();
            noSynchronized();
        }
    }
}

  0x00000001195d2e4e: lock cmpxchg %r11,(%r10)
  0x00000001195d2e53: je     0x00000001195d2da0
  0x00000001195d2e59: mov    %r13,(%rsp)
  0x00000001195d2e5d: movabs $0x79578d830,%rsi  ;   {oop(a 'java/lang/Class' = 'com/example/demo/SynchronizedTest')}
  0x00000001195d2e67: lea    0x10(%rsp),%rdx
  0x00000001195d2e6c: data32 xchg %ax,%ax
  0x00000001195d2e6f: callq  0x0000000119525860  ; OopMap{off=404}
                                                ;*synchronization entry
                                                ; - com.example.demo.SynchronizedTest::sync@-1 (line 11)

我们看到了开篇提到的lock cmpxchg这条汇编命令，结论是synchronized底层也是使用cas的方式来实现锁。

锁消除 lock eliminate

public void add(String str1,String str2){
         StringBuffer sb = new StringBuffer();
         sb.append(str1).append(str2);
}

我们都知道 StringBuffer 是线程安全的，因为它的关键方法都是被 synchronized 修饰过的，但我们看上面这段代码，我们会发现，sb 这个引用只会在 add 方法中使用，不可能被其它线程引用（因为是局部变量，栈私有），因此 sb 是不可能共享的资源，JVM 会自动消除 StringBuffer 对象内部的锁。

锁粗化 lock coarsening

public String test(String str){
       int i = 0;
       StringBuffer sb = new StringBuffer():
       while(i < 100){
           sb.append(str);
           i++;
       }
       return sb.toString():
}

JVM 会检测到这样一连串的操作都对同一个对象加锁（while 循环内 100 次执行 append，没有锁粗化的就要进行 100 次加锁/解锁），此时 JVM 就会将加锁的范围粗化到这一连串的操作的外部（比如 while 虚幻体外），使得这一连串操作只需要加一次锁即可。

volatile实现应用和原理

首先了解一下volatile的作用：

  1. 禁止指令重拍

  2. 保证内存的可见性

    先看个看个示例

public class VolatileExample {
    // 可见性参数
    /*volatile*/ static boolean flag = false;

    public static void main(String[] args) {
        new Thread(() -> {
            try {
                // 暂停 0.5s 执行
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            flag = true;
            System.out.println("flag 被修改成 true");
        }).start();
        // 一直循环检测 flag=true
        while (true) {
            if (flag) {
                System.out.println("检测到 flag 变为 true");
                break;
            }
        }
    }
}

在不加volatile的时候，在子线程中修改了flag为true，但是父线程中是不可见的，我们加上volatile修饰时”检测到 flag 变为 true“可以输出。再看一个指令重排的例子。

public class VolatileExample1 {
    // 指令重排参数
    private static int a = 0, b = 0;
    private static int x = 0, y = 0;

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            Thread t1 = new Thread(() -> {
                // 有可能发生指令重排，先 x=b 再 a=1
                a = 1;
                x = b;
            });
            Thread t2 = new Thread(() -> {
                // 有可能发生指令重排，先 y=a 再 b=1
                b = 1;
                y = a;
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println("第 " + i + "次，x=" + x + " | y=" + y);
            if (x == 0 && y == 0) {
                // 发生了指令重排
                break;
            }
            // 初始化变量
            a = 0;
            b = 0;
            x = 0;
            y = 0;
        }
    }
}

程序停止的时候只有先执行， x = b;然后执行 y = a;最后执行 a = 1和b = 1语句时，即发生了指令重排。我们再说一个禁止指令重排的应用。单例模式中保证多线程环境下的单例我们通常会使用双重校验的机制，实现代码如下：

public class LazyDoubleCheckSingleton {
    private volatile static LazyDoubleCheckSingleton lazyDoubleCheckSingleton = null;
    private LazyDoubleCheckSingleton() {

    }
    public static LazyDoubleCheckSingleton getInstance() {
        if (lazyDoubleCheckSingleton == null) {
            synchronized (LazyDoubleCheckSingleton.class) {
                if (lazyDoubleCheckSingleton == null) {
                    lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton();
                }
            }
        }
        return lazyDoubleCheckSingleton;
    }
}

对于要保证线程安全的单例最容易想到的方式就是在getInstance方法上加上synchronized就好啦，但是这种方式锁的力度太大，性能不是很好，所以我们在getInstance方法上先判断一下lazyDoubleCheckSingleton这个变量是否为空，如果为空我们就进行加锁。在再进行一次判断如果为空就创建一个对象。这里进行了两次判断所谓通常被称为双重校验。这里的成员变量为什么要加volatile？不加volatile会怎么样？为弄明白这个问题我们先了解一下创建一个对象的过程。

以lazyDoubleCheckSingleton = new LazyDoubleCheckSingleton()为例，

  1. 分配内存给这个对象

  2. 初始化对象

  3. 设置lazyDoubleCheckSingleton 指向刚分配的内存地址

    如果我们不使用volatile修饰这个lazyDoubleCheckSingleton的话可能会出现，1-3-2的执行流程，当执行1-3步之后，此时lazyDoubleCheckSingleton变量已经不为空了，他的值是new出对象的内存地址，此时有个线程过来了 到了if (lazyDoubleCheckSingleton == null) 这一步，判断不为空，就直接return出去了，这个线程拿到的就是一个未初始化的线程。所以我们要使用volatile修饰，保证指令按照1-2-3的顺序执行。下面加张图方便直观了解这个过程。

image

对于在多线程中的执行就变成下面的方式了。
多线程.png


image
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 159,716评论 4赞 364
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,558评论 1赞 294
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 109,431评论 0赞 244
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 44,127评论 0赞 209
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,511评论 3赞 287
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,692评论 1赞 222
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,915评论 2赞 313
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,664评论 0赞 202
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,412评论 1赞 246
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,616评论 2赞 245
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,105评论 1赞 260
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,424评论 2赞 254
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,098评论 3赞 238
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,096评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,869评论 0赞 197
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,748评论 2赞 276
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,641评论 2赞 271