java String 以及字符串直接量 与 字符串驻留池 ...

转自：http://www.blogjava.net/fancydeepin

前言： 字符串 (String) 是 java 编程语言中的核心类之一，在我们平常时候使用也比较很普遍，应用广泛。 但你是否知道什么是字符串直接量，知不知道有个字符串驻留池，字符串的驻留池可以用来缓存字符串直接量。

什么是直接量？
直接量是指：在程序中，通过源代码直接指定的值。 eg： int personId = 8080 ; String name = "fancy" ;
对于 java 中的字符串直接量，JVM 会使用一个字符串驻留池来缓存它们。一般情况下，字符串驻留池中的字符串对象不会被 GC (Garbage Collection，垃圾回收) 所回收， 当再次使用字符串驻留池中已有的字符串对象时候，无需再次创建它，而直接使它的引用变量指向字符串驻留池中已有的字符串对象。
String 基础：

String 类代表字符串。字符串是常量，它们的值在创建之后是不能再被更改的。在 java 中除了 synchronized之外，不可变的类也是线程安全的， 因此，String 类本身也是线程安全的。String 类的实例对象其实是可以被共享的。
示例代码： 

12        String name ="fancy";                  // @1 3        String nick    ="fancydeepin";  // @2 4        name = nick; 5        System.out.println(name);    // export：fancydeepin 6

结果输出 ：fancydeepin
这是怎么回事？不是说 String 是不可变的字符串吗？怎么这里又变了？ 是这样的，在这里 name 只是一个引用类型变量，并不是一个 String 对象，@1中创建了一个 "fancy" 的字符串对象， @2中创建了一个 "fancydeepin" 的字符串对象，name 引用 (就像一个指针) 刚开始是指向 "fancy" 对象，而后，name 又重新指向 "fancydeepin" 对象， 在示例代码中，整个过程只创建了两个 String 对象 (不知道我这样说你能不能理解，为什么是只创建了两个 String 对象？而不是 1个、3个... @3)，
一个是 "fancy" 对象，另外一个是 "fancydeepin" 对象。而这两个对象被创建出来后并没有被改变过，之所以程序会输出 fancydeepin，完全只是因为
name 引用所指向的对象发生了改变。
如果你是本着认真的态度看着我的贴子，细心的你，是否会留意到：
当 name 引用重新指向另外一个对象的时候，那 name 之前引用的对象 ( "fancy" 对象 ) JVM 在底层会怎么处理它呢？是会立即来回收它来释放系统资源吗？
答案是否定的。虽然这时候程序再也不访问 "fancy" 这个对象，但 JVM 还是不会来回收它，它将在程序运行期间久驻内存，为什么会这样呢？
再往下说就扯到 java 的内存管理机制了，这里点到即止。在这里你可以简单的将它理解成 "fancy" 对象被缓存了起来 ( 实际上也是因为被缓存了 )。
字符串驻留池 当比较两个 String 对象时候，是应该用 "==" 呢？还是应该选择 equals 呢？相信绝大部分人绝大多时候使用的都是选择用 equals 方法。
"==" 和 equals 的用法相信大家都很熟悉了，"==" 比较的是两个对象的哈希码值是否相等，而 equals 比较的是对象的内容是否一样。
而绝大部分时候我们比较两个 String 对象的时候只是想比较它们的内容是否相等，这样看来，只能选 equals 了，但真的是这样吗？
答案是否定的。你一样也可以用 "==" 来完成这样的一件事情，而且 "==" 的效率无论如何都是要比使用 equals 的效率要高的，但前提是，
需要使用字符串的驻留池，才能使用 "==" 来替代 equals 作比较。
String 里面有个方法叫 intern()，执行效率很高，但也许你还不曾用过，下面是摘自API中 intern() 方法的描述：

“当调用 intern 方法时，如果池已经包含一个等于此 String 对象的字符串（用 equals(Object) 方法确定），则返回池中的字符串。 否则，将此 String 对象添加到池中，并返回此 String 对象的引用。 它遵循以下规则： 对于任意两个字符串 s 和 t，当且仅当 s.equals(t) 为 true 时，s.intern() == t.intern() 才为 true。 ” 示例代码：

