JVM常量池浅析

提纲.png

  需要说明的一点是，这篇文章是以《深入理解Java虚拟机》第二版这本书为基础的，这里假设大家已经了解了JVM的运行时区域，以及class文件结构，类加载流程等基础内容。当然，文中我们也会提一提相关的内容作为复习总结

一.JVM有几种常量池

  主要分为：Class文件常量池、运行时常量池，当然还有全局字符串常量池，以及基本类型包装类对象常量池

1.Class文件常量池

  阅读过《深入理解Java虚拟机》这本书第6章内容的小伙伴肯定知道，class文件是一组以8位字节为单位的二进制数据流，在java代码的编译期间，我们编写的.java文件就被编译为.class文件格式的二进制数据存放在磁盘中，其中就包括class文件常量池。
  class 文件中存在常量池(非运行时常量池)，其在编译阶段就已经确定；JVM 规范对 class 文件结构有着严格的规范，必须符合此规范的 class 文件才会被 JVM 认可和装载。

为了方便说明，我们这里先写一个很简单的类:

class JavaBean{
    private int value = 1;
    public String s = "abc";
    public final static int f = 0x101;

    public void setValue(int v){
        final int temp = 3;
        this.value = temp + v;
    }

    public int getValue(){
        return value;
    }
}

通过javah命令编译之后，用javap -v 命令查看编译后的文件:

class JavaBasicKnowledge.JavaBean
  minor version: 0
  major version: 52
  flags: ACC_SUPER
Constant pool:
   #1 = Methodref          #6.#29         // java/lang/Object."<init>":()V
   #2 = Fieldref           #5.#30         // JavaBasicKnowledge/JavaBean.value:I
   #3 = String             #31            // abc
   #4 = Fieldref           #5.#32         // JavaBasicKnowledge/JavaBean.s:Ljava/lang/String;
   #5 = Class              #33            // JavaBasicKnowledge/JavaBean
   #6 = Class              #34            // java/lang/Object
   #7 = Utf8               value
   #8 = Utf8               I
   #9 = Utf8               s
  #10 = Utf8               Ljava/lang/String;
  #11 = Utf8               f
  #12 = Utf8               ConstantValue
  #13 = Integer            257
  #14 = Utf8               <init>
  #15 = Utf8               ()V
  #16 = Utf8               Code
  #17 = Utf8               LineNumberTable
  #18 = Utf8               LocalVariableTable
  #19 = Utf8               this
  #20 = Utf8               LJavaBasicKnowledge/JavaBean;
  #21 = Utf8               setValue
  #22 = Utf8               (I)V
  #23 = Utf8               v
  #24 = Utf8               temp
  #25 = Utf8               getValue
  #26 = Utf8               ()I
  #27 = Utf8               SourceFile
  #28 = Utf8               StringConstantPool.java
  #29 = NameAndType        #14:#15        // "<init>":()V
  #30 = NameAndType        #7:#8          // value:I
  #31 = Utf8               abc
  #32 = NameAndType        #9:#10         // s:Ljava/lang/String;
  #33 = Utf8               JavaBasicKnowledge/JavaBean
  #34 = Utf8               java/lang/Object

可以看到这个命令之后我们得到了该class文件的版本号、常量池、已经编译后的字节码指令(处于篇幅原因这里省略)，下面我们会对照这个class文件来讲解：

  这里我们需要说明一下，既然是常量池，那么其中个存放的肯定是“常量”，那么什么是“常量”呢？class文件常量池主要存放两大常量：字面量和符号引用：

1).字面量

字面量接近于java语言层面的常量概念，主要包括：

  • 文本字符串，也就是我们经常声明的：public String s = "abc";中的"abc" 
 #9 = Utf8               s
 #3 = String             #31            // abc
 #31 = Utf8              abc
  • 用final修饰的成员变量，包括静态变量、实例变量和局部变量 
 #11 = Utf8               f
 #12 = Utf8               ConstantValue
 #13 = Integer            257

  这里需要说明的一点，上面说的存在于常量池的字面量，指的是数据的值，也就是abc和0x101(257),通过上面对常量池的观察可知这两个字面量是确实存在于常量池的。
  而对于基本类型数据(甚至是方法中的局部变量)，也就是上面的private int value = 1;常量池中只保留了他的的字段描述符I和字段的名称value，他们的字面量不会存在于常量池：

