Java：String、StringBuffer、StringBuilder

一、String

1. String类是final类，意味着String类不能被继承，它的成员方法都默认为final方法。在早期的JVM版本中，被final修饰的方法会转为内嵌调用来提升执行效率。从JDK 1.5、1.6开始抛弃这种方法。因此，现在的JDK版本中不需要考虑用final来提升方法调用效率。只有在确定不想让该方法覆盖时，才将方法设置为final。

2. String类通过char数组来保存字符串

3. String对象一旦创建就不会发生改变，对String对象的任何操作都会产生新的对象

---

二、 StringBuffer

1. StringBuffer是线程安全的可变字符序序列。StringBuffer是类似于 String 的字符串缓冲区，但可以进行修改。虽然在任意时间点上它都包含某种特定的字符序列，但通过某些方法调用可以改变该序列的长度和内容。

2. 字符串缓冲区可以安全地用于多个线程。可以在必要时对这些方法进行同步，因此任意特定实例上的所有操作就好像是以串行顺序发生的，该顺序与所涉及的每个线程进行的方法调用顺序一致。

3. StringBuffer 上的主要操作是 append 和 insert 方法，可重载这些方法，以接受任意类型的数据。每个方法都能有效地将给定的数据转换成字符串，然后将该字符串的字符追加或插入到字符串缓冲区中。append 方法始终将这些字符添加到缓冲区的末端；而 insert 方法则在指定的点添加字符。

4. 无论何时在源序列上进行操作，类同步只是对字符缓冲区的同步。注意尽管多线程同时使用StringBuffer时是安全的，如果构造函数或其他操作所使用的源序列是多个线程共享的，执行操作的代码必须保证操作时拥有源序列的一致的、不变的视图。可以通过调用者加锁的方式来实现，比如使用一个不可变的源序列，或是不在线程间共享源序列。

5. 每一个字符缓冲区拥有自己的容量，只要字符序列的长度不超过该容量，就没必要分配一个新的内部缓冲区。如果内部缓冲区溢出了，字符缓冲区会自动增大。

6. 除非另有说明，将 null 作为参数构造函数或这个类的其他方法，会抛出NullPointerException

7. JDK 1.5 发布了针对单线程设计的StringBuilder类，是对StringBuffer的一个等价补充。通常有限使用StringBuilder，因为它拥有同样的操作并且速度更快，但是不支持同步。

---

三、StringBuilder

1. StringBuilder是一个可变的字符序列，该类提供了与StringBuffer兼容的API，但是StringBuilder不保证同步。当字符缓冲区是被单线程使用时（通常是单线程使用），StringBuilder类可以看作是StringBuffer类的理想替代。尽可能优先使用StringBuilder，因为大部分情况下它的速度更快。

2. 多线程使用时，StringBuilder是非安全的。如果要求这种安全的同步，推荐使用StringBuffer。

---

四、深入理解String、StringBuffer、StringBuilder

1. String str="hello world"和String str=new String("hello world")的区别

public class Test {

    public static void main(String[] args) {
        String str1 = "hello world";
        String str2 = new String("hello world");
        String str3 = "hello world";
        String str4 = new String("hello world");

        System.out.println("str1==str2 : " + (str1 == str2));
        System.out.println("str1==str3 : " + (str1 == str3));
        System.out.println("str2==str4 : " + (str2 == str4));
    }
}

　执行结果：

为什么会出现这样的结果？下面解释一下原因：

　　首先要了解以下JVM的内存机制 ，在class文件中有一部分来存储编译期间生成的字面常量以及符号引用，这部分叫做class文件常量池，在运行期间对应着方法区的运行时常量池。

　　因此在上述代码中，String str1 = "hello world";和String str3 = "hello world"; 都在编译期间生成了字面常量和符号引用，运行期间字面常量"hello world"被存储在运行时常量池（当然只保存了一份）。通过这种方式来将String对象跟引用绑定的话，JVM执行引擎会先在运行时常量池查找是否存在相同的字面常量，如果存在，则直接将引用指向已经存在的字面常量；否则在运行时常量池开辟一个空间来存储该字面常量，并将引用指向该字面常量。

　　众所周知，通过new关键字来生成对象是在堆区进行的，而在堆区进行对象生成的过程是不会去检测该对象是否已经存在的。因此通过new来创建对象，创建出的一定是不同的对象，即使字符串的内容是相同的。

2. String、StringBuffer以及StringBuilder的区别

（1）既然已经有了String类，那为什么还需要StringBuilder类呢？

　　那么看下面这段代码：

public class Test {

    public static void main(String[] args) {
        String string = "";
        for (int i = 0; i < 10000; i++) {
            string += "hello";
        }
    }
}

