关于String和StringBuffer

String 和 StringBuilder的区别

String类的学习（可以结合字符串常量池 常量池 运行时常量池来学习）

• 1.首先这两个类都是final类，一旦创建就不能修改值，对于已经存在的String对象的修改都是重写创建一个新对象，然后把新的值保存进去，String不能被继承，作为参数传递时，只是传递了一份引用，可以使用它的值，但是并不能修改，修改也只是修改局部变量的值

public class Demo {
    static String s1="hello";
    public static void getS(String s1){
        //这里只是把 一个String类型引用传过来给另一个 然后改变的是这个局部变量的指向 并没有改变外部成员s1的指向是
        s1=s1+"world";
        s1="hi";
        //这里指的是这个对象 "hello"不可变 而不是引用
    }
    public static void getp(Person p1){
        p1.modifyName("小明");
        //这里对象当然可变
        p1=new Person("小伟",11);
    }

    public static void main(String[] args) {
        System.out.println(s1);
        getS(s1);
        System.out.println(s1);
        s1=s1+"world";
        System.out.println(s1);
        Person p=new Person("小伟",12);
        //这里如果是一个对象的话传入了是引用 然后可以修改这个引用代表的对象
        System.out.println(p.name);
        getp(p);
        System.out.println(p.name);
    }
}

• 2.关于字符串常量池，常量池，运行时常量池介绍

常量池表

1.Class 文件中存储所有的常量（包括字符串常量）的table，Class文件的内容，不是2.运行时的内容，就是Class文件中的字节码指令，我觉得应该是每一种

运行时常量池

1.jvm内存中方法区的一部分，这是运行时的内容
2.这部分（绝大部分）内容随着jvm运行的时候，从常量池中转化而来，每一个Class对应一个运行时常量池
3.说绝大部分的原因是因为：除了Class中常量池内容，还可能包括动态生成加入到这里的内容

字符串常量池

1.这部分内容也是在方法区中，但是与运行时常量池不同，字符串常量池在jvm中是全局共享的，全局只有一个字符串常量池，他利用了享原模式，使字符串对象不重复创建，复用了同一个对象
2.jvm规范中要求进入到这里的string实例叫“被驻留的 intern string”，进来了下次遇到同一个就不用创建对应了，直接使用这个地址，如果池中没有，就创建然后驻留在池中，不同的虚拟机有不同的实现方式，而在主流的虚拟机Hotspot中设置一个StringTable来引用堆中的字符串实例，被引用了就是被驻留了

StringBuffer 的学习(直接copyl了)

底层都是char[] 不同的是String的char[]属性也是final，而StringBuffer内的char[]是可变的
String 字符串常量
StringBuffer 字符串变量（线程安全）
StringBuilder 字符串变量（非线程安全）
简要的说， String 类型和 StringBuffer 类型的主要性能区别其实在于 String 是不可变的对象, 因此在每次对 String 类型进行改变的时候其实都等同于生成了一个新的 String 对象，然后将指针指向新的 String 对象，所以经常改变内容的字符串最好不要用 String ，因为每次生成对象都会对系统性能产生影响，特别当内存中无引用对象多了以后， JVM 的 GC 就会开始工作，那速度是一定会相当慢的。
而如果是使用 StringBuffer 类则结果就不一样了，每次结果都会对 StringBuffer 对象本身进行操作，而不是生成新的对象，再改变对象引用。所以在一般情况下我们推荐使用 StringBuffer ，特别是字符串对象经常改变的情况下。而在某些特别情况下， String 对象的字符串拼接其实是被 JVM 解释成了 StringBuffer 对象的拼接，所以这些时候 String 对象的速度并不会比 StringBuffer 对象慢，而特别是以下的字符串对象生成中， String 效率是远要比 StringBuffer 快的：
String S1 = “This is only a” + “ simple” + “ test”;
StringBuffer Sb = new StringBuilder(“This is only a”).append(“ simple”).append(“ test”);
你会很惊讶的发现，生成 String S1 对象的速度简直太快了，而这个时候 StringBuffer 居然速度上根本一点都不占优势。其实这是 JVM 的一个把戏，在 JVM 眼里，这个
String S1 = “This is only a” + “ simple” + “test”; 其实就是：
String S1 = “This is only a simple test”; 所以当然不需要太多的时间了。但大家这里要注意的是，如果你的字符串是来自另外的 String 对象的话，速度就没那么快了，譬如：
String S2 = “This is only a”;
String S3 = “ simple”;
String S4 = “ test”;
String S1 = S2 +S3 + S4;
这时候 JVM 会规规矩矩的按照原来的方式去做

在大部分情况下 StringBuffer > String
StringBuffer
Java.lang.StringBuffer线程安全的可变字符序列。一个类似于 String 的字符串缓冲区，但不能修改。虽然在任意时间点上它都包含某种特定的字符序列，但通过某些方法调用可以改变该序列的长度和内容。
可将字符串缓冲区安全地用于多个线程。可以在必要时对这些方法进行同步，因此任意特定实例上的所有操作就好像是以串行顺序发生的，该顺序与所涉及的每个线程进行的方法调用顺序一致。
StringBuffer 上的主要操作是 append 和 insert 方法，可重载这些方法，以接受任意类型的数据。每个方法都能有效地将给定的数据转换成字符串，然后将该字符串的字符追加或插入到字符串缓冲区中。append 方法始终将这些字符添加到缓冲区的末端；而 insert 方法则在指定的点添加字符。
例如，如果 z 引用一个当前内容是“start”的字符串缓冲区对象，则此方法调用 z.append("le") 会使字符串缓冲区包含“startle”，而 z.insert(4, "le") 将更改字符串缓冲区，使之包含“starlet”。
在大部分情况下 StringBuilder > StringBuffer
java.lang.StringBuilde
java.lang.StringBuilder一个可变的字符序列是5.0新增的。此类提供一个与 StringBuffer 兼容的 API，但不保证同步。该类被设计用作 StringBuffer 的一个简易替换，用在字符串缓冲区被单个线程使用的时候（这种情况很普遍）。如果可能，建议优先采用该类，因为在大多数实现中，它比 StringBuffer 要快。两者的方法基本相同

字符串String的优劣

字符串不可变的优势

1. 只有当字符串是不可变的，字符串池才有可能实现。字符串池的实现可以在运行时节约很多heap空间，因为不同的字符串变量都指向池中的同一个字符串。但如果字符串是可变的，那么String interning将不能实现

2. 数据库的用户名、密码都是以字符串的形式传入来获得数据库的连接，或者在socket编程中，主机名和端口都是以字符串的形式传入。因为字符串是不可变的，所以它的值是不可改变的，否则黑客们可以钻到空子，改变字符串指向的对象的值，造成安全漏洞。

3. 因为字符串是不可变的，所以是多线程共享安全的，同一个字符串实例可以被多个线程共享。

4. 因为字符串是不可变的，所以在它创建的时候hashcode就被缓存了，不需要重新计算。这就使得字符串很适合作为Map中的键，字符串的处理速度要快过其它的键对象。这就是HashMap中的键往往都使用字符串

5.类加载器要用到字符串，不可变性提供了安全性，以便正确的类被加载。譬如你想加载java.sql.Connection类，而这个值被改成了myhacked.Connection，那么会对你的数据库造成不可知的破坏。

字符串不可变的坏处

劣势：影响效率，对系统性能产生影响，当内存的对象没有可达性时，jvm的gc就开始进行minor gc 工作，肯定需要时间，所以影响性能
StringBuffer 和StringBuilder可变