2).符号引用

符号引用主要设涉及编译原理方面的概念，包括下面三类常量:

  • 类和接口的全限定名，也就是Ljava/lang/String;这样，将类名中原来的"."替换为"/"得到的，主要用于在运行时解析得到类的直接引用，像上面：
 #5 = Class              #33            // JavaBasicKnowledge/JavaBean
 #33 = Utf8               JavaBasicKnowledge/JavaBean
  • 字段的名称和描述符，字段也就是类或者接口中声明的变量，包括类级别变量(static)和实例级的变量 
 #4 = Fieldref           #5.#32         // JavaBasicKnowledge/JavaBean.value:I
 #5 = Class              #33            // JavaBasicKnowledge/JavaBean
 #32 = NameAndType       #7:#8          // value:I

 #7 = Utf8               value
 #8 = Utf8               I

 //这两个是局部变量，值保留字段名称
 #23 = Utf8               v
 #24 = Utf8               temp

可以看到，class文件的常量池中也存在方法中的局部变量，但是没有；但是常量池外面的字段表中不包括局部变量；

  • 方法的名称和描述符，方法的描述类似于JNI动态注册时的“方法签名”，也就是参数类型+返回值类型:
  #21 = Utf8               setValue
  #22 = Utf8               (I)V

  #25 = Utf8               getValue
  #26 = Utf8               ()I

2.运行时常量池

  运行时常量池是方法区的一部分，所以也是全局共享的。我们知道，jvm在执行某个类的时候，必须经过加载、连接(验证,准备,解析)、初始化，在第一步的加载阶段，虚拟机需要完成下面3件事情：

  • 通过一个类的“全限定名”来获取此类的二进制字节流
  • 将这个字节流所代表的静态储存结构转化为方法区的运行时数据结构
  • 在内存中生成一个类代表这类的java.lang.Class对象，作为方法区这个类的各种数据访问的入口

  这里需要说明的一点是，类对象和普通的实例对象是不同的，类对象是在类加载的时候生成的，普通的实例对象一般是在调用new之后创建。

  上面第二条，将class字节流代表的静态储存结构转化为方法区的运行时数据结构，其中就包含了class文件常量池进入运行时常量池的过程。这里需要强调一下，不同的类共用一个运行时常量池(http://blog.csdn.net/fan2012huan/article/details/52759614)，同时在进入运行时常量池的过程中，多个class文件中常量池中相同的字符串只会存在一份在运行时常量池中，这也是一种优化。

  运行时常量池的作用是存储 Java class文件常量池中的符号信息。运行时常量池 中保存着一些 class 文件中描述的符号引用，同时在类加载的“解析阶段”还会将这些符号引用所翻译出来的直接引用(直接指向实例对象的指针)存储在 运行时常量池 中。

  运行时常量池相对于 class 常量池一大特征就是其具有动态性，Java 规范并不要求常量只能在运行时才产生，也就是说运行时常量池中的内容并不全部来自 class 常量池，class 常量池并非运行时常量池的唯一数据输入口；在运行时可以通过代码生成常量并将其放入运行时常量池中，这种特性被用的较多的是String.intern()（这个方法下面将会详细讲）。

二.全局字符串常量池

  字符串常量池单独列出来说有两个原因：

  • 不同于基本数据类型，String类型是一个final对象,他的字面量存在于class文件常量池中，但是运行期行为却与普通常量不同
  • JDK 1.7中，字符串常量池和类引用被移动到了Java堆中(与运行时常量池分离)，因此不同版本的String行为也有所差异

1.Java中创建字符串对象的两种方式

  这个问题我想大家一定非常清楚了吧，一般有如下两种：

  • String s0 =”hellow”；
  • String s1=new String (“hellow”);

  第一种我们之前已经见过了，这种方式声明的字面量hellow是在编译期就已经确定的，它会直接进入class文件常量池中；当运行期间在全局字符串常量池中会保存它的一个引用，实际上最终还是要在堆上创建一个”hellow”对象，这个后面会讲。
  第二种方式方式使用了new String()，也就是调用了String类的构造函数，我们知道new指令是创建一个类的实例对象并完成加载初始化的，因此这个字符串对象是在运行期才能确定的，创建的字符串对象是在堆内存上。
  因此此时调用System.out.println(s0 == s1);返回的肯定是flase,因此==符号比较的是两边元素的地址，s1和s0都存在于堆上，但是地址肯定不相同。

下面我们来看看几个非常常见的题目：

String s1 = "Hello";
String s2 = "Hello";
String s3 = "Hel" + "lo";
String s4 = "Hel" + new String("lo");
String s5 = new String("Hello");
String s7 = "H";
String s8 = "ello";
String s9 = s7 + s8;

System.out.println(s1 == s2);  // true
System.out.println(s1 == s3);  // true
System.out.println(s1 == s4);  // false
System.out.println(s1 == s9);  // false
1) s1 == s2

  这个对比第一部分常量池的讲解应该很好理解，因为字面量"Hello"在运行时会进入运行时常量池(中的字符串常量池，JDK1.7以前)，同时同一份字面量只会保留一份，所有引用都指向这一份字符串，自然引用的地址也就相同了。