1 2             String name =new String("fancy"); 3            4        if(name =="fancy") {    // false 5            System.out.println("equals 1"); 6        }else { 7            System.out.println("not equals 1");    // Be printed 8        } 9        10        name = name.intern();    // 将字符串添加到驻留池11        12        if(name =="fancy") {    // true13            System.out.println("equals 2");        // Be printed14        }else { 15            System.out.println("not equals 2"); 16        }17

输出结果：

12not equals 13equals 24

 

由上面的示例代码可以看到，字符串驻留池的使用是非常简单的，池中的对象可以被共享，只要你将字符串添加到池中，就能够直接使用 "==" 来比较两个对象，而不是只能使用 equals 来作比较。将字符串添加到驻留池来使用 "==" 作比较的方式要比直接使用 equals 效率要高些。
再论 String、StringBuffer 和 StringBuilder

由 synchronized 修饰的方法可以保证方法的线程安全，但是会降低该方法的执行效率；

翻开 API，很容易就能知道：StringBuffer 是线程安全的可变字符序列，StringBuilder 是一个可变的字符序列，是线程不安全的； 网上说的所谓的使用 StringBuffer 的效率更高更好，这已经不合时宜，这是 java 1.5 之前的版本的说法，早过时了现在！！ 现在是反过来了，由于 StringBuilder 不是线程安全的，StringBuilder 效率会比 StringBuffer 效率更高一些。
你可以不相信我说的，但你总该相信程序跑出来的结果吧，下面是示例代码：

1 2        StringBuffer  buffer  =new StringBuffer(); 3        StringBuilder builder =new StringBuilder(); 4        int COUNT =10;       // 测试 COUNT 趟 5        finalint N =100000; // 每趟操作 N 次 6        double beginTime, costTime; // 每趟开始时间和耗费时间 7        double bufferTotalTime =0.0D, buliderTotalTime =0.0D; // StringBuffer 和 StringBuilder 测试 COUNT 趟的总耗时 8        while(COUNT -->-1) { 9            // 也可以测试每趟都创建一个新的对象,这样 StringBuilder 效率比 StringBuffer 的效率变得更明显了10            /**11            StringBuffer  buffer  = new StringBuffer(); 12            StringBuilder builder = new StringBuilder(); 13            */14            System.out.println("----------------------------------<"+ (COUNT +1) +">"); 15            beginTime = System.currentTimeMillis(); 16            for(int i =0; i < N; i++) { 17                buffer.append(i); 18                buffer.length(); 19            }20            costTime = System.currentTimeMillis() - beginTime; 21            bufferTotalTime  += costTime; 22            System.out.println("StringBuffer  费时： --->> "+ costTime); 23            beginTime = System.currentTimeMillis(); 24            for(int i =0; i < N; i++) { 25                builder.append(i); 26                builder.length(); 27            }28            costTime = System.currentTimeMillis() - beginTime; 29            buliderTotalTime += costTime; 30            System.out.println("StringBuilder 费时： --->> "+ costTime); 31            System.out.println("----------------------------------<"+ (COUNT +1) +">"); 32        }33        System.out.println("bufferTotalTime / buliderTotalTime = "+ (bufferTotalTime / buliderTotalTime)); 34

后台输出结果：

1 2----------------------------------<10> 3StringBuffer  费时： --->>32.0 4StringBuilder 费时： --->>16.0 5----------------------------------<10> 6----------------------------------<9> 7StringBuffer  费时： --->>21.0 8StringBuilder 费时： --->>15.0 9----------------------------------<9>10----------------------------------<8>11StringBuffer  费时： --->>25.012StringBuilder 费时： --->>35.013----------------------------------<8>14----------------------------------<7>15StringBuffer  费时： --->>24.016StringBuilder 费时： --->>8.017----------------------------------<7>18----------------------------------<6>19StringBuffer  费时： --->>48.020StringBuilder 费时： --->>38.021----------------------------------<6>22----------------------------------<5>23StringBuffer  费时： --->>22.024StringBuilder 费时： --->>8.025----------------------------------<5>26----------------------------------<4>27StringBuffer  费时： --->>23.028StringBuilder 费时： --->>9.029----------------------------------<4>30----------------------------------<3>31StringBuffer  费时： --->>25.032StringBuilder 费时： --->>7.033----------------------------------<3>34----------------------------------<2>35StringBuffer  费时： --->>23.036StringBuilder 费时： --->>7.037----------------------------------<2>38----------------------------------<1>39StringBuffer  费时： --->>78.040StringBuilder 费时： --->>59.041----------------------------------<1>42----------------------------------<0>43StringBuffer  费时： --->>21.044StringBuilder 费时： --->>11.045----------------------------------<0>46bufferTotalTime / buliderTotalTime =1.605633802816901547

StringBuffer 在测试中平均耗时是 StringBuilder 的 1.6 倍以上，再测多次，都是 1.6 倍以上。StringBuffer 和 StringBuilder 的性能孰更加优，一眼明了。
最后，如果你想知道 @3 (在上面我已经用红色粗体标出) 的结果，不妨说一下： eg: String mail = "fancydeepin" + "@" + "yeah.net"; 来，一起来看一下上面的这条语句，想一下，这条语句将会创建几个 String 的对象呢？ 1个？ 2个？ 3个？ 4个？ 5个？ ... ...
也许你会认为是4个，它们分别是："fancydeepin"、"@"、"yeah.net"、"fancydeepin@yeah.net" 也许你会认为是5个，它们分别是："fancydeepin"、"@"、"yeah.net"、"fancydeepin@"、"fancydeepin@yeah.net" 也许 ... ... 但实际上，这条语句只创建了一个 String 对象！ 为什么会这样呢？原因很简单，这是因为，mail 在 编译的时候其值就已经确定，它就是 "fancydeepin@yeah.net" 。 当程序处于运行期间且当上面的这条语句被执行到的时候，那么 mail 所引用的对象就会被创建，而 mail 的值由于在编译的时候已经确定 它是  "fancydeepin@yeah.net" ，所以最终只有一个 String 对象被创建出来，而这个对象就是 "fancydeepin@yeah.net" 对象。
这样解释都能够理解了吧？真的理解了吗？是真的理解才好，不妨再来看一个： eg: String mail = new String("fancydeepin@yeah.net");
这回又创建了几个对象呢？ 答案是2个。为什么不是1个了呢？2个又是哪2个呢？ 可以很肯定的告诉你，它们分别是： "fancydeepin@yeah.net"、new String() 这是因为，这回 mail 在编译的时候它的值是还不能够确定的，编译只是将源代码翻译成字节码，程序还并没有跑起来，还 new 不了对象， 所以在编译完成之后，mail 的值是还不能够确定的。 当程序处于运行期间且当上面的这条语句被执行到的时候，这时候才开始去确定 mail 的引用对象，首先，"fancydeepin@yeah.net" 对象会被创建， 之后，再执行 new String()，所以这条语句最后实际上是创建了 2个 String 对象。