　　这句 string += "hello";的过程相当于将原有的string变量指向的对象内容取出与"hello"作字符串相加操作再存进另一个新的String对象当中，再让string变量指向新生成的对象。也就是说这个循环执行完毕new出了10000个对象，试想一下，如果这些对象没有被回收，会造成多大的内存资源浪费。

再看下面这段代码：

public static void main(String[] args) {
        StringBuilder stringBuilder = new StringBuilder();
        for (int i = 0; i < 10000; i++) {
            stringBuilder.append("hello");
        }
}

　　new操作只需要进行一次，也就是说只生成了一个对象，append操作是在原有对象的基础上进行的。因此在循环了10000次之后，这段代码所占的资源要比上面小得多。

（2）既然有了StringBuilder类，为什么还需要StringBuffer类？

事实上，StringBuilder和StringBuffer类拥有的成员属性以及成员方法基本相同，区别是StringBuffer类的成员方法前面多了一个关键字：synchronized，不用多说，这个关键字是在多线程访问时起到安全保护作用的,也就是说StringBuffer是线程安全的。

所以当多线程访问时推荐使用StringBuffer，而单线程访问时StringBuilder速度更快！

下面是StringBuffer和StringBuilder源码中成员方法差别的对比：

StringBuffer的成员方法前都有synchronized关键字：

StringBuilder的成员方法：

---

五、 不同场景下三者的性能对比

使用下列代码进行对三者性能做一个简单测试：

public class Test {

    private static int num = 50000;

    public static void main(String[] args) {
        testString();
        testStringBuffer();
        testStringBuilder();
        test1String();
        test2String();
    }

    public static void testString() {
        String s = "";
        long begin = System.currentTimeMillis();
        for (int i = 0; i < num; i++) {
            s += "java";
        }
        long over = System.currentTimeMillis();
        System.out.println("操作" + s.getClass().getName() + "类型使用的时间为：" + (over - begin) + "毫秒");
    }

    public static void testStringBuffer() {
        StringBuffer sb = new StringBuffer();
        long begin = System.currentTimeMillis();
        for (int i = 0; i < num; i++) {
            sb.append("java");
        }
        long over = System.currentTimeMillis();
        System.out.println("操作" + sb.getClass().getName() + "类型使用的时间为：" + (over - begin) + "毫秒");
    }

    public static void testStringBuilder() {
        StringBuilder sb = new StringBuilder();
        long begin = System.currentTimeMillis();
        for (int i = 0; i < num; i++) {
            sb.append("java");
        }
        long over = System.currentTimeMillis();
        System.out.println("操作" + sb.getClass().getName() + "类型使用的时间为：" + (over - begin) + "毫秒");
    }

    public static void test1String() {
        long begin = System.currentTimeMillis();
        for (int i = 0; i < num; i++) {
            String s = "I" + "love" + "java";
        }
        long over = System.currentTimeMillis();
        System.out.println("字符串直接相加操作：" + (over - begin) + "毫秒");
    }

    public static void test2String() {
        String s1 = "I";
        String s2 = "love";
        String s3 = "java";
        long begin = System.currentTimeMillis();
        for (int i = 0; i < num; i++) {
            String s = s1 + s2 + s3;
        }
        long over = System.currentTimeMillis();
        System.out.println("字符串间接相加操作：" + (over - begin) + "毫秒");
    }

}

　　运行结果（Mac OS，JDK 1.8，IDEA）

下面对上面的执行结果进行一般性的解释：

　　（1）对于直接相加字符串，效率很高，因为在编译器便确定了它的值，也就是说形如"I"+"love"+"java"; 的字符串相加，在编译期间便被优化成了"Ilovejava"。这个可以用javap -c命令反编译生成的class文件进行验证。

　　（2）对于间接相加（即包含字符串引用），形如s1+s2+s3; 效率要比直接相加低，因为在编译器不会对引用变量进行优化。

　　（3）String、StringBuilder、StringBuffer三者的执行效率：

　　  StringBuilder > StringBuffer > String

　　  当然这个是相对的，不一定在所有情况下都是这样。

　　  比如，String str = "hello"+ "world"的效率就比 StringBuilder st  = new StringBuilder().append("hello").append("world")要高。

　　  因此，这三个类是各有利弊，应当根据不同的情况来进行选择使用：

　　  当字符串相加操作较少或者改动较少的情况下，建议使用 String str="hello"这种形式；

　　  当字符串相加操作较多的情况下，建议使用StringBuilder，如果采用了多线程，则使用StringBuffer。

---

参考：https://www.cnblogs.com/dolphin0520/p/3778589.html