2) s1 == s3

  这个主要牵扯String"+"号编译器优化的问题，s3虽然是动态拼接出来的字符串，但是所有参与拼接的部分都是已知的字面量，在编译期间，这种拼接会被优化，编译器直接帮你拼好，因此String s3 = "Hel" + "lo";在class文件中被优化成String s3 = "Hello";，所以s1 == s3成立。

public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=3, locals=3, args_size=1
         0: ldc           #2                  // String Hello
         2: astore_1
         3: ldc           #2                  // String Hello
         5: astore_2
         6: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         9: aload_1
        10: aload_2
        11: if_acmpne     18
        14: iconst_1
        15: goto          19
        18: iconst_0
        19: invokevirtual #4                  // Method java/io/PrintStream.println:(Z)V
        22: return

  通过查看编译后的方法代码，可以看到这里加入操作数栈的ldc指令有两次，都是“Hello”，没有出现“Hel”或者“lo”,同时这两个“Hello”指向常量池的通过一个地址，都是#2，因此常量池中也只存在一个“Hello”字面量。

3) s1 != s4

  其实这个也不难理解，但是我们还是先来看看编译后的字节码：

public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=4, locals=3, args_size=1
         0: ldc           #2                  // String Hello
         2: astore_1
         3: new           #3                  // class java/lang/StringBuilder
         6: dup
         7: invokespecial #4                  // Method java/lang/StringBuilder."<init>":()V
        10: ldc           #5                  // String Hel
        12: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        15: new           #7                  // class java/lang/String
        18: dup
        19: ldc           #8                  // String lo
        21: invokespecial #9                  // Method java/lang/String."<init>":(Ljava/lang/String;)V
        24: invokevirtual #6                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        27: invokevirtual #10                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        30: astore_2
        31: getstatic     #11                 // Field java/lang/System.out:Ljava/io/PrintStream;
        34: aload_1
        35: aload_2
        36: if_acmpne     43
        39: iconst_1
        40: goto          44
        43: iconst_0
        44: invokevirtual #12                 // Method java/io/PrintStream.println:(Z)V
        47: return

  我们就不对操作符一一解释了，可以看到这次确实出现了“String Hel”和“String lo”，原因上面我们也说过，这是因为new String("lo")在堆中new了一个String对象出来，而“Hel”字面量是通过另一种操作在堆中创建的对象，这两个在堆中不同地方创建的对象是通过StringBuilder.append方法拼接出来的，并且最终会调用StringBuilder.toString方法输出(最终输出的也是“Hello”),这些通过上面字节码的分析都可以看得出来，我们来看看StringBuilder.toString方法：

@Override
    public String toString() {
        // Create a copy, don't share the array
        return new String(value, 0, count);
    }

  可以看到，这个最终是拼接出来的一个String对象，也就是说，s4指向的一个经过StringBuilder拼接之后的String对象，而s1指向的是另一个对象，这两个对象的地址当然是不同的了。

