首先把问题摆出来,先看这个代码:String a = "ab"; 
String b = "a" + "b"; 
System.out.println((a == b)); 
打印结果会是什么?类似这样的问题,有人考过我,我也拿来考过别人(蛮好玩的,大家也可以拿来问人玩),一般答案会是以下几种: 1、true "a" + "b" 的结果就是“ab”,这样a,b都是“ab”了,内容一样所以“相等”,结果true。一般Java新人如是答。 2、false "a" + "a"会生成新的对象“aa”,但是这个对象和String a = "ab";不同,(a == b)是比较对象引用,因此不相等,结果false。对Java的String有一定了解的通常这样回答。 3、true String a = "ab";创建了新的对象“ab”;再执行String b = "a" + "b";结果b="ab",这里没有创建新的对象,而是从JVM字符串常量池中获取之前已经存在的“ab”对象。因此a,b具有对同一个string对象的引用,两个引用相等,结果true。 能回答出这个答案的,基本已经是高手了,对Java中的string机制比较了解。 很遗憾,这个答案是不够准确的。或者说,根本没有运行时计算b = "a" + "b";这个操作。实际上运行时只有String b = "ab";。3的观点适合解释以下情况:String a = "ab"; 
String b = "ab";
System.out.println((a == b)); 
如果String b = "a" + "b";是在运行期执行,则3的观点是无法解释的。运行期的两个string相加,会产生新的对象的。(本文后面对此有解释) 4、true 下面是我的回答:编译优化+ 3的处理方式 = 最后的true String b = "a" + "b";编译器将这个"a" + "b"作为常量表达式,在编译时进行优化,直接取结果"ab",这样这个问题退化。
String a = "ab";
 String b = "ab";
 System.out.println((a == b));
 
然后根据3的解释,得到结果true。这里有一个疑问就是String不是基本类型,像 int secondsOfDay = 24 * 60 * 60; 
这样的表达式是常量表达式,编译器在编译时直接计算容易理解,而"a" + "b" 这样的表达式,string是对象不是基本类型,编译器会把它当成常量表达式来优化吗? 下面简单证明我的推断,首先编译这个类:public class Test { private String a = "aa"; } 
复制class文件备用,然后修改为:public class Test { private String a = "a" + "a"; } 
再次编译,用ue之类的文本编辑器打开,察看二进制内容,可以发现,两个class文件完全一致,连一个字节都不差。 ok,真相大白了。根本不存在运行期的处理String b = "a" + "b";这样的代码的问题,编译时就直接优化掉了。

解决方案 »

  1.   

    下面进一步探讨,什么样的string + 表达式会被编译器当成常量表达式? String b = "a" + "b"; 
    这个String + String被正式是ok的,那么string + 基本类型呢? 
    String a = "a1";
    String b = "a" + 1; 
    System.out.println((a == b)); //result = true
    String a = "atrue"; 
    String b = "a" + true; 
    System.out.println((a == b)); //result = true
    String a = "a3.4"; 
    String b = "a" + 3.4; 
    System.out.println((a == b)); //result = true 
    可见编译器对string + 基本类型是当成常量表达式直接求值来优化的。 再注意看这里的string都是"**"这样的,我们换成变量来试试: 
    String a = "ab"; 
    String bb = "b"; 
    String b = "a" + bb; 
    System.out.println((a == b)); //result = false 
    这个好理解,"a" + bb中的bb是变量,不能进行优化。这里很很好的解释了为什么3的观点不正确,如果String+String的操作是在运行时进行的,则会产生新的对象,而不是直接从jvm的string池中获取。 再修改一下,把bb作为常量变量: String a = "ab"; 
    final String bb = "b"; 
    String b = "a" + bb; 
    System.out.println((a == b)); //result = true 
    竟然又是true,编译器的优化好厉害啊!呵呵!考虑下面这种情况:String a = "ab"; 
    final String bb = getBB(); 
    String b = "a" + bb; 
    System.out.println((a == b)); //result = false 
    private static String getBB() { return "b"; } 
    看来Java(包括编译器和jvm)对string的优化,真的是到了极点了,string这个所谓的“对象”,完全不可以看成一般的对象,Java对string的处理近乎于基本类型,最大限度的优化了几乎能优化的地方。 另外感叹一下,string的+号处理,算是Java语言里面唯一的一个“运算符重载”(接触过c++的人对这个不会陌生)吧?
      

  2.   

    其实楼上两位对string的理解很透彻,但是太片面。对于"a"+"b"这样的表达式是否生成几个对象,很大程度上取决于java编译器的实现者,并不是所有的jdk都会优化编译。这个问题严格来说是没有答案的,它不在虚拟机实现规范之中,也不在java编译器实现规范之中。jdk实现者可以任意去实现如何去处理这种表达式,只要最后能够生成"ab"字符串数组即可。
    但是目前主流jdk都像楼上所说的那样去实现了,进行优化编译,但是这并不意味着你们的答案是正确的,因为这个问题根本就没有答案,所以不要拿这种问题去问别人了,知道是个什么结果即可。
      

  3.   

    还有,各位不要把java源程序所表现出来的形式与编译后的class文件以某种必然的性质联系起来,因为java虚拟机规范指出,并不一定要java语言才能编译出class文件,只要你愿意,可以使用C++的语言格式来生成class文件,只要class文件的格式能够让jvm装载并解析即可,你甚至直接手动生成class二进制流文件也可以,动态代理与CGlib这样的框架似乎就是这种实现。
    还有java语言也不一定只能生成class文件,完全可以开发一个编译器,通过java语言生成dll动态库,当然这不在java规范中,因为那与规范没什么关系了。
    java的真实运行过程根本不像java语言表面描述的那样。
      

  4.   

    像"a"+"b"这种属于《java语言规范》中的编译时常量的概念
    Compile-time constants of type String are always "interned" so as to share unique instances, using the method String.intern.
    关于字符串+:
    If only one operand expression is of type String, then string conversion is performed on the other operand to produce a string at run time. The result is a reference to a String object (newly created, unless the expression is a compile-time constant expression (§15.28))that is the concatenation of the two operand strings.因此对于遵守java语言规范的编译器来说,结果应该是相同的
      

  5.   

    那如果用String a = "a3.4"; 
    String b = "a" + 3.4; 
    System.out.println((a.equals(b))); //result = true 这样跟上面的的有什么区别呢?
      

  6.   

    没想到这种东西会在规范中,我觉得优化这种东西不应该存在于规范之中,规范应该只提供对外调用接口的定义,优化这种东西其实不确定性太强,而且多平台依赖性太强,不同机器和不同平台所要针对的优化手段都不同,虽然编译时很大程度上不不会出现这种情况,但是也不能保证编译时与运行时必须同时存在的特殊情况。
    我觉得这种编译时的实现应该是建议的,而不应该强制规定,不然我觉得有点违背java跨平台的宗旨。
      

  7.   

    jls规定的东西只是对生成的class文件有影响而已,不会对跨平台带来什么影响。