4) s1 != s9
public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=3, locals=5, args_size=1
         0: ldc           #2                  // String Hello
         2: astore_1
         3: ldc           #3                  // String H
         5: astore_2
         6: ldc           #4                  // String ello
         8: astore_3
         9: new           #5                  // class java/lang/StringBuilder
        12: dup
        13: invokespecial #6                  // Method java/lang/StringBuilder."<init>":()V
        16: aload_2
        17: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        20: aload_3
        21: invokevirtual #7                  // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        24: invokevirtual #8                  // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        27: astore        4
        29: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
        32: aload_1
        33: aload         4
        35: if_acmpne     42
        38: iconst_1
        39: goto          43
        42: iconst_0
        43: invokevirtual #10                 // Method java/io/PrintStream.println:(Z)V
        46: return

  从变异后的字节码看，这和3)中的情况是相同的，都是通过StringBuilder.append拼接后toString输出的全新对象，至于这个对象被分配到哪里去了，我们也不知道。

2.String s1 = "Hello"，到底有没有在堆中创建对象？

JVM运行时数据区.png

  上面这张图比是我们通常理解的JVM运行时数据区的结构，但是还有不完整的地方，为了说明全局字符串常量池概念，就必须拿出下面这张图：

JVM运行时数据区Plus.png

这张图中，可以看到，方法区实际上是在一块叫“非堆”的区域包含——可以简单粗略的理解为非堆中包含了永生代，而永生代中又包含了方法区和字符串常量池，我们放大一下，一遍大家看的更清楚些:

非堆.png

  其中的Interned String就是全局共享的“字符串常量池（String Pool）”，和运行时常量池不是一个概念。但我们在代码中申明String s1 = "Hello";这句代码后，在类加载的过程中，类的class文件的信息会被解析到内存的方法区里。
  class文件里常量池里大部分数据会被加载到“运行时常量池”，包括String的字面量；但同时“Hello”字符串的一个引用会被存到同样在“非堆”区域的“字符串常量池”中，而"Hello"本体还是和所有对象一样，创建在Java堆中。

  当主线程开始创建s1时，虚拟机会先去字符串池中找是否有equals(“Hello”)的String，如果相等就把在字符串池中“Hello”的引用复制给s1；如果找不到相等的字符串，就会在堆中新建一个对象，同时把引用驻留在字符串池，再把引用赋给str。
  当用字面量赋值的方法创建字符串时，无论创建多少次，只要字符串的值相同，它们所指向的都是堆中的同一个对象。

字符串常量池的本质

  看到这里，是时候引出字符串常量池的概念了：字符串常量池是JVM所维护的一个字符串实例的引用表，在HotSpot VM中，它是一个叫做StringTable的全局表。在字符串常量池中维护的是字符串实例的引用，底层C++实现就是一个Hashtable。这些被维护的引用所指的字符串实例，被称作”被驻留的字符串”或”interned string”或通常所说的”进入了字符串常量池的字符串”。
  再强调一遍：运行时常量池在方法区(Non-heap)，而JDK1.7后，字符串常量池被移到了heap区，因此两者根本就不是一个概念。

3.String"字面量" 是何时进入字符串常量池的?

先说结论：在执行ldc指令时，该指令表示int、float或String型常量从常量池推送至栈顶

JVM规范里Class文件的常量池项的类型，有两种东西(这段内容建议配合看书上168页内容)：

  • CONSTANT_Utf8_info
  • CONSTANT_String_info

  在HotSpot VM中，运行时常量池里，CONSTANT_Utf8_info可以表示Class文件的方法、字段等等，其结构如下：

CONSTANT_Utf8_info结构.png

首先是1个字节的tag,表示这是一个CONSTANT_Utf8_info结构的常量，然后是两个字节的length，表示要储存字节的长度，之后是一个字节的byte数组，表示真正的储存的length个长度的字符串。这里需要注意的是，一个字节只是代表这里有一个byte类型的数组，而这个数组的长度当然可以远远大于一个字节。当然，由于CONSTANT_Utf8_info结构只能用u2即两个字节来表示长度，因此长度的最大值为2byte，也就是65535(注意这跟Android中dex字节码65535方法数限制没有什么关系，但是道理是一样的).

  后者CONSTANT_String_info是String常量的类型，但它并不直接持有String常量的内容，而是只持有一个index，这个index所指定的另一个常量池项必须是一个CONSTANT_Utf8类型的常量，这里才真正持有字符串的内容。

![Uploading 提纲_620529.png . . .]

  CONSTANT_Utf8会在类加载的过程中就全部创建出来，而CONSTANT_String则是lazy resolve的，在第一次引用该项的ldc指令被第一次执行到的时候才会resolve。在尚未resolve的时候，HotSpot VM把它的类型叫做JVM_CONSTANT_UnresolvedString，内容跟Class文件里一样只是一个index；等到resolve过后这个项的常量类型就会变成最终的JVM_CONSTANT_String，
  也就是说，就HotSpot VM的实现来说，加载类的时候，那些字符串字面量会进入到当前类的运行时常量池，不会进入全局的字符串常量池（即在StringTable中并没有相应的引用，在堆中也没有对应的对象产生），在执行ldc指令时，触发lazy resolution这个动作：
  ldc字节码在这里的执行语义是：到当前类的运行时常量池（runtime constant pool，HotSpot VM里是ConstantPool + ConstantPoolCache）去查找该index对应的项，如果该项尚未resolve则resolve之，并返回resolve后的内容。
  在遇到String类型常量时，resolve的过程如果发现StringTable已经有了内容匹配的java.lang.String的引用，则直接返回这个引用，反之，如果StringTable里尚未有内容匹配的String实例的引用，则会在Java堆里创建一个对应内容的String对象，然后在StringTable记录下这个引用，并返回这个引用出去。

  可见，ldc指令是否需要创建新的String实例，全看在第一次执行这一条ldc指令时，StringTable是否已经记录了一个对应内容的String的引用。

4.String.intern()用法

String.intern()官方给的定义：

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.

实际上，就是去拿String的内容去Stringtable里查表，如果存在，则返回引用，不存在，就把该对象的"引用"存在Stringtable表里。

这里采用《深入理解Java虚拟机》书上的两个例子来解释这个问题，第一个例子在P57页：

public class RuntimeConstantPoolOOM{
    public static void main(String[] args) {

         String str1 = new StringBuilder("计算机").append("软件").toString();
         System.out.println(str1.intern() == str1);

         String str2 = new StringBuilder("ja").append("va").toString();
         System.out.println(str2.intern() == str2);

    }
}

以上代码，在 JDK6 下执行结果为 false、false，在 JDK7 以上执行结果为 true、false。

  首先我们调用StringBuilder创建了一个"计算机软件"String对象，因为调用了new关键字，因此是在运行时创建，之前JVM中是没有这个字符串的。
  在 JDK6 下，intern()会把首次遇到的字符串实例复制到永久代中，返回的也是这个永久代中字符串实例的引用；而在JDK1.7开始，intern()方法不在复制字符串实例，tring 的 intern 方法首先将尝试在常量池中查找该对象的引用，如果找到则直接返回该对象在常量池中的引用地址

  因此在1.7中，“计算机软件”这个字符串实例只存在一份，存在于java堆中！通过3中的分析，我们知道当String str1 = new StringBuilder("计算机").append("软件").toString();这句代码执行完之后，已经在堆中创建了一个字符串对象，并且在全局字符串常量池中保留了这个字符串的引用，那么str1.intern()直接返回这个引用，这当然满足str1.intern() == str1——都是他自己嘛；对于引用str2，因为JVM中已经有“java”这个字符串了，因此new StringBuilder("ja").append("va").toString()会重新创建一个新的“java”字符串对象，而intern()会返回首次遇到的常量的实例引用，因此他返回的是系统中的那个"java"字符串对象引用(首次)，因此会返回false

  在 JDK6 下 str1、str2 指向的是新创建的对象，该对象将在 Java Heap 中创建，所以 str1、str2 指向的是 Java Heap 中的内存地址；调用 intern 方法后将尝试在常量池中查找该对象，没找到后将其放入常量池并返回，所以此时 str1/str2.intern() 指向的是常量池中的地址，JDK6常量池在永久代，与堆隔离，所以 s1.intern()和s1 的地址当然不同了。

第二个例子在P56页：

public class Test2 {
    public static void main(String[] args) {
        /**
         * 首先设置 持久代最大和最小内存占用(限定为10M)
         * VM args: -XX:PermSize=10M -XX:MaxPremSize=10M
         */

        List<String> list  = new ArrayList<String>();

        // 无限循环 使用 list 对其引用保证 不被GC  intern 方法保证其加入到常量池中
        int i = 0;
        while (true) {
            // 此处永久执行，最多就是将整个 int 范围转化成字符串并放入常量池
            list.add(String.valueOf(i++).intern());
        }
    }
}

以上代码在 JDK6 下会出现 Perm 内存溢出，JDK7 or high 则没问题。

  JDK6 常量池存在持久代(不经心CG)，设置了持久代大小后，不断while循环必将撑满 Perm 导致内存溢出；JDK7 常量池被移动到 Native Heap(Java Heap,HotSpot VM中不区分native堆和Java堆)，所以即使设置了持久代大小，也不会对常量池产生影响；不断while循环在当前的代码中，所有int的字符串相加还不至于撑满 Heap 区，所以不会出现异常。

三.JAVA 基本类型的封装类及对应常量池

  java中基本类型的包装类的大部分都实现了常量池技术，这些类是Byte,Short,Integer,Long,Character,Boolean,另外两种浮点数类型的包装类则没有实现。另外上面这5种整型的包装类也只是在对应值小于等于127时才可使用对象池，也即对象不负责创建和管理大于127的这些类的对象。

public class StringConstantPool{

    public static void main(String[] args){
        //5种整形的包装类Byte,Short,Integer,Long,Character的对象，
        //在值小于127时可以使用常量池
        Integer i1=127;
        Integer i2=127;
        System.out.println(i1==i2);//输出true

        //值大于127时，不会从常量池中取对象
        Integer i3=128;
        Integer i4=128;
        System.out.println(i3==i4);//输出false
        //Boolean类也实现了常量池技术

        Boolean bool1=true;
        Boolean bool2=true;
        System.out.println(bool1==bool2);//输出true

        //浮点类型的包装类没有实现常量池技术
        Double d1=1.0;
        Double d2=1.0;
        System.out.println(d1==d2); //输出false

    }
}

  在JDK5.0之前是不允许直接将基本数据类型的数据直接赋值给其对应地包装类的，如：Integer i = 5; 但是在JDK5.0中支持这种写法，因为编译器会自动将上面的代码转换成如下代码：Integer i=Integer.valueOf(5);这就是Java的装箱.JDK5.0也提供了自动拆箱：Integer i =5; int j = i;

  以及，这里常量池中缓存的是包装类对象，而不是基本数据类型，要注意！！！

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

推荐阅读更多精彩内容

  • Java初级面试题
    1. Java基础部分 基础部分的顺序：基本语法，类相关的语法，内部类的语法，继承相关的语法，异常的语法，线程的语...
    子非鱼_t_阅读 31,293评论 18赞 399
  • 最详细的JVM&GC讲解
    这篇文章是我之前翻阅了不少的书籍以及从网络上收集的一些资料的整理，因此不免有一些不准确的地方，同时不同JDK版本的...
    高广超阅读 15,413评论 3赞 83
  • 【转】Java面试题全集（上）
    转自：http://blog.csdn.net/jackfrued/article/details/4492194...
    王帅199207阅读 8,384评论 3赞 93
  • 鹿关
    今天是我在简书第二天，发生了一个大新闻。 鹿晗和关晓彤公开了！
    王淑彤阅读 155评论 0赞 0
  • 第一章
    “千年之后的你会在哪里——” “喂？嗯，我这边就要结束了，嗯，晚上回家吃饭。”王振挂上电话，贴上了最后一个...
    九月小麦田阅读 176评论 0赞 0